Variable (Boolean or Float)

Operator Menu Location: Signal Reference

Operator Bitmap:

 

Functional Description:
The Variable operator stores a signal value that can change during schema execution. For instance, it may store a system set-point or tuning parameter that a plant operator or design engineer may wish to modify at runtime.

Multiple Variable operators can reference the same signal value provided they have the same name and scope. In the sample schema pictured below an error signal is computed and stored in a Float Variable named fError_l. Another Float Variable operator elsewhere in the schema has the same name, fError_l, and sources a Numeric Display operator. While the two Variable operators are distinct objects in the schema, they reference the very same error signal---namely the difference between process (PV) and setpoint (SP) signals, so that the value computed by the Subtraction operator is shown on the Numeric Display.

In other words, the two instances of the fError_l variable are akin to explicitly connecting a signal wire between the output of the Subtraction operator and the input of the Numeric Display operator as shown below.

The use of Variable operators as virtual signal connections is a good technique for making schemas more readable. It offers an alternative to direct connections, thereby avoiding situations where signals must cross over each other or where long connections must be used to zigzag around other objects.

Variable operators not only serve to bind signals within the same schema, they can also bind signals across schemas and/or across modules in a node. In other words, they allow a signal computed in one schema or module, to be referenced in another schema or module. Variable operators have a scope attribute that determines their access range---Local, Module, or Global. A variable with Local scope may only be referenced within the same schema document. A variable with Module scope may be referenced within any schema executing in the same module (i.e., the parent schema linked to the module, any of its sub-schemas, or any of its sub-schemas' sub-schemas.). A variable with Global scope may be referenced within any schema executing within any module in the same node.

Design Pad automatically appends the characters "l", "_m", or "_g" to the Variable _signal name according to its scope, Local, Module, or Global, respectively.

In addition to binding signals from disparate schemas, Boolean Variable operators also serve as the triggering mechanism to initiate a transition in a state-transition diagram. In this context, a Boolean Variable is bound to a transition arc in the diagram. The transition is activated when the variable value is HIGH. Please see the help reference for the Sub-Schema State operator for more information and examples. Also refer to the help reference for the Sub-Schema Function Block operator for examples on the use of Variable operators to bind signals between a schema and its sub-schema(s).

A key motivation behind the use of sub-schemas is that they promote program re-use. The idea is that re-using code can drastically reduce development and testing time. Moreover, if a bug is ever found within a sub-schema it only needs to be corrected in one place, thereby simplifying code management. Because Variable operators serve as the glue that bind sub-schemas together, they also play an important role in program re-use. Proper selection of variable scope is a critical factor in maintaining re-usable code. The operator scope should have the minimum range required to achieve the desired objective. If a variable is not needed outside of the schema in which it resides, it should be assigned Local scope. This avoids the possibility that when a sub-schema is re-used in a different application, a variable with Module or Global scope is not inadvertently bound to another variable with the same name and scope in the other application.

The available scope settings on their own are sometimes not sufficient to achieve re-use. For instance, consider an application where four identical machines are to be controlled. The ideal approach from a re-usability standpoint is to implement the algorithm in a sub-schema and to reference that same sub-schema four times.

Suppose the algorithm were best implemented as a state diagram, as shown below, with a transition bound to a Boolean Variable named bTaskComplete_m having module scope.

Suppose the variable bTaskComplete_m necessarily had to have module scope because its state (LOW or HIGH) could only be determined within the sub-schema file associated within state State B. But the assignment of module scope to bTaskComplete_m creates a problem. Remember that the same state-diagram is to be referenced by the four sub-schemas, meaning that four distinct instances of this same state diagram are to execute concurrently and independently. However, because bTaskComplete_m has module scope, every appearance of that variable is interpreted as a reference to the very same signal. As a result, Design Pad will bind together each and every instance of the bTaskComplete_m transition, such that machine operation will be incorrectly coupled and the schemas will not execute as expected.

This problem can be solved by using the Prepend Name property of Variable operators and (optionally) enabling the namespace feature of sub-schema operators. As its label implies, the Prepend Name property prefixes the variable name with the node name, module name, sub-schema namespace, or a combination of these. The resolved name (i.e., the combination of the Prepend Name and Signal Name properties) can then be used to uniquely identify a variable reference.

The problem in the example described above can be rectified by activating the Namespace property of the Function Block Sub-Schema operators, setting the Prepend Name property of the bTaskComplete_m to Namespace, and setting the Naming drop-down combo in the Transition Properties dialog box to Namespace. Then, the resolved names for the problematic operators would be unique: Machine A.bTaskComplete_m, Machine B.bTaskComplete_m, Machine C.bTaskComplete_m, and Machine D.bTaskComplete_m.

Another example usage of the Prepend Name property to promote program re-use is shown below. Consider a hardware interface file consisting of three PCM-1 modules, one NIM-1 module, and one ACP-1. The NIM-1 module is to monitor the health of the three PCM-1 modules that are to control identical machines. Since each of the PCM-1 modules perform an identical function, it is desirable to associate them all to the same schema file. This schema file generates a heartbeat signal to be monitored by the NIM-1 module, as shown below:

The heartbeat signal, named bHeartbeat_g is assigned Global scope so that it is accessible from the NIM-1 module. But if the same schema is assigned to the three PCM-1 modules, each module would attempt to set the value of the same global variable named bHeartbeat_g. In order for the heartbeat signal variable to be unique to the module that sources it, the Prepend Name property of the variable must be set to Module so that the module name is used as a prefix to the signal name. The fully resolved name will be PCM-1A.bHeartbeat_g, PCM-1B.bHeartbeat{}g, or_ PCM-1C.bHeartbeat_g.

Then, the schema linked to the NIM-1 module should contain three namespace-enabled Function Block Sub-Schema operators with names to match the module names as follows:

Each of these Function Block Sub-Schema operators can then be linked to the same schema file that contains a circuit used to monitor the heartbeat signal:

Note that in this case, the Prepend Name property of the bHeartbeat_g operator is set to Namespace, such that its name is prefixed with the name of the sub-schema. The fully resolved name will be PCM-1A.bHeartbeat_g, PCM-1B.bHeartbeat_g, or PCM-1C.bHeartbeat_g, to match the source signal names.
In the preceding examples, there were instances of Variable operators where the input pin x was visible but the output pin y was not, and vice-versa. A Variable operator may be of type Input-Only, Output-Only, Input-Output, or None. The type determines if input pin x and output pin y are visible in the schema and serve a purpose. When input pin x is connected, the internal variable value is set equal to the value of x as dictated by enable input e. If input e is not connected, the internal variable value is set to x every time the operator computes. If input e is connected, the internal variable value is updated according to the Enable On property---see the operator properties section below. Obviously, when output y is visible, it can be used to feed the input pin(s) of other operators with the signal value the variable represents.

Great care must be taken when connecting input x of two or more distinct Variable operators that represent the same signal (i.e., they have the same fully-resolved name). Consider the schema below in which two distinct operators representing the same signal are fed by different constant values.

If a device were to execute this schema, what value (3 or 5) would fSignal_m assume? The answer is not definitive---it depends on which operator executes last. In fact, if the schema contained several other operators, the result would be even more unpredictable as it is possible that the execution order could have one Variable first, then other operators, then the second Variable, then other operators. So the signal value could be 3 during part of the computation cycle that some operators compute and 5 during part of the cycle that other operators compute.

Design Pad explicitly disallows the same variable signal from being set in multiple locations within the same schema. That is, an error is issued at compile-time when the schema above is processed. However, the ability to set the same signal from different sub-schemas is quite desirable so Design Pad allows it. For example, it may be desirable to set the same signal to a different value depending on which state sub-schema is currently active.

Like most operators, Variable operators have various attributes that may be specified in the properties dialog---a list of such properties is enumerated below. In addition, to these operator-specific properties, there are several settings that related apply to the set of operators that reference the same signal. These attributes are specified in the Variable Settings and are also enumerated below. There are actually three distinct Variable Settings dialogs, one for each type of variable scope. For variables of Local scope, the dialog is accessed from the Schema menu (select the Local Variable Settings item). For variables of Module, and Global scope, the dialog is accessed from the module drop-down menu in the hardware interface file view,

User-Defined Properties:
Signal Name. A string label that identifies the operator+.+ Multiple Variable operators with the same signal name are treated as the same object--subject to the

Scope and Prepend Name property settings below.

Variable Type. Indicates if the Variable is to serve as a signal source (Output Only), signal sink (Input Only), both (Input-Output) or neither (None). Operator input x is visible if this property is set to Input Only or Input-Output. Operator output y is visible if this property is set to Input Only or Input-Output.

Scope Access. Determines the operator's access range, Local, Module, or Global. A variable with Local scope may only be referenced within the same schema document. A variable with Module scope may be referenced within any schema executing in the same module (i.e.,the parent schema linked to the module, any of its sub-schemas, and any of its sub-schemas' sub-schemas.). A variable with Global scope may be referenced within any schema executing within any module in the same node. Design Pad automatically appends the characters "l", "_m", or "_g" to the _Signal Name according to its scope.

Display Enable Input. Determines if input pin e is visible in the schema diagram. Design Pad issues a warning upon processing the schema when the pin is visible but not connected. The warning message is not issued when the pin is not visible (when this property is not checked).

Enable On. Enable input e may be optionally used to manage updates to the parameter value. The operator can be configured to update its stored value on an edge-trigger (rising edge or falling edge) or logic state (active LOW or active HIGH). For instance, if Enable On is set to Rising Edge, then the variable value will only be updated with the value of input x, during the instant that input e switches from LOW to HIGH.

Initialization Behavior. Determines if the initial variable value is set by the User-Defined Initial Value property (specified in the Local/Module_/Global Variable Settings Dialog---see below) _or by input x (valid only if x is connected).

Instance Note. Text used to document the application. This text is displayed as hover help when the mouse-cursor is placed over the operator graphic_._

Prepend Name. Indicates if the Signal Name is to be prefixed by the module name, node name, sub-schema namespace, or a combination thereof. When Namepace is selected, the Signal Name is prefixed with the name of each namespace-enabled sub-schema _(state or function-block) along the path from the schema that contains the _Variable operator to the topmost parent schema. In the four-machine example described in the text above, only the name of the Function Block Sub-Schema operator is prepended to the signal name: Machine A.bTaskComplete_m. If the State Sub-Schema operator were also namespace-enabled, then its name would also be prepended to the signal name: Machine A.State B.bTaskComplete_m.

Resolved Name. Displays the full name of the signal, formed prefixing the Signal Name property with the Prepend Name property.

Variable Settings Dialog:
Data Type. The variable's data type, Boolean or Float. This is a read-only column in the dialog.

Signal Name. The fully resolved signal-name (see Signal Name, Prepend Name, and Resolved Name properties of operator.) This is a read-only column in the dialog.

Initial Value. The value the variable should be set to when the schema it is in first executes.

Link Access. Future expansion.

Browse Access. Indicates if the variable value can be accessed when using an ad-hoc HMI.

Update in Flash. Indicates if the variable value is to be stored in non-volatile memory such that it is retained when the device is powered off. Three setting are available: None indicates that the variable is not to be saved in flash; On Command indicates that the variable is to be recorded on Flash Save operator command; On Command + Power Loss indicates that the variable value will be store in flash when explicitly commanded by the Flash Save operator or when the device is powered off (intentionally or unintentionally). When the device loses power, it has precious little time to perform clean-up operations, such as saving critical variables to non-volatile memory. The quantity of variables that can be designated as critical is limited and depends on the target hardware.

Merge Behavior. When downloading a node configuration file into the target hardware, the user can elect to first erase the configuration being replaced, or to merge the old configuration with the new. The latter option is useful if software updates must be made "on the fly"---while maintaining control over the machinery it is connected to. This property indicates what should be done with the variable value if the node configuration files are to be merged. There are two options: Leave Existing and Reset to Default. This first option is the default and maintains the variable value stored in the device (useful for setpoint settings, etc). The second option resets the variable to the value stored in the new configuration.

Access Level. Node configuration files may contain a password to prevent unauthorized access to modify certain parameters. When this property is set to Operator, anybody is free to modify the variable value. When this property is set to Engineer, a password is required to modify the variable value.

Instance Note. User notes that serve as documentation. The notes are incorporated into the hover help box that is displayed when the user positions the mouse over the operator graphic. This note applies to all instances of a Variable operator with the same Signal Name. (As opposed to an Instance Note property associated with a specific instance of an operator.)

Comments:
None.

See Also:
Sub-Schema Function Block, Sub-Schema State, Structure Variable