Delta Tau GEO BRICK LV User Manual
Turbo PMAC User Manual
356
Synchronizing Turbo PMAC to External Events
Synchronizing with External Time Base
If synchronicity is desired in an application where axes on several cards are tied to an external frequency
time base, the same frequency signal must be brought into encoder counters on all cards. If it is not also
required to have complete synchronicity when on internal time base, there is no need to tie the Turbo
PMAC clock signals together, because the external frequency will provide the common clock.
time base, the same frequency signal must be brought into encoder counters on all cards. If it is not also
required to have complete synchronicity when on internal time base, there is no need to tie the Turbo
PMAC clock signals together, because the external frequency will provide the common clock.
Motion Program Timing
Whether or not cards share a common clock signal, the synchronization of moves between multiple cards is
only as good as the time specification in the motion programs in each card. If one card is told to do a 3-
second long move, and another to do a 4-second long move, and they are started at the same time, obviously
they will not finish together. Therefore, it is imperative that motion programs on several cards that are
intended to run together must be written carefully so as to take the same amount of time for moves.
only as good as the time specification in the motion programs in each card. If one card is told to do a 3-
second long move, and another to do a 4-second long move, and they are started at the same time, obviously
they will not finish together. Therefore, it is imperative that motion programs on several cards that are
intended to run together must be written carefully so as to take the same amount of time for moves.
Initial Calculation Delay
After receipt of a Run or Step command, a Turbo PMAC requires some initial calculation time before it
can start the first move – typically a few milliseconds. If several Turbo PMACs are told to start a
program simultaneously, the cards will in general not take the same amount of time to calculate their first
move. If each card started its first move immediately on finishing the calculations, there would be a loss
of synchronicity between cards. Turbo PMAC parameter I11 (Motion Program Calculation Delay) exists
to prevent this problem. It determines the number of milliseconds between the receipt of the Run or Step
command, and the start of the first move. I11 should be set to the same value on all cards for which
synchronicity is desired; the default value of 10 (=10 msec delay) can be used in virtually all applications.
(If I11 is set to 0, the first move starts immediately after calculations are finished. Typically, this is OK in
single-card applications, but not in multi-card applications.)
can start the first move – typically a few milliseconds. If several Turbo PMACs are told to start a
program simultaneously, the cards will in general not take the same amount of time to calculate their first
move. If each card started its first move immediately on finishing the calculations, there would be a loss
of synchronicity between cards. Turbo PMAC parameter I11 (Motion Program Calculation Delay) exists
to prevent this problem. It determines the number of milliseconds between the receipt of the Run or Step
command, and the start of the first move. I11 should be set to the same value on all cards for which
synchronicity is desired; the default value of 10 (=10 msec delay) can be used in virtually all applications.
(If I11 is set to 0, the first move starts immediately after calculations are finished. Typically, this is OK in
single-card applications, but not in multi-card applications.)
Time-Specification of Moves
In general, moves in these programs should be specified by move time (TM, TA, and TS), and not by
feedrate (F). The time for a feedrate-specified move is calculated as the vector distance of all feedrate
axes (FRAX) divided by the feedrate. It is difficult to ensure that such moves on separate cards will take
the same amount of time.
feedrate (F). The time for a feedrate-specified move is calculated as the vector distance of all feedrate
axes (FRAX) divided by the feedrate. It is difficult to ensure that such moves on separate cards will take
the same amount of time.
DWELL is a non-synchronous move and should not be used when writing programs for multi card
applications. Use the DELAY command to maintain program synchronicity.
applications. Use the DELAY command to maintain program synchronicity.
No-Drift Conditions
If motion programs are written carefully, using time-specified moves, and the cards share common clock
signals, they can run indefinitely with no drift between the cards. There can be an initial offset between
the cards of up to a few msec as to when they start their motion programs, even with simultaneous
commands, but this offset will not increase with properly written motion programs and shared clock
signals. The following section explains how to minimize (and usually eliminate) this offset.
signals, they can run indefinitely with no drift between the cards. There can be an initial offset between
the cards of up to a few msec as to when they start their motion programs, even with simultaneous
commands, but this offset will not increase with properly written motion programs and shared clock
signals. The following section explains how to minimize (and usually eliminate) this offset.
Minimizing Initial Offset
Turbo PMAC cards told to start a program simultaneously usually will do so on the same servo cycle
providing that no PLC programs are enabled. Programs that do not start on the same servo cycle will start
at the next real time interrupt. This will be ((I8 + 1) * servo cycle length)
providing that no PLC programs are enabled. Programs that do not start on the same servo cycle will start
at the next real time interrupt. This will be ((I8 + 1) * servo cycle length)
µs later. If PLC programs are
enabled, the starting offset between cards could be as much as the amount of time the longest PLC
requires to run and be translated. A good method for eliminating an initial execution offset is as follows:
requires to run and be translated. A good method for eliminating an initial execution offset is as follows:
•
Initialize all program counters on all Turbo PMAC cards. For the simple case of the same program
with the same name on each card enter @@B1<CR>. A more complicated case might be
@0B1@1&3B2<CR>.
with the same name on each card enter @@B1<CR>. A more complicated case might be
@0B1@1&3B2<CR>.
•
Disable all PLC programs using <CTRL-D>. This will give the fastest possible response to a
command.
command.