The preparation of an application program for HVAC equipment should be effective not only in order to minimize the time required for it. It is also a matter of making the most of the possibilities of hardware platforms, but on the other hand keeping some reserve for possible expansion of the system. Resources in PLC are not unlimited and on some platforms we have to allocate them wisely. In the following text, you will find some tips on how to approach this task.
When creating a project and scheduling it, we must be aware of the difference between a project (Project) and an assembly (Solution). A project is a set of programs, functions and function blocks. Probably the most important thing is to realize that each project has its global variables (which can be mapped - connected - to the hardware inputs and outputs of the PLC). A project is actually something like a "container", to which we assign our own programs as well as links (references) to libraries, etc. The assembly is then something that includes:
This is mainly due to the fact that one program can run on multiple PLCs. How is this possible and why should we want it? Under normal circumstances, we will suffice with the traditional idea that there is one or more PLCs in the set and that a different program (or more programs) runs in each of them.
All programs can be created in a single project. In the PLC settings in the task definition, it is then defined for each PLC which programs the given PLC processes. Let us now imagine that a program describes the control of a certain technology that is contained in several different PLCs - for example, there are several identical air handling units or equithermal branches in a building. It may be advantageous to manage the program for controlling the air handling unit or equitherm in only one place (in a project) and "call" it in individual PLCs, of course always with other assigned physical inputs and outputs. The inputs and outputs of the program are assigned to the corresponding physical inputs and outputs in the I/O modules of each PLC. When we modify a function in the program, it is enough to load the assembly into the controllers and the changes will be reflected in all PLCs to which the program is assigned.
Dividing programs into several projects (within one report) makes sense if we want to manage some programs together. For example, it is possible to set up a separate air conditioning project and a separate lighting control project, always with the relevant libraries and programs that use the blocks and functions from these libraries. For example, we can use the entire lighting project in another set, back it up separately, send it by e-mail, etc. Another case occurs when there are several PLCs in the assembly that do not have any common programs. Each PLC should then have its own project, as this will make the structure of the assembly clearer in a fairly fundamental way. It is more convenient for the management of individual programs - the subsequent reading of variable values from the PLC to the IDE is accelerated and instead of one large definition file with variables, several smaller files are created, separate for each PLC.
This is convenient because PLCs are managed and configured together. When changing programs, all PLCs can be played back at once with a single push of a button. It is also possible to send values from one PLC to another using SSCP communication between substations. (In other versions of Domat IDE, it will be possible to communicate with PLCs from another configuration, as is the case with SoftPLC IDE.) The maximum number of PLCs in a set is determined by how large the projects are in the PLC. The recommended number with sufficient reserve is 5 PLCs. In one set, we usually set up PLCs located in one building or technological unit, where they have functional connections with each other.
If we switch from SoftPLC IDE to Domat IDE, we find that Domat IDE contains several differences. The most important are:
On the one hand, this long-awaited feature allows the software to be significantly streamlined, as algorithms can be well segmented and repetitive chunks of code can be used as instances of customer blocks. However, if nesting is exceeded, both the readability of the program decreases and the PLC load increases disproportionately. Therefore, with regard to less powerful platforms (mark100, mark150, ...), we recommend using a maximum of two levels of nesting, ie a compound block can consist of other compound blocks, but these inner blocks should only be composed of basic blocks from libraries.
Unlike function blocks, structured text provides an elegant solution to cycles, conditions and writes to variables from multiple processes. On the other hand, the program written in ST is less clear and therefore more difficult to maintain - if it is not thoroughly commented, even the author himself does not know it after some time. In a typical program for the control of building technology, it is recommended to use functional blocks for clarity, preferably standard ones, which can be supplemented by "custom" function blocks, tailor-made - either from other function blocks or using structured text.
As described above, we can define multiple PLCs in one set (Solution). The advantage is, among other things, that PLCs can share common programs: when editing a program, the change after upload will be reflected in all PLCs that contain the program. Uploading projects to all PLCs can be started at once. This helps keep the entire system consistent even when editing in different PLCs that have communication links with each other.
In the SoftPLC IDE, especially on platforms based on Windows (IPCT.1) and Linux (IPLC510), users appreciate several dozen communication drivers for a variety of protocols used in building management, including proprietary protocols for foreign or legacy control systems. Domat, on the other hand, now only contains Modbus, M-Bus, BACnet, SoftPLC Link and the meter reading protocol according to IEC62056-21. This is because the Domat runtime must work on small platforms with limited memory capacity. Integration of third-party systems can be realized via SoftPLC (IPLC510) in the function of a converter with subsequent reading into the Domat environment using the SoftPLC Link driver. On the other hand, the Domat IDE allows you to write your own drivers in the ST language - see below.
Programs are not run invariably one after the other, but are assigned to so-called tasks. A task, or a group of programs run at once, contains one or more programs and is run periodically, based on a change in the state of a variable, or is "free running" - it is done when the PLC has time. It is thus possible to perform less important tasks (eg meter reading, statistical functions) less often or with a lower priority in order to optimize PLC performance.
Drivers for simpler communication protocols can also be written to the customer, as a function in the ST language. This option is open to more experienced programmers, it is necessary to take into account that debugging may take more time than originally planned. Sometimes the support of a third-party equipment supplier is required. In some cases, development can also be ordered from Domat Control System - it depends on the current capacities of the development department. ST does not include functions for parsing text strings, so protocols based on XML queries are not easy to process. Conversely, binary or character data transfers with a fixed telegram structure should be relatively easy to implement. Contact Technical Support for a description of the protocol you plan to integrate.
When making decisions, it is generally true that a program in the FUPLA language is clearer, but more demanding on computing power. Programming is simpler and clearer, many procedures take place automatically in the background. In contrast, the block execution order cannot be affected (when compiling, the IDE creates a program that specifies the block order. It is guaranteed that all relevant inputs are calculated when processing a function or function block. However, no specific block order is guaranteed). The whole program is always executed - in the FUPLA language, blocks are used, which can be quite complicated and only a small part of the function is used. In contrast, in a structured text, the user would not create a new FB instance for the same function, but would write a simple construct in ST. Structured text provides maximum control over the program, solves cycles and conditions well, working with arrays, vectors, structures. Allows more thorough debugging. On the other hand, ST is less clear and more difficult to use, it's not "clickable" software, although it includes IntelliSense - automatic keyword completion suggestions. The author of the program must keep an eye on all declarations, namespaces, etc.