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. In this section, we introduce the concept of sub-schema namespaces as a means of promoting re-use.
But before taking up the subject of sub-schema namespaces, we shall consider the role of Variable scope. 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.
(a)
(b)
Figure 5.15. (a) Example schema with four function-block sub-schema operators.
In Figure 5.15, each sub-schema operator references the schema in (b) with a state-transition diagram having a transition (labeled bTaskComplete_m) that is linked to a Boolean variable of 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 with state operator labeled 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 G4 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 sub-schema namespaces and the Prepend Name property of Variable 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 in Figure 5.16. Consider the hardware interface file consisting of three PCM-1 modules and one NIM-1 module as shown in Figure 5.16a. 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 in Figure 5.16b:
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 show in Figure 5.16c. Each of these Function Block Sub-Schema operators can then be linked to the same sub-schema file (shown in Figure 5.16d) that contains a circuit used to monitor the heartbeat signal:
(a)
(b)
(c)
(d)
Figure 5.16. (a) Hardware interface file with 3 PCM-1 modules and 1 NIM-1 module;
(b) Schema linked to each PCM-1 module; (c) Schema linked to NIM-1 module;
(d) Sub-Schema document linked to each Function-Block Sub-Schema operator in (c).
Note that in the sub-schema of Figure 5.16d, the Prepend Name property of the bHeartbeat_g operator is set to Namespace, such that its name is prefixed with the name of the corresponding sub-schema operator in Figure 5.16c. 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.
Aside: The example above is used to illustrate the use of Namespaces. Detecting the health of a neighboring module is best done by using the Module Active operator (see the Design Pad Operator Reference, publication PDG-R-2011/13).
