For less powerful platforms, the key question is whether the application will "fit" into the PLC. The Domat system is very flexible, allows many combinations of functions in the PLC and does not have "sharp limits" set, which would cause the impossibility to make full use of platform resources (especially memory). Unfortunately, the memory requirements of a running runtime cannot be determined by a simple algorithm from the source text. We are able to determine how much memory the compiled program in the PLC will take up, ie whether it will be loaded into memory at all. However, it is not possible to estimate 100 % of how much RAM the compile will require to run: each defined communication channel takes up some memory, and different combinations of channels and blocks take up different sectors of memory on some platforms. The exact status of resource usage can be seen in the PLC statistics in the System status tab, see below.
On the other hand, we are able to determine how much space is left in the NVRAM memory for the RETAIN variables (they are stored even after a power failure). (The values will remain stored in the classic Flash memory after a power failure, you just need to count on a three-hour write interval, which extends the life of the memory, or start saving manually.)
PLCs that can be programmed using the Domat IDE programming environment can be divided into three performance categories. The categories differ both in performance and memory for SW and for the web, as well as the number of clients they are able to serve and the speed of response, for example on a web server.
These basic PLCs include the mark100, mark120, mark150, mark150/485, IMIO100 and ICIO200 stations.
A typical application program for the weakest platforms includes functions for VVK control for approx. 50 physical data points. Time programs take up the most memory space, especially those with exceptions. Therefore, we recommend limiting their number to 2-3 and especially using the types of schedulers …Basic, which have only a weekly table with a maximum of 42 changes and do not contain exception programs. If the substation is used only for data collection and their subsequent sending to another system, the limit of the number of data points is significantly shifted. In this mode of operation, for example, the PLC mark100 manages to communicate approx. 150 physical data points.
PLCs from this category can serve a maximum of 5 clients on the SSCP channel (for example, communication between PLCs, visualization - SCADA, OPC server, or other programs such as Domat Menu Reader, ie "server" channels). However, it is always necessary to keep one channel reserve for communication with the Domat IDE itself. The real limit is therefore 4 clients on the SSCP channel.
The memory capacity for the web server is approx. 1.1 MB - this must be respected especially when preparing images - choose economical formats such as .png!
These PLCs include mark125, mark130, IMIO105, IMIO110 and ICIO205 stations.
For controllers with increased RAM capacity, the limit on the number of data points is shifted by approx. to triple, ie 150 for control and 400-450 for data collection.
PLCs from this category can also serve a maximum of 5 clients on the SSCP channel.
The memory capacity for the web server is the same as for the previous category, ie approx. 1.1 MB.
These stations include IMIO105.2, IMIO110.2, ICIO205.2, mark130.2, mark220LX, mark320LX, markMX.2 and markMX.
Here, the number of time programs is no longer critical. Rather, we must ensure that the blocks are not nested in more than approx. 3 levels - see below. The limit on the number of data points is again approx. three times compared to the basic PLC with increased RAM capacity and is therefore approx. 450 physical data points.
PLCs in this category also have a larger memory capacity for "retain" type variables. Substations from this category are able to communicate with up to 20 clients on the SSCP channel at once, which is a value that is very difficult to exceed in practice.
The memory capacity for the web server is at least 8.3 MB.
However, the load on the PLC, or the number of physical data points that the PLC can control and the speed of response of the entire system, depends primarily on the complexity, level of difficulty and method of creating control software.
The limitation by the number of physical data points is therefore rather indicative, it always depends on the way of work of a particular author of the program.
When creating software, it is possible to orientate yourself both by the number of physical data points and by the information that is visible in the Domat IDE after each compilation of the assembly. In the “Output” window, information about the filling of the PLC memory is displayed after compilation. Therefore, the memory occupancy values should be below 100 %, ideally they should not exceed 90 %.
Another indicator that can be used to determine the degree of load on the PLC is the length of one calculation cycle. If the assembly is already loaded on the controller and debugging is started, the length of the cycle can be found in the “System status” window. Regardless of the platform, the maximum length of one cycle should ideally be below 0.5 s, in the case of larger projects below 0.7 s. For example, a longer duration of one cycle will cause slower system responses for external clients (web server, Domat Menu Reader, HT102/HT200 terminals, communication with Domat IDE, etc.), the system will be less responsive to short-term input changes and in extreme cases may reduce unreasonably long cycle stability of the entire system.
Customer blocks are a great tool for streamlining the work of a programmer. They are ideal for software standardization across the company, universal variants can be written for use on most projects. However, the use of highly complex function blocks (large tens to hundreds of blocks inside) and multiple nesting of blocks increases the PLC load. For the weakest platforms (ICIO200, IMIO100, mark100, mark120, mark150 and mark150/485) we recommend a maximum double nesting.
User FBs should not contain diagrams of the whole technology, in general they should contain rather simpler things: the ideal block is eg control of pump, boiler, mixing branches, etc., but not block "Boiler room", "Air conditioning", or in extreme case eg " building 1 ”, where there would be four identical buildings in the set, and each FB then contained 80 inputs and 80 outputs and hid the complete regulation inside.
It is ideal to use a compromise between FB and programs - to split the project into multiple programs that contain a simpler FB. Complex function blocks will make the work of the SW creator easier, but they will make the PLC controller more difficult.
The most powerful types of PLCs can be loaded more, but if, for example, a fast response on the buses or an overall fast response is required, the programming style must be adapted here as well. For basic PLCs, it is always necessary to remember that it is a weaker platform, so the complexity of FB must be adapted to this.
For periodic tasks, it doesn't make sense to call a task more often than the freewheeling period of the task and than the PLC is able to refresh inputs and outputs on the bus - more frequent calls with common algorithms still do not speed up the response and unnecessarily burden the processor. However, it is more advantageous to use a free-running task, in which the PLC plans the optimal use of itself - the task is run "when the PLC has time". This guarantees the shortest possible processing period with sufficient reserve for other processes (web, communication…). See also above.
At least one task of any type must always be defined in the PLC. There may then be more tasks, but you need to know that it does not make sense to set a period shorter for periodic tasks than the original measured cycle time. Task won't run that fast anyway. Thus, the periodic task makes sense for algorithms that are to be run only once in a certain (longer) time. Not for things to be run more often. This is done using the "freewheeling" type, which is launched as quickly as possible. (However, it is possible to set a pause, which is always performed after the end of one cycle.)
In general, it is recommended to use only one task for most applications. This is because we could very easily get into a situation where the alternation of non-trivial computational tasks does not get to other tasks, such as communication, web server, etc. The second and subsequent tasks should be with the shortest possible computation time. In Simple mode, only one task is defined, freewheeling, and all programs are run in it. The function thus corresponds to the SoftPLC IDE concept.
