RTC
®
5 PC Interface Board
Rev. 1.9 e
6 Developing User Applications
82
innovators for industry
6.5.4 Circular Queue Mode
The RTC
®
5 does not support the circular queue mode
that could be activated on the RTC
®
3/RTC
®
4 via
set_list_mode
. But the RTC
®
5 can effectively
emulate this operational mode via an alternating list
change and the command
load_list ( 3, 0 )
ensures that – as in the
RTC
®
3/RTC
®
4’s circular queue mode – new
commands will be loaded only into an already
processed list (that isn’t BUSY), without needing to
explicitly supply the number of the list. And
continuous processing of list commands is not
hindered by the simultaneous loading of new
commands (also see
"Alternating List Changes", page
"Loading with Protection", page 72
).
Users who only want to assign the list memory’s full
capacity to a single list – as realized in the
RTC
®
3/RTC
®
4’s circular queue mode – can accom-
6.5.5 Loops
Although list jumps (see
) and conditional
jumps (see
) let you repeat any number of
list commands limitlessly or under external control,
precisely specifying the number of executions isn’t
always reliably possible. But this can be achieved with
the command pair
command sequence between these two short list
commands will execute exactly as often as specified
with the
command’s parameter, but at least
once. Here, nesting up to 8 loops deep is allowed.
The commands
and
must
always be used in pairs. Unpaired or superfluous
commands (
to a nesting depth greater than 8) will be ignored.
Empty loops (e.g.
) will terminate immediately and not be
repeated.
You can place such command pairs not only within
lists, but also within subroutines.
In subroutines,
the address directly after the associated
Loops won’t function beyond the bounds of a
subroutine, because list jumps into or out of subrou-
tines aren’t permitted (see
).
Within lists, however,
executes a
(to the address directly after the asso-
ciated
and
can even reside in two different lists, provided that
list changing is ensured via either an explicit list jump
or an automatic list change. If, on the other hand, a
list actually terminates (e.g. when using
stack will
get automatically deleted and the started loop can no
longer be ended because the next
no longer
has its associated
.
will delete the entire loop
management if no automatic list change exists, but
Explicit list jumps to a
loop’s
body or from inside a loop to a loop-external location
are permissible, but can’t be monitored. Careless use
could therefore compromise loop management
integrity so severely that started loops won’t execute
as expected (but subroutine calls from inside a loop
are always reliably possible as long as the subroutine
itself contains no unpaired
commands).
