See: The
PmaPrototype object
The simplified idea of
PmaPrototype and
PmaInstance object functionality is that at application launch 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:
Usually is 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 and
PmaInstance objects serves the "
Pma object parameters" configurator. For reference to the
Pma object parameters the
Macro expression $.par can be used in 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: The
PmaInstance 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 consists of 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 would be the
"boiler number" parameter, but it is also possible to use the IP address of the PLC device, 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,
PmaAlarmGroup,
PmaAdo objects available for the 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.