search

christiansandberg / canopen

CANopen for Python
http://canopen.readthedocs.io/
MIT License
444 stars 196 forks source link

getting weird behaviour with sdo read and heartbeat callbacks on 2.3.0 #516

Open woudie-swap opened 4 months ago

woudie-swap commented 4 months ago

Hi,

we have been experiencing some very odd behavior since accidentally upgrading to v2.3.0 - mostly in regards to sdo read and heartbeat callbacks.

regarding the heartbeat callback issue: without any changes to our codebase, we initially began observing what seemed like timing issues where we were getting heartbeats randomly spaced apart. However, after some investigation, we found that the heartbeat callback was just not triggered for numerous heartbeats that were being sent - we could see the heartbeats arriving but the callback would just not trigger. Any ideas on what might be going on here?

regarding the sdo read failures: we make a series of consecutive sdo read calls to get some data from our device, but noticed that they were all failing to get a response since we updated to 2.3.0 and its very unclear as to why. We noticed that there is a random extra frame that gets sent when we make the sdo read call that might be responsible for the issue but our device is not throwing an sdo error on the response id. The can frame is this 80 00 00 00 00 00 04 05 and we are not sure what it trying to do since its not apart of our devices canopen implementation. Any ideas on what might be going on with this?

we have since downgraded to 2.2.0 and all expected functionality returned to normal

acolomb commented 4 months ago

Regarding the NMT heartbeat problem, sorry I have no idea what might cause the callback to not get fired. Maybe it raises an exception pretty early? How did you check whether it runs or not? An exception would be raised in the notifier background thread, you could use network.check() to find that: https://canopen.readthedocs.io/en/latest/network.html#canopen.Network.check

Did you see anything in the change log that rings a bell regarding your use case?

As for SDO, we did in fact add some SDO abort messages (0x80) in cases where the client did not correctly send them following a failure condition being detected. I guess a candump / trace of the SDO communication leading up to that point would help in diagnosing. And here as well, look at the change log and see whether the added cases might affect your device.

Sorry for the inconvenience.