RTC
®
5 PC Interface Board
Rev. 1.9 e
6 Developing User Applications
87
native restoration method is not possible. The
intermixed loading of protected functions via
differing applications should therefore be
avoided.
• If, during loading a protected function, the
command release_rtc is called before a subse-
quent list_return command is transferred, then
the function will not be stored on the RTC
®
5
board.
• The input pointer will generally not be inherited
(the input pointer location currently saved in the
DLL for the acquiring application is used, maybe
corrected via get_config_list). On the other
hand, output pointers of lists can be queried after
an acquisition via get_status (page 281).
• After acquisition and until the next
load_…
command, the list status (with reference to LOAD
and READY) might be incorrect. But for further
execution this is not important, and the status
will be newly set after the next
load_…
command.
• Other settings such as start_loop or laser settings
are not relevant to the DLL. Though settings used
by the previous application can not generally be
queried, new settings can of course be estab-
lished as desired.
• Error handling is performed separately for each
board and each application (user program).
When access rights are exchanged, this data is
not included.
6.8 Error Handling
So that RTC
®
5 errors can be caught at program
runtime via suitable programming, the RTC
®
5
performs general error handling. In addition, some
commands allow for specific error handling.
General errors occur, for example, if an application
has no access rights for the board
(
RTC5_ACCESS_DENIED
), or if the board fails to
respond to a control command (
RTC5_TIMEOUT
), or if
PCI communication problems occur during loading
(
RTC5_SEND_ERROR
).
Examples of specific errors are: calling a command
with an unallowed (uncorrectable) parameter
(
RTC5_PARAM_ERROR
, e.g. see get_value or
write_da_x), or rejected loading of a list command
(
RTC5_REJECTED
, e.g. due to an illegal input pointer),
or transmitting a control command at an improper
time (
RTC5_BUSY
, e.g. goto_xy, when a list is still
being processed).
In such cases, the control commands will not be
executed; list commands will typically be replaced
with list_nop commands (e.g. for
RTC5_PARAM_ERROR
or
RTC5_IGNORED
, see
set_end_of_list as an example).
For each command, the DLL will set and accumulate
the bits corresponding to these errors in the (board-
specific) error variables
LastError
and
AccError
.
• The error code
LastError
will be automatically
reset at the beginning of every command and
therefore is a listing of occurred errors from the
most recently executed command.
LastError
can be queried via get_last_error
(1)
.
• The cumulative error code
AccError
, on the other
hand, only gets reset when the DLL is initialized.
But it can also be reset by the application via the
reset_error command.
AccError
is a listing of
errors occurring since the last error reset
(reset_error) and can be queried via get_error
(1)
.
(1) The described mechanism only applies for commands that
establish communication with the RTC
®
5. Commands that
don’t establish communication with the RTC
®
5 (e.g.
rtc5_count_cards, set_rtc4_mode or get_serial_number) will
neither generate nor alter
LastError
or
AccError
(also
see comments in the corresponding command descriptions).
To Next Page
Loading...
