motor[i].MasterCtrl question

I have a motor driving a z-axis in a cutting application, we are cutting a curved part; cut pressure is controlled by an air-spring. As the cutting wheel rides over the part, the air-spring compresses or extends, this displacement is read by an encoder, which our z-axis motor is slaved to during the cutting process. The motor[x].MasterCtrl bit is turned on/off to control whether the z-axis motor is in following mode.

Now for my problem:

It appears that following is still enabled, even if MasterCtrl is set to 0. See the attached pdf for a plot of the move profile. Motor[4] is the z-axis. "zRaisePos" is the programmed raise position the motion program uses to position Z. As you can see from the plot, after the MasterCtrl bit is turned off, the actual motor position overshoots the programmed position. But only for the first move after MasterCtrl is turned off. During all subsequent moves, the z-axis motor returns to the proper home position. "zRaisePos" does not change at all during the moves.

Here's a code snippet from the motion program that raises the z-axis:

zRaisePos = -2.5;

Motor[4].MasterCtrl = 0; // turn off following

//call timer(0.2);

begin 2:10; // raise z

run 2;

Motion program 10:

open prog 10

cs2ProgramRun=10;

N10;

abs; // absolute move mode

ta50;

ts10;

F100; // set feedrate

z(zRaisePos); // move z axis to home point

dwell0;

cs2ProgramRun=-10;

N-10;

close

To me it looks like the motor is still being affected by the master encoder, even though MasterCtrl is turned off. Is there any other reason to explain the overshoot right after following is turned off?

Thank you,

Kmonroe

zAxis Profile 2.pdf

I see that you have a timer delay commented out. Does a delay or dwell (not sure where you are sending this from) make a difference?

I would test this manually:

- Set the MasterCtrl=0 from the terminal window, do you see a physical jump?

- Issue a PMATCH, do you see a position change?

- Jog the axis to home position (or run program 10), always from terminal, while plotting. Do you see the position overshoot?

Is the virtual motor assigned to a coordinate system other than the one which the Z-axis is assigned to?

Hello Richard,

The delay did not seem to make much difference, so I took it out.

If I jogged or moved the axis from the terminal window, I did not see the overshoot. Which is why I was so perplexed about why it was happening when invoked via the program.

But your comment about PMATCH made me think....the raise program (program 10) is called via a custom g-code from a motion program running in Coordinate system 1 (the top snippet shown in the OP is from the g-code routine). The Z-axis is in coordinate system 2. I may try to add a PMATCH command to the raise program and see if that fixes the problem. Is there some reason why the z-axis position would not be re-calculated if the cs2 program is called from coordinate system 1?

I fought this problem some more today. As stated in my original post, I am having problems with a motor going to a programmed position after master following is used for that motor (the motor in question is the slave).

Here's a simple outline of the program (CS1 is our gantry, and our Z-axis motor (motor[4]) is assigned to CS2).

1. Program started in CS1, custom G code called to lower Z-axis to part. The CS2 program is started in the normal way (begin 2:10; run 2).

2. When the z-axis is lowered, motor[4].masterctrl is set equal to 1, and the gantry runs our profile to perform the cut.

3. When the cut is finished, motor[4].masterctrl is set equal to 0, then another custom G-code is called to raise the z-axis.

Step 3 is where things don't work correctly, the axis does raise but it never gets to the target position, its always several millimeters away. I've plotted the actual and commanded motor positions, and the PMAC is actually commanding the motor to run short. For example, my raised position is -2.5mm, but the motor only goes to about 5mm and stops.

It appears to me that even though following is turned off, there is still some offset getting applied to the axis position. There are no other transforms, offsets, or kinematics applied to CS2.

If I jog the motor from the terminal, the motor runs right to the target position.

I did get our machine to run, but my solution was ugly. Instead of calling a motion program, I run jog commands from a script PLC; the jog commands are nested inside of a while loop that says 'if my motor isn't high enough, jog again!'. Ugly, but it works; I also have a counter in the loop that will bail if it goes through more than 100 iterations, this keeps my PLC from getting stuck. Strangely, jog commands issued by the script PLC still exhibited the position offsets, if I jogged from the terminal command line, the motor went right to the designated position.

My question is: what the heck am I missing? If I turn following off for a motor, shouldn't it just be off? What could be adding or offsetting my motor commanded position? Multiple jog commands work, but why?

Help!

Thanks

Kmonroe

I have been trying to figure out where this problem is coming from. I will say that it is far more common in this type of application to put the motor in following mode with Motor[x].MasterCtrl = 3 so it is in "offset mode", permitting the following and any trajectory to superimpose. In "normal mode", any motion command, even an implied zero-distance command, tries to take out what the following has put in. This might be creating the

So please try the following in offset mode. Make sure that a "pmatch" command is executed, either explicitly or implicitly (as when starting a motion program), each time the mode is changed. In most of these applications, you changing activation and mode at the same time (MasterCtrl between 0 and 3), so that is when you must make sure the "pmatch" is executed.

Curt, thanks for the info.

I did try your recommendation and it seemed to have fixed my problem. I'll need a little more run-time on the machine to verify it completely, but for now it appears to function as I originally expected.

Thank you

After a little more run-time on this machine, I had to go back to using jog commands in a script PLC to run the motor to its programmed position properly. Even using masterCtrl=3 seemed to result in the motor overshooting its programmed position in some cases when running a motion program.

Curt, thanks for the info.

 

I did try your recommendation and it seemed to have fixed my problem. I'll need a little more run-time on the machine to verify it completely, but for now it appears to function as I originally expected.

 

Thank you