I am encountering a problem where occasionally when setting input_pos the execution gets stuck. The script runs for almost a month in hourly cycles and a couple of times it got stuck writing input_pos. The position is written after a delay of 150 seconds where no commands are send to the odrive. The odrive reports no errors and python is also still processing without errors.
Included are two pictures, one of the debug trace of where the code ended and it was stopped and one of the script which it was executing when it got stuck. What could be the problem? And what are possible solutions?
Revision used are the following:
HW revision: 3.6
FW revision: 0.5.4
Odrivetool revision: 0.6.3
Interesting! Could you update ODrivetool to the latest release and see if the issue persists?
I think other than that, I’d strongly recommend using CAN bus, especially if this is an application that needs to constantly run for a month – USB can be a bit intrinsically unreliable, there’s really no way of knowing if this is an actual ODrivetool bug, or your OS being weird, or a bug in your computer’s USB controller firmware – makes diagnosis fun, but difficult.
After running for ~19 hours the problem arose again.
Since it is always after a delay of 150 seconds with no communication I think it can be something in the USB chain (Driver/controller/whatever else is in between) entering some kind of sleep mode. I changed the 150 seconds delay so there is communication every two seconds with the ODrive keeping communication (USB chain) active. Will keep you posted on results.
