-
Notifications
You must be signed in to change notification settings - Fork 52
Description
Hello,
I believe I've found a bug/issue in PySOEM: calling Master.state_check() appears to block the entire python process for the duration of it's timeout parameter, which interrupts the process data thread during the SafeOP -> OP transition.
This is the general order of operations presented in basic_example.py:
- Transition all slaves to SafeOP state.
- Start the background thread to transmit cyclic process data.
- Request all slaves to OP state.
- Call
state_check()repeatedly to validate that all slaves have reached OP state (in this example with a timeout of 50ms).
The issue occurs in step 4. I've observed the EtherCAT process data getting interrupted for exactly 50ms intervals the exact number of times the state_check() call is executed (it often takes multiple failed attempts to enter OP). I believe the issue is that because python doesn't support true multi-threading, calling state_check() blocks every thread in the python process.
This implementation makes the code fragile because changing the timeout parameter or network cycle rate can spontaneously break the code for no apparent reason. I believe it also means that some slaves with more stringent watchdog settings may not work at all, because performing the check will inherently cause the watchdog to expire.
It should be noted that SOEM has a similar pattern in their ec_sample.c example. However, I believe this code works properly because C has true multi-processor support; the background cyclic thread does not get interrupted by the call.
It's possible that this could be intended functionality, but in general I believe there should be a method to verify that OP state has been achieved without interrupting process data.