The following tips look at the issue in terms of performance not from the PLC, but from the programmer. Especially in companies where more than one programmer participates in one order, or projects are handed over between the implementation department and the service department, it is advisable to follow several rules when creating programs, which will facilitate the work of program authors and their followers.
Under normal circumstances, we use the Autogen function for hardware (HW) variables, which automatically generates a global variable to the I/O point, which we can already use in the program and connect other function blocks to it. If a variable is created using Autogen, it has a unique ID. If the project, including global variables, is used as a default for other similar projects, we can proceed as follows when switching hardware I/O points to the program:
In this way, we can use some standardized program structure in the project, whose assignment of inputs and outputs we can not influence - the designer has done it before.
Domat IDE allows you to insert text and image annotations into diagrams. Text boxes can have different colors. For example, we write yellow comments on functions to make it clear what each part of the program does - always in relation to the technology or its function, ie for example "winter setpoint compensation", certainly not it is clear at first glance. The part of the program that still needs to be modified can then be marked in red ("Connect after commissioning of the cooling machine"); after their completion we can delete the note. Sometimes one picture is better than many words, so we can insert into the diagram, for example, the formula according to which the calculation is performed, and the like.
It is useful if the notes are for unusual or at first glance incomprehensible functions. For example, it is definitely worth describing the meanings of individual values for a multistate variable ("0 = off, 1 = on, 2 = timer, 3 = automatic").It is useful if the notes are for unusual or at first glance incomprehensible functions. For example, it is definitely worth describing the meanings of individual values for a multistate variable ("0 = off, 1 = on, 2 = timer, 3 = automatic").
Similar rules apply to comments in structured text. There, the function descriptions are even more important, because the ST language is not as clear as the FUPLA block diagrams.
We think that the program will be opened on departure by a service technician who may not have seen it in his life. It will have to orientate itself quickly and solve technological or hardware problems. The last thing he needs is to research what our program should do and how the programmer meant it.
Marking of variables for HMI import, OPC, etc.Already when creating variables and creating algorithms, it is advisable to mark variables that will (or could be) used in the future for import into superior systems - control panels, OPC server, SCADA applications, etc. Marking is used in Domat IDE, for example when (semi) automatic generation of text menu templates.
At the same time, it is possible to directly assign a display name and a text gadget to blocks marked for HMI import. A small addition when writing the program will automate and unify the user menu, which will further facilitate the creation of user manuals and operator training.
If the measured quantity does not have a physical unit, we do not actually know what we are measuring. Although temperatures are intuitive ° C, for example, for pressures, it may no longer be clear at first glance whether the value is in bar or kPa. For heat meters, MWh versus GJ is often solved, water meters can give values in liters or m3, etc.
It is advisable to fill in the units honestly, especially for inputs and outputs, but also for required values, parameters, calculated variables displayed in graphics, etc. Let's not forget that the units are automatically transferred to the data point table when imported into the visualization! Let's save work not only when reviving, but also when creating graphics and HMI. By filling in the physical units of global variables, we follow the concept of "enter data only once" - we avoid duplicate data entry, which represents a waste of time and the risk of error.
Needless to say, sensors measuring the same quantities should have the same units. Sometimes we see the water pressure for cooling in kPa and for heating in bar, which also does not help clarity.
This point may seem somewhat controversial, with two requirements: the effort to simplify work for oneself and others, and the tendency to protect the system against unauthorized access. Sometimes it is practical to write the PLC serial number (S / N) or the code (Code :) from the label in the notes in the PLC Properties, so that passwords do not have to be searched in further documentation and the PLC is always accessible. On the other hand, if a program with complete access data and a predefined public address leaks, it is difficult to prevent possible misuse.
The effort to unify variable names is as old as the programming itself. Older control systems used to have a limited number of characters for the variable name (eg 8 or 16), forcing project authors to discipline a certain amount of discipline. Nomenclature systems with data point names such as "Bld1AHU1FilSuAlr", "LA1HzgVe", etc. were created.
We recommend that you do not include the physical address of the I/O module or PLC input in the variable name, as this can be seen in the table of I/O points in the device and can change if the input is damaged and the peripheral and variable are switched to another input. Furthermore, it is advisable to avoid numbering the peripherals according to the project (eg sensor B31, valve Y10), at least for larger projects, as this is not a clear function at first glance (what does B31 measure? Y is a valve or damper? ?) and for differently equipped devices, the numbering may change (ie eg Y2 is once a preheating valve, sometimes cooling), depending on how the automatic peripheral numbering turns out in the implementation project. This can be a problem especially for projects where dozens of similar buildings brought to a common headquarters are drawn by several designers in different design programs.
Probably the most useful was the system combining the name of the device (VZT1) with the name of the data point, which also contains the measured quantity (tVenk, pPrivod). Such marking is well understood by the programmer and the service technician. However, we must not forget the international aspect: multinational companies can insist on one of the standards described above.
Function blocks from libraries have default names of the type "B110_Shift_Register_4", while the instance number is automatically added at the end if there are several of the same block types in the program. Where we know that the input, output or internal variables of the block will be integrated into higher layers of the system - LCD, control panels or visualization, it is good to rename the block so that the name reflects its technological function.
Wrong: B35_Reverse_PI_Controller (default name)
Correct: ControlTemperatureControl or RegTPriv
The name should not be unnecessarily long, so that the summary name of the variable incl. The whole trip was readable in dialogues for her selection at various programs. The path should be clear, eg "vetev2.ekviterma.x1".
The recommendations you have just read are no dogmas. However, it proved itself in a company with 8-12 programmers (project technicians) in the implementation department and the service department, which is separated from the implementation department. It is important that after handing over the order to the customer (in some cases only after the expiration of the warranty period), the implementation technician hands over the order to the service department. The service technician checks in his own interest whether the documentation is complete, whether the software backups, access data and contacts to the customer are up-to-date and whether there are any unfinished work at the event. If he finds a mistake or ambiguity, he does not take action. This is a very strong motivation for the implementation technician to finish things, otherwise he will not get rid of the orders - and the smooth transition of the order to the service department is helped, among other things, by following the above rules.
