BindTo calls for buffered data

When working with indirect scripts to read the .buffer property of an attribute, the BindTo call needs to be used in startup instead of using it in execute. Using BindTo in execute can lead to losing the data in alternate buffers.

• Using artificial delays in the script is not recommended as this may result in script timeouts and would in turn affect UI refresh. For example, do not use a while loop that increments a variable from 1 to <60000. This could cause the ViewApp screen to go blank or become unresponsive while the script is executing.

• Instead of artificial delays, allow the whole script to continue execution across multiple cycles, without any artificial delays in the script, and set the script's expression to false once the quality of all the attributes is good.

When binding to an on-engine attribute, the whole script could be put in Execute. The following snippets show an example of using an indirect to process a buffer. In this example, the BindTo call is in Startup and FOR EACH is in Execute.

In Declarations:

dim x as indirect;

In Startup:

x.BindTo("me.attribute1.buffer");

In Execute:

dim vtq as ValueTimeQuality;

for each vtq in x

LogMessage(vtq.value);

next;

When binding to an off-engine attribute, it may take more than one scan cycle to bind and the quality of the Indirect variable must be inspected before attempting its use. When binding to an off-engine attribute, declare the reference as indirect, and test the off-engine reference quality in the body of the script. You can use a WHILE-triggered script to ensure execution, illustrated in the following example. For more information, see Bind to off-engine attributes.

In Declarations:

dim x as indirect;

dim y as boolean;

 

In Execute (while true: me.z):

 

if not y then

'This could also be done in the startup script

x.BindTo("Object1.attribute1");

y = true;

endif;

 

if IsGood(x) then

LogMessage(x);

me.z = false;

endif;