rapid move subroutine

[kmonroe023]

I have a subroutine written in the Libraries folder that performs a RAPID move with a trigger: z(position)^-0.1.

 

If I call the subroutine from a PLC, it runs as expected, the motor runs until the trigger and stops, then backs up 0.1mm.

 

However, I really need to be able to call this subroutine from a motion program and have it work like it was called from a PLC. I tried to call it from a motion program and nothing happens. I assume the subroutine runs as a motion program if is called from a motion program, and the PMAC chokes on the Rapid command when doing this.

 

Is there anyway I can call a subroutine from a motion program and have it run as a PLC, so the Rapid move command works??

 

Thanks,

Kmonroe

[tahoe brian]

Please note that the G, M, and T commands in PMAC are essentially motion program subroutine calls to a specific subprogram, program number depending upon whether G, M, or T. You could make a custom G code, i.e. Gxx that calls the subprogram. Another option is the CALL command. Then in your subprogram you will be issuing a CMD"z(position)^-0.1". There are some details that you will need to work out, but this is the gist.

[kmonroe023]

Thanks, that makes sense Brian.

 

I'm already using a custom G-code to call the subroutine. I'll experiment a bit and see what I can come up with.

[curtwilson]

There should be no reason why you cannot execute a RAPID mode move from a motion program or its subroutines and subprograms. People do it all the time. You should not need to use the CMD"" structure in a motion program to execute a RAPID mode move, even a triggered move.

 

A couple of notes on the differences between PLC program execution and motion program execution that you should be aware of:

 

Commanding a move in a PLC program automatically puts the addressed coordinate system (Ldata.Coord) into RAPID mode. In a motion program, you must explicitly declare RAPID mode.

 

At the start of execution of a motion program, the PMATCH function is automatically executed to calculate the starting axis position(s) from the present motor position(s). This does not happen in a PLC program.

 

Things like this can be tested easily from the terminal command line with the "cpx" (one-line one-shot motion program) and "cx" (one-line one-shot PLC program) functions. Try commands like:

 

&1 cpx rapid Z1000^-0.1

 

which functions as a motion program,

 

and

 

cx Ldata.Coord=1 Z1000^-0.1

 

which functions as a PLC program.

[kmonroe023]

Thanks for the additional information Curt.

 

I can get the subroutine to run fine if called from a PLC, but if it is called from a motion program, nothing happens.

 

What I think the problem is, is that the calling motion program is running in coordinate system 1, but the sub-routine needs to run a motor in coordinate system 2. I originally thought setting Ldata.Coord=2 in the subroutine would fix this; but as I thought more about it, I came to the conclusion that since the sub-routine was called from CS1, it was running in CS1 and setting Ldata.Coord would do nothing to change this. Therefore, nothing happened because the commanded axis in the sub-routine does not exist in CS1.

 

I did eventually get it workiong by setting a program flag and letting one of the PLCs call the sub-routine. Not the most elegant solution, but it works.