It would seem like magic to someone two decades ago that you can speak through your voice-activated assistant and turn on your oven, open your garage, or turn on a lamp. With the rise of the “Internet of Things”, this is now an everyday occurrence. It is a catchy buzzword in the news, but it basically means the ability to remote control or monitor devices. Traditionally this functionality was only reserved for advanced machinery, but as the cost of connective technology has decreased, it has become reasonable to give anything with an “On” button the ability to be remotely controlled (also called a “Smart” device). Just because the device has the ability to be remotely controlled, there may be more work involved to get the device to understand the commands. Each device OEM has selected a certain communication protocol, and for the device to properly understand the command, the command will need to be sent in only this protocol. There are the more modern, consumer grade methods you will likely recognize: Wi-Fi, Bluetooth, 4G LTE but there are tons more you may not have heard of: PROFIBUS, Bacnet, CANbus, MQTT, BLE, Z-Wave, ZigBee, and X10. Prior to all of these existed one standard which has been adopted by many industrial equipment manufacturers: Modbus.
Modbus was created in 1979 by Modicon, a predecessor to the modern company Schneider Electric. From its inception, Modbus was intended to be a communication protocol to control industrial equipment. Although now aged considerably, it is still relevant today due to its widespread use, simple design, and the reliability proven over so many years. Almost every communication standard can be converted to Modbus with the appropriate piece of additional hardware. A simple google search “Modbus to XXXXX converter” will prove this.
Modbus is a language protocol with two common hardware protocols: RTU and TCP/IP. Just like how English is a language that can be written or spoken (think the hardware you use to communicate) these two hardware protocols speak the same language with different physical connectors. RTU stands for “remote terminal unit” and uses a two-wire protocol known as RS-485. TCP/IP is essentially the same thing the internet runs on and its hardware connection is an ethernet port. The two can be converted from one to the other with an additional hardware device. Modbus RTU is the most common, so that’s what I’ll be covering for the remainder of the article.
The concept of the Modbus RTU language is simple: a master (aka client) device requests information or sends a command to a slave (aka server) device, and the slave device responds with the information that was requested. The limitations of the language are also what lends itself well to industrial control: It’s a local, hardwired connection, without any type of password protection. There is a limit to the type of data as an integer, which works well for temperatures, pressures, and status reports but not much else. Only a single master can send/receive information to a single slave device at a time and the number of devices is capped at 247. Each device needs to be manually assigned a unique address and the location and context of the data inside the device needs to be known. The address of the device is simply 1 through 247, but the location and context of data depend on the device itself. There should be a Modbus table supplied by the manufacturer of the location and type of data you can send/receive from the slaves.
Think about it just like mailing a letter: If you want to ask House #1 what temperature its oven is, filling out the envelope is a standard format. But to write the contents of the question, you’d need to know some more information: 1. The house actually has an oven 2. What parameter in the house refers to the oven temp 3. If the response can only be an integer, then the unit of measure and scale of the response. Using the supplied Modbus field list from the OEM, all this information should be clear. Without this resource, you’ll be completely lost on what information is available to read. I’ve only covered the Modbus protocol conceptually at a very high level, if you wish to know more Wikipedia has a great article.
Now that you have a basic understanding of Modbus, we can focus on the specifics of remotely controlling a screw air compressor. There are two ways to accomplish this depending on what you are trying to do and the abilities of the air compressor. The first way is to overwrite the load and unload set points in the compressor controller, so the compressor acts the way you need. This leaves all the control, safety, and regulation logic intact within the compressor controller and works for almost all scenarios. For example, if you want the compressor to shut down, just overwrite the unload set point as lower than the current pressure. The machine will unload, time out, and stop in the controlled manner just as if the pressure set point was reached. It doesn’t matter if the compressor is a fixed speed or VFD, this method will still work. Another example is if you are controlling a VFD compressor and your logic is needing the compressor to increase output. Just overwrite the target pressure higher than the current pressure. This is the most elegant way to control a compressor system, but does require more time to develop the logic and more knowledge of the system.
The second method is to directly call the load/unload command on the compressor. Please notice I’m referring to the load/unload command and not the start/stop. Normally, you’d keep the start/stop command at the local control of the compressor. The start/stop command would remotely turn the compressor on and off, but still retain the pressure logic inside the controller which may not be the intention if you are trying to directly control the output. This load/unload control method is simpler to program, but doesn’t work ideally for all cases such as a VFD driven compressor. Another consideration is what happens when the compressor loses communication with the master. When controlling in the previous method by overwriting the load/unload pressures, the compressor will continue to operate locally with the last command setpoints. When controlling via the load/unload command, the reaction may differ depending on how each OEM programmed their controllers. For example, ELGi compressors will revert to its internal pressure settings if no command is received from the master at least every three seconds.
Modbus RTU is not a technology to be feared. It’s been around a long time and understood by many. A good systems integrator should be able to take the fieldbus list and integrate the device with any PLC or SCADA system in your plant. It may not be the having the glamorous “Internet” part in the IoT, but it provides all the remote functionality you’ll need in an air compressor application. If you have any questions, please reach out to ELGi at www.elgi.us for more information.
