RTC6 boards
Doc. Rev. 1.0.21 en-US
8 Advanced Functions for Scan Head Control and Laser Control
252
8.6.6 Virtual Image Field with
Processing-on-the-fly
With Processing-on-the-fly applications, the full value
range (29-bit) of the virtual Image Field can be used,
see Chapter 7.3.3 ”Virtual Image Field”, page 169 to
load and process command lists with objects that are
up to 512 times larger than the real 20-bit Image
Field.
With 1D Processing-on-the-fly applications (for
example, workpieces on a conveyor belt), objects can
only exceed the real Image Field in the very dimension
parallel to the Processing-on-the-fly direction.
With 2D Processing-on-the-fly applications (for
example, with an xy positioning stage), the to-be-
marked objects of a command list may be distributed
across the entire virtual Image Field.
If an entire marking task consists of several partial
markings (“tiles”) whose extent does not exceed the
real Image Field, the Processing-on-the-fly
functionality can also only be used to move the
partial marking to be marked into the real Image Field
and then process it there.
Coordinate values which are still outside the real
image after Processing-on-the-fly correction are
clipped to the boundary values of the real Image Field
Here, the get_marking_info error bits get set
automatically, see Chapter 8.6.9 ”Monitoring
Processing-on-the-fly Corrections”, page 255.
If there is a risk of the real 20-bit Image Field being
exceeded during list execution, specifically a
forwarding motion of the conveyor belt or
xy positioning stage should be executed. The
forwarding motion can be waited for with
wait_for_encoder, wait_for_encoder_mode,
wait_for_encoder_in_range or wait_for_mcbsp by
interrupting the list execution until certain encoder
values or McBSP values are reached, see
Chapter 8.6.7 ”Synchronizing Processing-on-the-fly
Applications”, page 252.
The appropriate break up of the entire marking task
and synchronization with the 1D or
2D Processing-on-the-fly movement is the task of the
user program.
8.6.7 Synchronizing
Processing-on-the-fly
Applications
Processing of command lists can be started by either
a RTC6 command or an external start signal, see
Chapter 6.4.4 ”Starting and Stopping Lists”,
page 109.
If the command list is not to be started immediately
with the start signal, then an appropriate delay may
be implemented as follows:
• When transferring positions via the
McBSP interface – by a wait_for_mcbsp at the
beginning of the command list.
• When transferring positions via encoder counters
– by a set_fly_x/set_fly_y, set_fly_2d or
set_fly_rot (to reset the counter(s)) and a
subsequent wait_for_encode
r_mode
or
w
a
it_for_encoder_in_range at the beginning of
the command list.
wait_for_encoder_in_range is useful for
2D encoder-based Processing-on-the-fly
applications. wait_for_encoder_in_range waits
until both encoders are within the specified range
at the same time and thus does not depend on
the actual Trajectory that used to reach this
range
(1)
When transferring positions via encoder
counters, a track delay can be configured (even
independently of an active
Processing-on-the-fly Session) to delay the
execution of the actual start relative to the
triggering start signal or RTC6 command, see
Section ”External Start”, page 290.
(1) If you would use wait_for_encoder or
wait_for_encoder_mode instead, you would need to
call these commands individually and consecutively for
each encoder. Here, simultaneous fulfillment of both
encoder criteria would depend on the xy
positioning
stage
motion’s explicit Trajectory and you would need
to define and reproduce an appropriate Trajectory even
before loading the lists.
To Next Page
Loading...