You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* ds402: Skip explicit change to SWITCHED ON state.
The BaseNode402.homing() method tries to enter state SWITCHED ON upon
entry. That's unnecessary, the application should handle these
transitions. But more importantly, it actually fails in many cases,
namely if the previous state is SWITCH ON DISABLED, the default
power-up state of most devices. There is an automatic way to reach
OPERATION ENABLED over multiple intermediate steps, but the library
does not know how to reach SWITCHED ON from any other state than
OPERATION ENABLED or READY TO SWITCH ON. In addition, setting the
op_mode property will already change to SWITCHED ON only if coming
from OPERATION ENABLED (which is usually a good idea to avoid
unexpected movement).
Note that switching the operation mode to HOMING is actually safe in
any power state.
* p402: Make HOMING_TIMEOUT_DEFAULT configurable per instance.
When the HOMING_TIMEOUT_DEFAULT class attribute is overridden as an
object attribute, the argument default value definition in homing()
still uses the old value from the class attribute. Check the argument
and apply the default value at runtime to pick up the updated default
timeout if the argument is omitted.
* ds402: Increase delay to check status on homing start.
The Statusword is examined immediately after setting the Controlword
command to start homing. That is very likely to fail because of the
round-trip time until the Statusword is actually updated from a TPDO.
To work around that, the delay between each check of the Statusword
should be moved before the actual comparison, and its default value
increased.
Introduce a new constant TIMEOUT_CHECK_HOMING to configure that with a
default value of 100 ms. This replaces the previously used
INTERVAL_CHECK_STATE which is only 10 ms by default.
An even better solution would be to wait for the Statusword to be
updated by a received PDO, but that would be much more complex.
* p402: Wait for TPDO instead of timed statusword checking.
Several methods loop around waiting for some expected statusword
value, usually calling time.sleep() with the INTERVAL_CHECK_STATE or
INTERVAL_CHECK_HOMING constants. Replace that with a call to
check_statusword(), which will only block until the TPDO is received.
This allows for possibly shorter delays, because the delay can be cut
short when the TPDO arrives in between. But rate limiting the
checking loops is still achieved through the blocking behavior of
check_statusword().
If no TPDO is configured, the statusword will fall back to checking
via SDO, which will also result in periodic checks, but only rate
limited by the SDO round-trip time. Anyway this is not a recommended
mode of operation, as the warning in _check_statusword_configured()
points out.
* p402: Use RPDO to set the operation mode if possible.
Fall back to the previous behavior using SDO if the relevant object
0x6060 is not mapped to an RPDO.
* p402: Check PDO configuration for the Operation Mode objects.
Switching operation modes for several drives simultaneously must be
done via PDO. There is still a fallback mechanism via SDO, but a
warning should be issued when that is about to be used.
0 commit comments