DS402: Homing fails depending on power state, unnecessary state changes
See original GitHub issueThe BaseNode402.homing()
method tries to enter state SWITCHED ON upon entry. I think 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. That’s because 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).
So I propose to just leave out that initial state switching, but wanted to discuss here first because it will probably break some people’s application on upgrades. Note that switching the operation mode to HOMING is actually safe in any power state, at least on devices I encountered.
Another change I propose is not restoring the previous operation mode, at least as an option. Just needless bus traffic and delay in case the next operation mode must be decided by the application anyway. So I would add an optional argument with the default value restore_op_mode=False
. Anyone opposed?
Same goes for restoring the power state after switching the operation mode. Not really necessary and in case of homing()
it will even cause additional delays by switching back and forth. Leaving OPERATION ENABLED when switching modes should also be optional, because there are valid applications where e.g. Profile Velocity and Profile Position need to be switched during operation without delay.
I will PR any agreed upon changes, so this issue is just for tracking and finding consensus.
Issue Analytics
- State:
- Created 2 years ago
- Comments:16 (1 by maintainers)
Sorry it took a while longer, but here’s my suggestion for a NEWS entry (wherever we may put that):
Once we are certain where this should be documented, I will gladly adjust the formatting accordingly. While writing it up, I noticed a bug which will be fixed by #277.
Great work @acolomb, for me is a go.