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, doesn't exist in the running application. Only the prototype copies exist in all corresponding instances.
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 PROMOTIC 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 PmPrototype and PmInstance objects the PROMOTIC object parameters configurator is used. For reference to the PROMOTIC object parameters the Macro expression $.par can be used in the configurators and for the scripts there is the PmObject.GetPar method. The important fact for obtaining the 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 PmInstance object can receive only the parameters from the corresponding PmPrototype 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 PmInstance object is therefore special from the parameter searching (bubbling) point of view, because the parameter search is terminated there and does not continue to the PmInstance 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 PmPrototype object (the name can be the same or different) and refer to the parameter of the instance parent either here or in the PmInstance 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 parameter boiler, and link the value to the boiler parameter value of the instance parent: boiler:$.par("boiler");
It is important that it is possible to deliver the PROMOTIC object parameter into the panel as a graphic item parameter. The basic principle is that the PROMOTIC object parameter cannot get inside the panel autoamtically (the graphic item cannot directly "see" the parameter defined outside the panel). It is necessary to create the corresponding parameter in the PmiRoot graphic item and set it to the value of the PROMOTIC object parameter when opening the panel. This can be done:
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 PROMOTIC 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.
For example for trends, alarms and events, it is necessary to parametrize the group identifier, displayed group name, the name of the file 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.