System sizing with IRC

When designing a control system that includes communicative zone controllers (Integrated Room Control, IRC), we must ensure that the number of controllers connected to the PLC does not exceed a critical limit. Behind it, it would no longer be possible to operate the controllers in software, the response time on the bus would be unbearably long, or commissioning and servicing would be "just" complicated. Let us now look at some of the restrictions that must be respected. Some limits are "hard", others depend on other factors, such as the number of communicated variables per controller.

Number of IRC controllers on one bus
The theoretical maximum number of addressable controllers is 255, which is determined by the Modbus communication protocol. However, this number is nowhere near achievable, for the following reasons:

• when connecting 250 controllers to one bus, it would be extremely difficult to maintain the line topology and especially the total length of the bus, which should not exceed 1200 m (in that case, the average length of the line between two controllers would be less than 5 m, which is unattainable in practice),
• the response time would be in the order of minutes, while small tens of seconds are acceptable,
• a bus loaded in this way would put a significant number of controllers out of communication in the event of an interruption or short circuit, and it is also more difficult to start up and service.

The recommended number of controllers on one bus is a maximum of 50 - 60, unless there are other restrictions.

Number of communication buses on one PLC
Theoretical limit: For compact PLCs (mark320, markMX, etc.), the maximum number of lines is given by the hardware. A PLC usually has 4 ports, of which those with an RS232 interface can be supplemented with a converter to RS485 (e.g. Domat R012). It would also be possible to convert buses with IRC controllers to an Ethernet network using Modbus RTU / TCP routers (e.g. Domat R035) and thus obtain an "infinite" number of lines leading to one PLC. In reality, however, the "hardware" limitation is given by the maximum number of TCP channels in the PLC, of which there are several dozen, but we have no chance to reach even this number, because we will be stopped by some of the other limitations.

For wall series PLCs, where communication ports are obtained by adding serial communication cards w750-652, there is again a theoretical limit of 64 ports, but in practice we must not exceed the number of 4-5 communication cards per PLC. The bottleneck here is the internal bus through which all cards communicate with the processor unit.

It is strongly not recommended to combine IRC controllers and regular I/O modules on one bus: the bus for IRC runs outside the switchboard throughout the building, and in the event of a short circuit or interruption, even the input and output modules, which usually control the primary technologies, would not communicate.

The recommended number of buses with IRC controllers on one PLC is therefore 2 to 4, depending on how many IRC controllers they contain and how many of them we want to transfer values.

Number of IRC controllers on one PLC
This is exclusively a software limitation and is mainly related to what additional support functions we have to implement in the PLC for each IRC controller. If we were only to transfer the data via the PLC to the superior system (visualization), these variables would only take up relatively little space in the memory and would not be a significant limitation. Often, however, the user requires, for example, a time program for each room separately, functions for the logic of operating modes, control of blinds, etc., which can then greatly burden the PLC - let's be aware that there can be several hundred IRC controllers on the PLC, and each block in the software means this number is a significant cut from free memory. Especially with complex blocks, the use of which is directly encouraged by the repeatability of tasks in IRC controllers, the upper limit of the memory capacity can easily be reached and the program will not start after uploading to the PLC or cannot be compiled at all.

Another function that software loads the PLC is the alarm block. If alarms can be defined at the SCADA level, this means a great reduction in PLC memory requirements. This is usually possible, because in the PLC we do not need confirmation logic and, for example, blocking the start of the device from an alarm that has not gone away, as is the case with primary devices (VS, boiler rooms, HVAC).

The problem is that there is no simple function to determine the maximum memory capacity of a PLC. But there will definitely be a difference between the simple integration of 15 variables on an IRC controller and the integration of 15 variables with a separate time program and evaluation of functions for energy management, such as software integration of valve opening, alarms for monitoring overheating or underheating, etc.

Method
Before we start designing, we should find out some basic information:

• total number of IRC controllers in the building,
• types of regulation in individual rooms, preferably in the form of a clear table:

It is ideal if the specification also includes technological diagrams with physical data points (inputs and outputs of the control system) for individual types of connections.

• values that the user will want to have in the graphics and in the PLC Software labor is also related to this.

Usually 10-15 values per controller are enough (typically temperatures - actual and desired for heating and cooling, operating mode actual and desired, fan coil status, degree of opening of heating and cooling valves). If possible, let's agree a list of values with the customer, it will make handing over the work much easier. If the number of variables on the IRC is unknown, do not exceed approx. 60 IRC controllers per PLC.

Examples of configurations

Hospital 1
IRC controller EPC102 with 24 variables transmitted to the PLC. Of these 24 values, 4 are processed as alarms (ie 4 alarm blocks on IRC) and 1 is a weekly time program with no exceptions.

PLC: several mark320 substations, each using 2 - 4 communication buses.

There are 30 - 40 IRC controllers on one bus. In total, there are 70 - 100 IRC controllers on the PLC.

Hospital 2
IRC controller EPC102 with 21 variables transferred to PLC. Alarm blocks are not used, each IRC has a weekly schedule without exceptions.

PLC: Wall, 3 communication cards 750-852, and other I/O cards for controlling three heating branches.

On one bus there is approx. 40 IRC controllers. In total, there are 116 IRC controllers on the PLC.

Hospital 3
IRC controller FCR013 with 22 variables transferred to PLC. Alarm blocks are not used, each IRC has a weekly schedule without exceptions.

PLC: mark320, 2 buses used.

On one bus there is approx. 35 IRC regulators. In total, there are 72 IRC controllers on the PLC. There is still some reserve in this PLC.

Additional notes

• If IRC controllers are connected as master-slave, it is possible to read the states of binary inputs and other values only from the master controller. The slave controllers only copy the states of the outputs from the master controller. Only one controller – the master – is included in the PLC load.
• If the modbus line addresses of the IRC controllers are also listed in the project, make sure that the addresses of the slave controllers always start from 10 - see the catalog sheet of the FCR controllers... This is more of a note for commissioning; the designer usually does not assign addresses to the controllers.
• We use time programs without exceptions. Exception time programs on the one hand take up more space in the PLC memory, on the other hand they are more difficult to set en masse. Exceptions such as vacations, vacations, etc. are solved using a central time program with exceptions, and its status will be used in individual IRC blocks to rearrange individual time programs.
• If we are not sure whether the proposed topology is correct, we can use a free consultation at support@domat.cz - just send a topology proposal or a brief description of the solution.