RESOLVED - fastest way to start motion on trigger input

[hannsx]

Hi,
I am using a PowerBrickLV in combination with a linear motor. The encoder resolution after 4xinterpolation is 50nm.
I move my Motor to the starting position for the move. Then I start the motion program:
-------------------------------------------------------------------------
open prog 2

rapid;
abs ;
Motor[1].JogTa = -0.01 :
Motor[1].JogTs = -0.01 ;
Motor[1].JogSpeed = ScanVelocityMs ;

while( StartScan == 0 ){ } ;

Y( ScanDestination ) ;

close
-------------------------------------------------------------------------
I thought it may be the faster way to get the move started after the StartScan bit is changed to 1, compared to querying the value in a PLC and starting the program from there. The reason why I think so ist that when I look at the program interrupts scheme, the motion program calculations start before the PLC - programs are run. Another reason is that, if the while-loop is iterated multiple times in the time slot allocated for the motion program calculations, the motion would start immediately if the StartScan value changed in the process of iterating. In a PLC on the other hand the StartScan would only prompt the starting of motion program 2 and the motion would then start on the following rti - interrupt.

Am I making the right assumptions here? If you know a faster way to start the motion please tell.

And I wonder if the while-loop is iterated multiple times in any real-time-interrupt, either in a motion program or a PLC.

Best regards,
hannsx

[curtwilson]

I think your best approach is a hybrid one, using a twist.

In your motion program, first set both Coord[x].DesTimeBase (target time base value) and Coord[x].TimeBase (immediate time base value) to 0. (We call this "freezing the time base", basically like issuing a "%0" command.)

Next, set some kind of internal flag so a PLC program can start looking for the trigger.

Finally, issue the move command in the program. PMAC will calculate all the equations of motion for the move and put them in the execution queue, and motion program calculations will automatically be suspended.

At this point, the move execution has technically started, but it is "stuck" at T=0.

Now your real-time PLC program, executing every RTI (Sys.RtIntPeriod=0), looks for the trigger, and when it sees the trigger go true, sets both Coord[x].DesTimeBase and Coord[x].TimeBase to Sys.ServoPeriod.

In the interpolation calculations of the very next servo cycle, "time" will increment by Sys.ServoPeriod, starting true execution of the move.

This should be a servo cycle or two quicker response than other methods you might try.

[hannsx]

Thank you for the help - that surely is a nice approach I wouldn't have thought of. Do you know if loops written in a motion program or a plc are iterated multiple times in one rti?

[curtwilson]

For motion programs, saved setup element Coord[x].GoBack specifies how many times you can loop back in a single RTI.

For PLC programs, local element Ldata.GoBack (externally accessed as Plc[i].Ldata.GoBack) specifies this for a single (foreground or background) scan of a PLC. You must set this inside the PLC.

In this technique, I don't think multiple loops will be of much help.

[hannsx]

Ok - that's what I searched for. Thank you for the information and your advice.