In this experiment, I added two things:
MovePT() isn’t called (it’s just skipped for that FSM iteration) if any of the “action flags” are set in the MultiAxis firmware status.
- I increment a counter (a user buffer) every time I call
The hope is that this will permit us to know if a very badly-timed call to
MovePT() might be a contributor to the issue I’m seeing.
The anomaly (when axis 0 command position changed to something very wrong) this time was that axis 0 was commanded to something very close to the axis 1 cmd/actual position. (Actual: 563077, Cmd:562464, Axis0_Cmd: 561017). I don’t know quite where that number came from or what it might correspond to. These motors generally flicker 1000-5000 counts while they’re holding still, so this could have been the actual position at some (sub-millisecond) moment in time, though it doesn’t correspond to any actual position axis 1 was in during this brief window.
Here’s a visual from (~500ms) around the moment of the anomaly.
Items of interest:
The MovePT_Counter doesn’t change for 60 ms before the anomaly.
- I don’t have any data for
MovePT() calls before I added the skip-calling-MovePT-if-action-bits-are-set behavior.
- I can’t offer reasonable speculation about the timing of
MovePT() calls previously.
- In this instance, it doesn’t appear that a call to
MovePT() happened while something “interesting” was happening (e.g. TriggeredModify).
- Axis 0 was commanded to move to the Axis 1 position (I frequently see it get sent to Axis 2).
- The anomaly happened after the probe input (part of the condition of the user limit) changed. (This has always been the case, I just wanted to mention it again.)
- The command position changed back to the correct one 4 ms after my next call to
MovePT(), at which time the TriggeredModify and TriggeredModify_EStop happened the next millisecond.
Are there other runtime things I should be monitoring, like limit error (or other axis/multiaxis error bits)?
Does this bring to mind other things I can do to isolate the problem?