RTC
®
5 PC Interface Board
Rev. 1.9 e
6 Developing User Applications
86
innovators for industry
6.7.1 Board Acquisition by an Appli-
cation
Though the commands
,
,
affect the
access rights or activation of the installed RTC
®
5
boards, they don’t initiate a board reset (board resets
can only be initiated via the command
). They therefore affect
neither the list memory, nor the board’s settings via
previously issued control commands. Likewise not
affected is the board’s execution of a previously-
started and currently-running list program. These
commands also don’t delete the related DLL data.
Applications subsequently acquiring a board via
or
) will
therefore inherit the board’s unadjusted memory
contents and operational state. The application
therefore has use of the board’s stored data and
settings and can intervene in the flow of any
program started by the previous application.
If an application releases a board via
subsequently reacquires it – without it having been
acquired in the meantime by another application –
then the RTC
®
5 board can be further used without
changes, because in this situation all DLL configu-
ration data remain unaltered. However, the above
does not apply if the acquired board was released via
and reacquired with
When an RTC
®
5 board is acquired by another appli-
cation, some of the previous application’s key data
managed only in the DLL will
not
(automatically) be
inherited. The acquiring application will thereby lack
information related to memory configuration,
protected-area management, or the operational
status.
If board acquisition is followed by a board reset via
, then all settings will
be newly defined anyway and such missing infor-
mation wouldn’t be relevant.
On the other hand, if the acquiring application
intends to further use the RTC
®
5 board’s inherited
state, then it may need to explicitly query the missing
DLL information, receive it from the previous appli-
cation and explicitly re-establish it so that the board’s
DLL remains consistent. In this regard, observe the
following:
• For a correct behavior of the input pointer at the
list borders, the memory configuration currently
set in the DLL for the acquiring application must
be consistent to the acquired board’s current
memory configuration. If this is not the case, use
the command
command obtains the board’s current memory
configuration and appropriately sets the DLL’s
board management for the acquiring application.
• The management table of protected functions
(indexed subroutines, character sets and text
strings) is saved on the board and therefore
inherited through board acquisition. All
protected functions stored on the board
therefore remain callable. On the other hand,
information on where the next protected
function should be loaded is lost. This infor-
mation can only be restored via
(see
). An alter-
