network disconnect - leads to unresolvable exception loop

[QuadCorei8085]

network.py Network.disconnect() functions calls the bus.shutdown() then dumps the bus instance (assigns None).

The problem is that in case a PCAN error happens (e.g. you disconnect the bus - but you would like to be robust against disconnected bus) then notifier thread will throw a PcanError exception, in case you would like your code to recover from this situation this could be done like:

while True:
  try:
      print node.sdo['item']['subitem'].raw
  except:
      network.bus.reset()
      network.disconnect()
      network.connect(....)

The problem with this is that if your bus interruption takes longer than the bus reset, reconnect then the connect will fail without exception and in the next cycle the bus.reset() will report "None" type object has no member reset.

Currently my only workaround is:

while True:
  try:
      print node.sdo['item']['subitem'].raw
  except:
      try:
        network.bus.reset()
      except:
       pass

      try:
        network.disconnect()
      except:
       pass

      try:
        network.connect(....)
      except:
       pass

I also tried to just reset the bus using network.bus.reset() but I was not able to (although with PCAN-View it is possible to bring out the device from the

Bus error: an error counter reached the 'heavy'/'warning' limit

I personally would remove either the python self.bus = None or make it part of the connect() function that in case the item exists we could either throw an exception or just simply replace it with the new instace.

[christiansandberg]

If you always do a disconnect and connect, do you really need to do a reset first?

[QuadCorei8085]

In my experience resetting the PCAN adapter (at least with the PCAN View) helps recovering from bus-off situations, therefore I added the reset command, I'm not sure if the bus.shutdown (and a following initialize) has the same effect.

[christiansandberg]

But if the reset didn't work as you mentioned, why keep it?

[christiansandberg]

The reason the bus is set to None when disconnected is just to keep track of the connected state, but that could be done with a separate connected attribute instead.

[QuadCorei8085]

Yes that would be an option. Another option is to not set it to None, the network would not work without a CAN interface anyway and the shutdown call does not destroy anything in the BusABC class so the object could be kept.

If it is None -> network.connect initializes it, if it is not none-> nothing to do.
If disconnect is called -> bus.shutdown is called and nothing extraordinary happens.

[christiansandberg]

It’s just that I want to raise an exception that is easier to understand. If we don’t keep track of the connect state then the user will either get errors about None type missing methods or some handle is invalid which might not be obvious that the the bus is just not connected.

[QuadCorei8085]

To avoid misunderstanding my proposal above would look like this, in this case there is no need to track the connected state (as such it does not exist anyway, the physical interface is always connected):

def connect(self, *args, **kwargs):
    ....
    if self.bus is None:
        self.bus = can.interface.Bus(*args, **kwargs)
    ....

def disconnect(self):
    """Disconnect from the CAN bus.

    Must be overridden in a subclass if a custom interface is used.
    """
    for node in self.nodes.values():
        node.pdo.stop()
    self.notifier.stop()
    self.bus.shutdown()
    self.check()

The only thing this introduces is that a network can be initialized by 1 CAN interface/driver.
But I don't think reattaching a different CAN interface to the same Network instance is a common practice :)

[christiansandberg]

What will happen if you call disconnect and then connect again? Won’t you just have an unusable bus? Or if you call disconnect and then try to do read an SDO?

[QuadCorei8085]

Nothing extraordinary. Current network.disconnect() implementation calls bus.shutdown() which is implemented as:

    def shutdown(self):
        """
        Called to carry out any interface specific cleanup required
        in shutting down a bus.
        """
        self.flush_tx_buffer()

So it does not do anything with any internal class members neither it de-initializes the (P)CAN physical interface (not even resets it). That is the reason I'm confident that throwing away the bus (by setting to None) is not the optimal solution currently :)

For the SDOs you will have a timeout exception as the notifier is stopped (true exception), but this is not related to the bus handling.

[christiansandberg]

You're not looking at the right code, this is what is done on shutdown:

    def shutdown(self):
        super(PcanBus, self).shutdown()
        self.m_objPCANBasic.Uninitialize(self.m_PcanHandle)

So the bus is uninitialized and pretty much useless after that.

[QuadCorei8085]

Hm, correct. So only the try-except try-except.. could be used to re-init a terminated bus?

[af-silva]

Closing this issue, if you need support @QuadCorei8085 please say, so I can reopen.