RTC6 boards
Doc. Rev. 1.0.21 en-US
12 Troubleshooting
868
Additionally, the following commands are helpful for
troubleshooting:
• By get_error and get_last_error, nearly any
command can be checked for proper execution,
see Chapter 6.8 ”Error Handling”, page 130.
• By set_verify, you can verify that all downloads
(commands, tables) were performed error-free,
see Section ”Download Verification”, page 131.
• By get_value or get_values, you can query
specific values returned from the scan-system. By
set_trigger/set_trigger4/set_trigger8 and
get_waveform, you can record an entire series of
return values, see Section ”Status Monitoring and
Diagnostics”, page 183 (for iDRIVE scan systems
see also Chapter 8.1 ”iDRIVE Functions”,
page 212).
• By set_wait and get_wait_status, you can check
if program branches (conditional jumps)
executed as intended.
• By get_overrun, you can check if overruns of the
10 µs clock cycle occurred, see Section
”Clock Overruns”, page 182.
• By get_status or get_out_pointer, you can
determine which command number the program
is currently executing (for example, for “infinite
loops“ due to a circular argument in the program
flow).
• get_startstop_info provides information about
the Laser Control Signals and possible
transmission errors to and from the attached
scan system.
If specific outputs from a port have no effect, then
check if the user program is performing directly
consecutive accesses of that same port. Because so-
called short list commands (see Section ”Normal,
Short, Variable and Multiple List Commands”,
page 302) are typically used for this, one command
might overwrite the other’s output value within the
same 10 µs clock cycle. In this situation, separate
both short commands with a (normal) list command,
for example, list_nop or list_continue.
If the execution time (measured by
save_and_restart_timer and get_time) does not
correspond with your calculation, check if your
user program contains so-called short
list commands, which generally do not require their
own clock cycle for execution. Another possibility is
that additional Scanner Delays were automatically
inserted to prevent (improper) overlap of LaserOn
and LaserOff, see Section ”Automatic Delay
Adjustments”, page 155.
If the problems persist, contact SCANLAB.
To Next Page
Loading...