We’re implementing probing.
To accomplish this, we create one user limit per axis. The user limit for axis #0 has RSIActionTRIGGERED_MODIFY as the action. The other user limits don’t trigger any actions. Depending on how probing is configured, the user limit may also capture the axis position. (Some axes may use high-speed inputs on the drive to capture the probe position, others rely on RMP to capture the position.)
Now, 2532 times out of 2533, this works as I would expect. That one time, something odd happens.
Somewhere around 3 ms after the (active low) input goes low, the RMP commanded position for axis #0 changes to the exact RMP commanded position for axis #2. About 427 ms later, the commanded position jumps back to where it should have been after I send it the next batch of points (I think).
In this scenario, axis 0 is using the high-speed inputs and axis 1 is using RMP’s user limit to capture the position. (I don’t have a reason to think that’s making a difference.)
The curious thing here is that I cannot find any indication that I’m sending axis #0 to the position that MotionScope reports as the commanded position. None of my position data looks like this.
Here’s a plot of the scope data.
The green line is axis 0 commanded position.
For the sake of troubleshooting timing, I have recently added writing data to user buffers so that I can correlate events in my code with what the scope is showing.
The “Status” section of the plot visualizes this data (basically as a boolean).
Here’s the same data, zoomed in to the point in time where the jump happens.
The input we’re using for the user limits is labeled “T7X12_Probe0”. The other bits that I’m setting are in my code, some of which are handlers that get called when a user limit interrupt/event comes in.
What I see here is that shortly after the input changes, the commanded position changes. But the commanded position changes before my handler indicates that it’s started (Motor_0_ProbeUserLimitHit). From my perspective, it almost seems to happen before I could have done anything (directly) to cause it.
This is a complex scenario that I cannot easily make simple, so I won’t suggest that I have assurance of the source of the problem.
What I do know is that at no time did I ever send motion points (via
MovePT()) that include any other position for axis #0:2018214 and axis #2:-444223. There is no reference in my code to
Axis::CommandPositionSet(). The user limits are not configured to change positions or anything else. One of them captures the axis position (via
MotionController::UserLimitInterruptUserDataAddressSet()). I don’t know how the commanded position for axis 0 was changed. It is conspicuous that it was set to exactly the commanded position for axis 2, but I don’t know that it proves anything.
I don’t know how this is happening. It’s conceivable that my application is at fault, but I can’t think of a way to show that I’m causing the jump.
It’s conceivable (though unlikely?) that my
MemorySet() calls could do something destructive like this, but the addresses get set once just after the program starts and are used without being modified thereafter.
I didn’t attempt to capture user limit config and log it, so I can’t say that the user limits definitely weren’t misconfigured. I’m using the same function every time to configure them, though.
Can you suggest some kind of data I could gather or test I could run that might make it easier to find the cause of this problem?