See: The PmaPrototype
The simplified idea of PmaPrototype
object functionality is that when the application starts, the content of the prototype is copied into all corresponding instances, that use this prototype.
The main advantage of the prototype-instance concept is the automatic copying of the prototype into all instances on application start, so any modification done to the prototype will be included in all instances next time the application is launched. The content of the original prototype exists only in the development environment, does not exist in the running application. Only the prototype copies exist in all corresponding instances. Parametrized prototypes:
It is often necessary to ensure that instances created from the same prototype must be slightly different. The main differences are usually different texts, initialization constant values, bindings to variables, own files or database tables, trends, alarms and event groups and different scripts. For this purpose the Parameters of the Pma object
can be used, by defining a set of parameters and then the specific instance sets the real value of these parameters, valid for the corresponding instance. For defining the parameters of the PmaPrototype
objects serves the "Pma object parameters
" configurator. For reference to the Pma
object parameters the Macro expression $.par
can be used in the configurators and for the scripts the PmaObject.GetPar
method can be used. The important fact for detecting the value of the parameter is that when detecting the value of a specific parameter, the parameter is searched from the current object through the parents by a cascade way (bubbling). Caution for prototypes and instances:
object can receive only the parameters from the corresponding PmaPrototype
object, and can enter modified values
there. It means that the instance can modify the existing parameter values of the corresponding prototype. The instance, or the instance parents, cannot add new parameters. Instance (prototyp) can access only the parameters defined in the prototype, but cannot access the parameters of instance parent. This way it is ensured that all instances of the individual prototype has the same set of parameters with different values. The PmaInstance
object is therefore special from the parameter searching (bubbling) point of view, because the parameter search is terminated in this object and does not continue to the PmaInstance
object parent. This way the instance of the prototype is isolated from other parameters present in the application. If it is necessary to obtain the value of the parameter for the prototype from the instanece parent, then the parameter must be created in the PmaPrototype
object (the name can be the same or different) and refer to the parameter of the instance parent either here or in the PmaInstance
object. The reference to the parent parameter is done by Macro expression $.par
in the parameter value in the instance or prototype.
For example in the prototype, create a new boiler
parameter, and link the value to the boiler
parameter value of the instance parent: boiler:$.par("boiler"); The relation between Pma objects and Pmg objects:
It is important that it is possible to deliver the Pma
object parameter into the panel as a Pmg
object parameter. The basic principle is that the Pma
object parameter cannot get inside the panel automatically (the Pmg
object cannot directly "see" the parameter defined outside the panel). It is necessary to to create the corresponding parameter in the PmgRoot
object and set it to the value of the Pma
object parameter when opening the panel. This can be done: The usage of the prototype/instance concept:
The prototype/instance concept is very useful in situations, when the application contains multiple similar or identical units. For example the application monitors 5 boilers and the boilers are in fact identical and the part of the application connected with one boiler includes the communication with corresponding PLC, boiler data, trends, alarms, events and graphic panels.
Now it is enough to create the prototype "Boiler", that represents one boiler, implementing the complete functionality of the single boiler (communication, graphics, trends and alarms) and then create 5 instances of the prototype named "Boiler", "Boiler2", etc. For managing the differences between the instances a necessary number of Pma
object parameters is created. The most important parameter would be the "boiler number", but it is also possible to use the IP address of the PLC, etc. Caution!
All objects in the prototype must have unique global names and system resources
(identifiers, names, files, addresses, database tables, etc.), it is recommended to use Macro expression $.par
. This applies especially to PmaTrendGroup
objects, to objects available for Web or network, etc.
For example for trends, alarms and events, it is necessary to parametrize the group identifier, displayed group name, the file name and the folder, database name, the table where the component saves the data. If this is not done, then it works the same way as if there were two components of the same configuration in the development environment. These components would overwrite each others data, or the global registration fails because of identical identifier, etc.