I’m hunting down an elusive problem where I’m homing a slaved axis.
I’m using user limits to trigger a stop when the home input is activated. Each axis has its own input, and I configure the user limit for each axis to triggered modify stop and capture the position.
When this problem happens, the first user limit to trigger commands a stop for the target axis, but also for the other axis.
In this example, Axis.3 triggers its user limit, but both Axis.3 and Axis.0 are commanded to stop.
Note: Axis.0 shouldn’t have been stopped (yet), in blue, is triggered to stop the millisecond after the one tied to the user limit. This timing seems conspicuous.
Questions
I’m fairly confident that I’m using the correct target axis in UserLimitConfigSet(...), or this would never work. I also double-checked to verify that the user limits are using the correct firmware addresses for their respective inputs.
While I’m homing, I remove all the axes from the multi axis. The subsequent stop of Axis.0 reminds me of what happens when a user limit triggers a stop on one axis in the multi axis and it propagates to the others.
What other things could cause RMP to conclude that it should command a stop to an otherwise unrelated axis?
Can you confirm that it only happens during the homing process? If you disable the MultiAxis and trigger the Axis3 UserLimit do you still see a Triggered modify event on Axis0? You’d need motion to see the impact.
We are testing to see if could be another UserLimit triggering for Axis0 or another source of propagation. Is the same true when you disable the Slaving?
So, I’m implementing my own homing routine that resembles 19 (home to switch).
I’m not using Axis::Home(...). I command Axis::MoveVelocity(...) after the user limit is configured.
I haven’t seen this happen any other time, but then, I never use Axis::MoveVelocity(...) outside of this. Neither RMP nor the axis object are in any sort of “homing” mode. (They are all in the standard synchronous cyclic position mode.)
I’m not suggesting that RMP is doing something wrong, as much as I’m asking what kinds of scenarios could cause RMP to command an axis to stop as the result of some other commanded stop. I don’t think it’s the (empty) MultiAxis. I’m skeptical that I’ve misconfigured the user limits. Are there other possible sources?
I’ll try some of the things you suggest as soon as it starts happening again. (-8
So, it turns out in this case that I was not correctly “dissolving” (my terminology) the MultiAxis for the homing routine (due to an uninitialized variable).
The fact that RapidSetup doesn’t always/usually update the MultiAxis view unless you refresh or close/reopen (as well as the behavior of MultiAxisGet(...) vs LoadExistingMultiAxis(...), which I was trying to use in my inspection script), meant that I didn’t pay much attention to what it showed (regarding axis mapping), but the cascading commanded stops certainly looked like MultiAxis behavior.
