Air handling units (AHUs) and air conditioning systems with integrated controls are becoming more and more popular. Their strong point is mainly that the control system with control algorithms is supplied by the manufacturer, who should know how the plant shall be controlled, and who could tune up the algorithms at dozens of identical units at different projects. Installation of the peripherals is also simpler, as most of them can be wired already in the production works, and complicated installations on site can be avoided. On the other hand, a link to the building management system (BMS) or SCADA, which also integrate other technologies, is required. The AHU supplier thus should be a qualified partner for the BMS supplier, who is responsible for this integration.
There are more communication standards used today. Each of them requires a slightly specific approach. Let us take Modbus RTU (over serial line) or Modbus TCP (over Ethernet), one of the most favourite protocols, as an example to show the whole process and point out the most common problems.
Even in the design phase it is necessary to specify the main facts which affect the whole supply and commissioning process:
The AHU supplier must specify if the controller talks over serial line (typically RS232 or RS485) using Modbus RTU, or over Ethernet and Modbus TCP. There are Modbus TCP/RTU routers to convert data from Modbus over serial to Modbus over Ethernet, but these are extra components in the system, which must be supplied, installed, commissioned and paid. Therefore it is advisable to get along without them, and if they are required, the designer should specify who will be the supplier and who will be responsible for their commissioning and setup.
It should be also cleared that if the unit needs a communication card or external interface, these components are part of delivery. Some manufactures use a single interface for more units, which may save costs.
An Ethernet card must have its IP address configured. Definition of the IP address range and assignment of addresses to the units is usually done by the BMS supplier, or IT department of the final customer in a corporate network.
If an air-conditioning unit or its communication card features a serial line, learn in advance what kind of physical interface it provides. For direct link of two devices and shorter distances up to 15 meters, the RS232 may be a suitable standard, while for longer distances up to 1000 m and more units on the bus the RS485 line is used. In either case it should be checked if both communication parties are able to work with the same communication parameters (baudrate, parity, etc.).
The design documentation should be as detailed as to terminal description, which means that the AHU supplier should provide documentation with terminals numbering and other bus requirements, such as shielding, termination, maximum bus length, maximum number of units on the bus etc. Most of the data are available over the Internet. However, it must be known what interface or communication card type is used, as some manufactures offer more communication solutions.
The Modbus protocol describes two roles: master and slave. There is always one device on the bus as a master, usually the supervised PLC or SCADA, which controls the communication and polls the slave unit or units. The supplier of the slave device must provide a Modbus table with the list of variables, similar to that below. The roles also may be called client and server. Before the commissioning starts, you should attempt to get as much information as possible: Modbus tables, data sheets, hints on specific features from the supplier. Record the important facts for next similar projects in the project documentation or in your special know-how folder. All settings should be updated in the actual project documentation: this makes life easier for the service staff. If the supplier offers lending of his devices in advance, do take the chance for this hands-on experience. A hour in the office equals to several hours on site.
When commissioning, go step by step, from bottom to top, and always check if the previous parts are completely OK. It makes no use to start up the whole system and then randomly seek for bugs. With serial communication over Modbus, the steps are as follows:
1. Check of physical link of the system parts – integrity of cabling (check with multimeter if necessary), wiring polarity.
2. Setting of bus termination resistors, usually by switches, according to the manufacturer’s notes. A badly or not at all terminated bus has no impedance match, and may be a fatal problem for communication. An oscilloscope is a great device, if available.
3. Setup of communication parameters: baudrate, parity, data bits, and stop bits. These values must be the same for all bus participants.
4. Modbus link address setup at the slave devices. These addresses must be unique at the bus, i.e. no two or more devices shall have the same address. The addresses are mostly configured using DIP switches, coding switches, or over a menu if the device has a control panel with display. If there are no special requirements, start with 1 and continue with 2, 3, etc. to keep the addressing clear.
5. Locate the Receive data (RxD) and Transmit data (TxD) LEDs, if available. They will help in the next part.
6. At Ethernet devices, check the network card status and activity using LEDs at the device and at the Ethernet switch. There may be issues with establishing a connection if the cards are cross-connected with no Ethernet switch inbetween. It is recommended to use a switch, which indicates both physical link and data transmission.
As a next point, try to establish (any) communication with the slave device. Use simple programs – utilities, which offer more flexibility than a preconfigured PLC project. Anyway, there may be a bug in the PLC project, which would only be confusing. The proceeding is as follows:
1. Choose a Modbus utility, e.g. Modbus Poll or ModComTool, and a communication converter (USB to RS485 or USB to RS232) which you already have worked with. It is always good to have only one unknown variable in the system.
2. Check the IP address setting at Ethernet devices, and prove the physical connectivity, for example using the ping command. The problem often is that the fixed IP address of the notebook is in another network than the IP address of the unit, or the IP addresses are duplicate.
3. Get ready the Modbus table provided by the device manufacturer.
4. Check if the communication utility has the same communication parameters as configured at the device. Try with the default settings of the unit first, even if the target parameters may differ (e.g. the baudrate may be higher).
5. Check the timing parameters of the Modbus client: if the timeout, in other words: waiting time for the device response, is too short (say less than 100 ms), the master may not wait long enough for the response, and will indicate a communication error. Start with timeout about 1000 ms, and reduce it to 200 – 300 ms later. The pause between telegrams may be about 1 s so that the Tx / Rx LED flashing sequence is visible. It may be reduced as low as to 20 ms later.
6. Choose a register in the Modbus table. The register should contain a variable which is easy to interpret. It is good if the variable is also available for reading at the display of the unit or at its web page, so that you can check its value and changes. Typically, a room or outside temperature will do. Fig. 1 shows Modbus registers for three Toshiba airconditionig units. All units are available over a single interface, and their data are offset by 100 registers in the Modbus table. So, for example, the return air temperature of unit 2 is in Modbus register 223, and similarly, registers of units 3 to 7 can be calculated.
7. In the communication utility, set the Modbus function according to Modbus documentation of the unit (here, Input registers, F04, is used) and try to send and receive a telegram. The program should have a port monitor so that you see if the device is responding and what data it sends back.
8. In the successfully received telegram check if the received value is as expected.
There may be following problems with communication:
The device is not responding at all
The most common issue. Check the Hardware points above, especially the setup of communication parameters. If they are not known, try the ModComTool utility and its scanning function which automatically tests all combinations of selected communication parameters, and stops at the moment when a response is received.
In the utmost case, the device supplier can be asked to „select his favourite weapon“ and show that his device responds on a Modbus request using any Modbus client program, even his own utility. If he is able to prove this, the problem is on your side. The LEDs indicating sent and received data may help, you can at least see if the master sends some data, and if the slave is responding or not.
With TCP communication check if the Modbus port number is set to 502 in the device, and you can try to change the Modbus (link) address in the request. The device should ignore the Modbus link address in the TCP request according to the Modbus standard, but devices were noted where the Modbus server required the link address of 1, otherwise there was no response at all. Another interesting reaction was found at the Advanced Energy photovoltaic inverters, which responded to link address 1 for reading, but link address 0 had to be set for writing. The manufacturer explained this as a protection against writing by mistake, a security by obscurity measure.
The device responds with a Modbus error
If a standard Modbus error is returned, usually the request was sent using an unsupported Modbus function (e.g. Read Holding Registers F03 rather than Read Input Registers F04) or there was a non-existing register number queried – this might have been caused by misinterpreting HEX and DEC formats (e.g. 200 hexadecimal is 512 decadic; if the table is in HEX and the value is entered as 200 into a DEC-based client, it is a completely different register which is queried). Note also that the notation „40012“ mostly does not mean „register 40012“, but „register 12 read by function F04“ (or even „... read by function F03“, which is interesting and deceiving at the same time).
The device responds with a strange value
If the received value is completely different from the expected one, such as 0 rather than 21, most probably another register is read. Some manufacturers start the Modbus table numbering with 1 (as registers), some with 0 (as addresses). Try to increase or decrease the register address by 1. You can also read a whole block of registers at a time, and easily tell which value belongs to which variable. However, it may also be that another Modbus function is used (e.g. F04 rather than F03) and completely different data are read! Remember also that at values below 0 (such as outside temperature) the underflowing of the Word format causes e.g. -1 to be read as 65535.
The device responds with similar value, but different in scale
This means that you are on the right way and the problem may be in scaling only. The result must be divided, mostly by 10 or 100: Modbus can not communicate decimal numbers. Values for which decimal resolution is required must be multiplied in the server prior to transmission, and divided after reading by the client. The manufacturer should mention this in the Modbus table, such as at Fig. 1 where the temperature is stated in °C ×100. It must thus be divided by 100 after reading to get the correct value.
As soon as the first value is communicated successfully, half of the work is done. Other variables usually keep the same rules. Similar method is used for writing, just note that to enable writing it may be necessary to set a particular value in another register – this is used to protect the device from unintentional writing. Such tricks should be advised of in the device manual or Modbus table.
Data integration not only saves physical datapoints in the control system, it also makes easy to communicate values which would be difficult or impossible to transmit over analogue signals. These are mainly energy consumptions, operating hours (cumulated values), numbers of alarms, alarm codes, and other discrete multistate values.
For those who are interested in more details, Domat organises free trainings where the participants put their hands on the communication and even can try to integrate their own devices. A properly designed and commissioned link between two systems brings a transparent view on technologies, and may increase comfort in buildings and cut down service costs.