Description
Hi Tobit,
I am still investigating, but when using closed-loop position control for path-following (with commands every time step), my system tends to accrue many myactuator_rmd.can.BusError exceptions regardless of the time step size used (typically 2 ms but with other time step sizes also). I'm handling the exceptions and it doesn't appear to have a significant effect on path following performance, but after executing a path later individual commands often return a myactuator_rmd_py.ProtocolException: Unexpected response of the kind used by the path following, e.g.:
>>> motor[5].setAcceleration(5000, pos_accel)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
myactuator_rmd_py.ProtocolException: Unexpected response '0xa4'
In this case monitoring the CAN socket reveals a correct (0x43) message and response, and the motor does execute the command to write the new acceleration, but it is problematic when you need to read the correct response (e.g., with getMultiTurnAngle()). It is as though responses to commands which receive a BusError accrue in a buffer and then are inappropriately read by later commands.
Also, though more rarely, a BusError will occur on a command that is not repeated each time step, which I think may cause the command to fail to be sent to the motor (to be confirmed) - potentially disrupting a program. Anecdotally, I think the likelihood of this may increase as more BusError's have been accrued (e.g., following execution of a path).
As I mentioned I'm still investigating, so I'm not certain whether the bus errors are a result of something in my system or something in the code. I haven't yet dug into your code sufficiently to see what might cause the bus errors there, but maybe you have a better idea? In any case, I wonder if there is a way to clear the response buffer so later commands don't get unexpected responses?
I will continue to look into this on my return at the end of the month, but just wanted to bring it up now in case you have a chance to start thinking about it.
Cheers,
Stefan