Open Phiraos opened 2 years ago
For now I don't get where the error is coming from. Dose it pop up on the display of the acutator? Dose it happen in the CSP mode only or also in homing?
Dose the actuator go into SafeOP state when the error occurs, and stops the motor?
With Python and non-realtime operating systems you will always have big jitter, also network interface cards connected via USB are not good to achieve realtime. Your actuator seems not to like that jitter. I thought "Profile Position" mode would be more resistant to jitter, but this seems also not be the case for your actuator?
For now I don't get where the error is coming from. Dose it pop up on the display of the acutator? Dose it happen in the CSP mode only or also in homing?
I get the error on the utilitary software of the vendor. I use it for monitoring. I get the error only in CSP mode.
Dose the actuator go into SafeOP state when the error occurs, and stops the motor?
With Python and non-realtime operating systems you will always have big jitter, also network interface cards connected via USB are not good to achieve realtime. Your actuator seems not to like that jitter. I thought "Profile Position" mode would be more resistant to jitter, but this seems also not be the case for your actuator?
When the error occurs, the motor stops working but I can't tell is state. I use a ethernet port on a NUC. I don't know how the send_processdata works but, I was thinking maybe the update loop and the processdata loop try to access in the same time the output and that's why it gets out of period.
Hi,
This issue follows the #73.
I use a thread to periodicaly use processdata.
But, even using a thread to send cyclicly processdata, I get systematicaly the error : PVT buffer underflow.
That means, somehow, the processdata loop is not reliable in terms of period (my loop period is approximately 4ms).
Here is the source :
I don't know how to make more stable the processdata loop.