Thread Rating:
  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Position following in offset mode
I have a slave motor following a master using position following. I need to correct for an offset between the two, and thus I am calculating that offset after a position capture, and issuing an incremental jog to correct. So far, I have been doing this in normal mode (MasterCtrl=1), using a jogx:offset amount. However, after reading the manual, it seems using "offset" mode (MasterCtrl=3) may be a better approach. Unfortunately, I cannot get the offset correction to work when using offset mode.

1) Why would offset mode be better than normal mode for this use case? Is one more accurate in applying the offset to achieve position lock?

2) When in offset mode, should I use jogx:offset or x=desired position to make the correction? In my tests, the former does not seem to work.

3) When using offset mode, if I am to use x=desired position, I need to calculate: desired position = reference position + my offset. How do I get the reference position?
Using an incremental jog on the slave motor should correct for any offset between the two. Other than the difference in position reporting this should work the same in "offset" or "normal" following mode.
Thanks Steve.

I have tried using jogx:offset when in normal mode, and it seems to hose the motion program. It appears that the correction is made, but after that the looping in my program does not work. I also noticed that reading status like Motor[x].PosErr returns nan after this. Is it not OK to use jogx:offset in this scenario?

In normal mode I also tried using inc move mode and issuing an X[offset]. This prevents the motion program from getting hosed, but the motion response is strange. In one case an incremental move causes the motor change direction, move in the opposite direction very slowly, and then continue forward again at original speed. In another case an incremental move causes the motor to slow down for a while, then speed back up to original speed.

Note that I do have speed and acceleration limiting in place.
Keep in mind if this motor is also an axis in the motion program a jog will adjust its motor position and will require a PMATCH so the motion program will continue normally.

From your description there may be some other issue going on (Motor[x].PosErr returnig a nan). i would need to see the actual code used to properly comment on this.
Steve, after debugging a bit, I found something very interesting. In the code below, L0, L1, and L2 hold flags, L3 to hold the motor number, and L13 is the offset to apply. When the code is executed, the value of L3 is changed from the coordinate system number to the motor position! Then in the rest of my program when I try to use L3 in statements such as Motor[L3].PosErr, I get nan. What is going on?

send0"L vars %d %d %d %d %u",L0, L1, L2, L3, L13
pmatch // problem still occurs even without pmatch
send0"L vars %d %d %d %d %u",L0,L1,L2,L3,L13

L vars 1 0 0 3 2372
L vars 1 0 0 52390 2372
BTW, I modified my program to not use L3 at all, and now it works as expected. Please let me know if you are able to reproduce this issue with the L3 variable.
I was able to reproduce the problem using the following simple program:

open prog 1


home3 // Start at position 0



send0"L3 is: %d", L3
send0"L3 is: %d", L3




-0: L3 is: 0
-0: L3 is: 43299
We have tested jogging the slave motor to effect an offset works in "normal" following mode but not in a motion program. There is an issue with "offset" following mode and we are currently looking into this but this would not be the correct way to offset the slave motor anyway..

The issue with the L3 local variable is probably not related. My guess is an errent PLC is doing this.
There are no PLCs running in the system. Did you try running the same program on your end. I am seeing the same thing occur to the L0 variable after executing a "home" command in the program.

Forum Jump:

Users browsing this thread: 1 Guest(s)