How does the RMP EtherCAT master handle rollover (overflow/underflow) in the axis encoder position reported to it by the drive?
My observation is that when overflow/underflow occurs, RMP just increments/decrements its axis position by the counts delta. So far, so good.
What happens if the reported encoder positions jumps? You could call any change in encoder position a jump, but what if it suddenly jumps from some big value (that’s not on a integer overflow boundary) all the way to zero?
Actual Situation
I’m adding support for encoder cards to our application. The cards support setting the reported encoder position to an arbitrary value.
While I was trying to test overflow/underflow, I got into a situation where the axis position reported in RapidSetup was very, very large, and resetting the reported encoder value did not change the RMP axis position.
I didn’t take thorough notes, so I don’t have more detailed information to provide, but supposing that I didn’t dream this, can you help me understand how RMP deals with raw encoder positions and maintains an axis position based on changes to that value?
You’re correct about RMP using delta changes for 32-bit encoder values.
Is your encoder position (on the PDO) a 32-bit value? If not, you can optionally give the size (in bits) in your CustomNodeInfo’s PositionActual entry. Here’s one I found in NodeInfo.xml:
I’m probably not describing my situation well enough.
The reported encoder position (from the device) is a 32-bit value. Overflow/underflow seems to work as one might expect: RMP maintains an axis position as a 64-bit double, modifying it by deltas in the reported encoder position change.
My question is about what I should expect if the reported encoder position “jumps” (outside of standard overflow/underflow).
If the device reports an encoder position of 1,000,000 and then it changes its reported encoder position to 500,000, what will RMP do to the axis position it maintains?
How does RMP recognize when overflow/underflow occurs? Does it pay attention to the bit width of the reported encoder position?
In the case of your example, the RMP EncoderPosition would decrease by 500,000 for that sample. It does not pay attention to the bit width. So long as the delta is under 2^31 it will maintain that behavior.
If your raw 32-bit value is going to have a big jump like that, you’d probably want to use OriginPositionSet() (assuming you were causing the jump intentionally on the endoder device).
I don’t know that I’m going to want to do this much, but the behavior that I observed confused me. I just wanted to make sure I had informed expectations of RMP in this scenario.
Thanks, Scott.