121
*LAStart
NS
F1
WTPipe Flow
F3
CM3,0
DV1,5,0,1,1
F1
*LAloop
*GR100,tb
*GTloop
*LAtb
NS
F1
CA
WTTea Break
CM7,0
WTPress 1 To Cancel
NA
*WK1,100
*GTStart
In this example the text display will show the cyclic data value for variable 1 on the screen for the user to monitor the
process. At tea break time the host sets the jump register to 100, the script engine sees this and changes the screen to
display “Tea Break” and asks the user to press key 1 to cancel the message. If the operator is present and presses 1 then
the process monitor screen is returned. However if there is no-one there to press the key, then script engine will restore
the process view after 10 seconds.
Events
In the examples presented so far, everything has been sequential and things only happen when the script engine
executes a line of code. The script engine can not act on a key press until the script gets to a point where it checks for
any presses with a
*GK
type of command. While this works in many simple applications it is often not the preferred
method of operation.
A mechanism to interrupt the program flow when a particular event has occurred has been incorporated. An Event is an
external influence, which redirects the operation of the script engine immediately. There are two external influences that
can trigger an Event; a key press and the host setting the Event Register.
The Event Register can support a maximum of 20 events. Like the Jump Register, the Event Register is set with the
<SE
n
>
Set Event command where
n
is in the range 1 to 20. Once the event has been seen by the script engine, the event
register is cleared to 0. Events are enabled with the
*EE
n
,
m
,
label
command, where
n
= 0 to respond to a key press
event, and
n
= 1 to respond to the Event Register;
m
= the number of the key or register and
label
is where the script
engine is to jump to.
Once the event has occurred and the script engine has finished executing the instructions ,it needs to do nothing until the
next event occurs. This can simply be achieved by using a label and a goto, but this keeps the script engine busy and
occupies valuable script memory. It is possible that the text display may be dealing with cyclic data while doing all of
this which may affect the perceived responsiveness of the instrument. To lessen the load on the processor, there is an
idle state for the script engine:
*BI
Become Idle tells the script engine to nothing except watch for an external event.
Script Event Update (Firmware 3.4 Onwards)
One problem with the <SE
n
> command is that the event is always executed when the command is sent. There are
applications on some small PLC's where it would be helpful if the event was only executed when the value of
n
was
updated to a new value.
This has been implemented by defining a new set of values for
n
. If
n
is in the range 21 to 40 then event (
n
-20) will be
executed once and then not again until the event number is changed, regardless of the number of times the command is
executed.
