Unless I’m missing something, it seems this node has a bug.
When you enter the node, position-value and animation-segment have “old” data. The DO pulse goes directly to mutex-gate, which (assuming it gets the lock) sends a pulse to rotate telling it to set target to current value being fed by animation-segment, a defer node then loops back to update position-value (which will now be the old value from animation-segment, which is likely to NOT be where the servo was last positioned) and start a new animation.
Shouldn’t position-value be getting its pulse from the DO pin as well as sending the pulse to mutex-gate so the current position is pulled before any new rotate commands are sent? This will lead to animation-segment running even if lock isn’t acquired, but the values will be ignored by rotate anyway…
Just noticed this implementation has the problem that the code above servo-mux will get run even if mutex has a lock. Not a big problem for this code since it just restarts from current position (or gets ignored), but could be a problem in other cases (or might be desired function in other cases). The only solution I can think of off-hand is to add a servo-mux-ACT output pin and use it to disable the DO input when ACT is true. This preserves the servo/mutex encapsulation and allows coding of either option (disable DO pin while ACT, or allow over-ride with new DO pulse).
This still re-calculate values feeding servo-mux if another nodeId has the mutex lock, but in that case servo-mux will be ignoring the values (and they will be reset if this node is called after the lock is free), so it should not be an issue.
If calculating the values when other nodeId’s have a lock is a problem, things get a little trickier. In this case, ACT bus could be used to pulse the animation-segment-PLAY pin (instead of position-value-DONE, which would no longer be used) so it only happens when this node first obtains a lock (but position-value will still get updated. If that is a problem, it could feed a buffer that only updates on ACT pulse, but we want to read position-value before servo-mux-ACT is true and it has been over-written with a new value).
Hello and thanks for taking the close look! There are many possible ways to achieve the functionality of rotate-slow and perhaps the variant with mutex-state you’ve offered is more clear. I made the mutex-state node after rotate-slow actually, thus it is implemented using mutex-gate.
I rechecked the current implementation and I’m still thinking it is OK. Here’s why
Not quite. The first pulse to rotate will be sent only after continuously-pausable gets enabled, which is linked to animation-segment, which is activated only on PLAY pulse, which is pulsed by the position-value node only after it sets its VAL output to the correct value.
