While exchanging with our customers on the best ways to interface industrial controllers, we noticed that nowadays the small secrets enabling you to use an RS485 interface were sometimes unknown from engineers implementing computer or internet based automation. So here is a quick remedial course...
What is RS485?
RS485 is a serial transmission standard, a little bit like RS232, but using other electric signals. An important advantage of RS485 is that you can put several RS485 devices on the same bus. Therefore, you don't have to multiply RS485 interfaces on the host to question several devices. However, there is a small trick to do so: at each end of the bus, you must put a bus terminator. Sometimes this means that you must screw a small resistance on a terminal, or simply move a switch in the adequate position.
An RS485 bus is often made of just two wires and a resistor at the extremities...
RS485 and RS232 are not directly compatible: you must use the correct type of interface, or the signals won't go through. There are indeed RS232 to RS485 gateways, but they are not interesting nowadays: it's as easy to use an RS485 to USB, to Ethernet, or to GSM directly. It's cheaper and it's one less component in the system.
The main particularity when using RS485 is in the format of the exchanged data. While with RS232 many devices simply use text (ASCII) protocols, with RS485 most devices use the MODBUS protocol. You must therefore know a minimum of MODBUS to interface an RS485 device.
What is MODBUS?
MODBUS is a protocol between a host (master) and devices (slaves) to access the configuration of the devices and to read the measures. MODBUS messages correspond to relatively simple operations to read and write 16 bit words and binary registers (often called "coils"). The host systematically initiates the exchange and the "slave" device answers. The slave doesn't sent any message before the host requests it.
As there can be several devices connected in parallel on the RS485 bus, each slave device must use a unique MODBUS Slave ID on the bus. Each MODBUS request starts with the Slave ID of the intended device, each answer starts with Slave ID of the slave sending it. So, in order for the MODBUS communication to work, you must check in the device configuration its Slave ID and change it if necessary. On the way, check also communication speed and parity (same principle as RS232).
You cannot easily craft MODBUS messages "by hand", as you would have done with ASCII protocols used on RS232: each MODBUS message ends with a checksum code, computed from the full content of the message. To exchange MODBUS messages, you must therefore use:
- either a specific program provided by the device vendor, with a compatible interface;
- or a simple RS485 interface with a programming library which encodes and decodes MODBUS messages;
- or a smart RS485 interface able to encode and decode by itself the MODBUS messages, such as the Yocto-RS485.
Note as well that there are two variants of the MODBUS protocol: the MODBUS ASCII mode, where messages are exchanged as lines of hexadecimal codes, and the MODBUS RTU mode, where messages are exchanged directly as binary frames. To talk with a MODBUS device, you must imperatively use the same mode as configured in the device. All the devices which truly follow the standard support the MODBUS RTU mode. In real life, its always this latter mode which is used: MODBUS ASCII has no advantage as all the messages are in any case difficult to code by hand.
A small temperature controller with built-in PID, fuzzy logic, ... and a MODBUS interface on RS485
Accessing MODBUS registers
When you have theoretically understood how to exchange information, you still must know which register to request to obtain measures, and which registers to change to configure the device. At this level, register addresses change from one device to another, but there are MODBUS conventions useful to know to understand technical user guides, which are often not as clear as one could hope.
There are 4 types of MODBUS registers:
- The coils, corresponding to on/off binary outputs, such as relays.
- The input bits, corresponding to binary inputs (read only).
- The input registers, corresponding to analog inputs (read only).
- The holding registers, corresponding to analog parameters which can be changed.
The technical user guide of a MODBUS device usually contains a list of all the available registers, listed by type. For each type of register corresponds a range of register numbers, following this convention:
- The coils are numbered from 00001 onward
- The input bits are numbered from 10001 onward
- The input registers are numbered from 30001 onward
- The holding registers are numbered from 40001 onward
Note that when one uses this convention, the first register of each category always ends by digit 1 (zero is not used).
Sometimes, rather than indicating the unique register number, the vendor indicates the type of register with the identifier of the MODBUS function which allows you to read them:
- 01h for the coils
- 02h for the input bits
- 04h for the input registers
- 03h for the holding registers
In this case, it's often the relative position of the register in its group which is indicated, with the 0 position for the first element. Thus, register 0 of the 04h function corresponds to the first input register, which you can also call register 30001. Take care not to be confused by the incoherence between register ranges which do not correspond to the MODBUS function identifiers, and the incoherence of relative positions starting at 0 while absolute positions start at 1...
When you know which register to access, you must still know how to interpret it. As analog registers are coded using 16 bits, there are usually two conventions. The first one consists in using a value range defined in the device configuration, and to make an linear mapping of the 0-65535 register value to this value range. The second consists in storing directly the value in decimal fixed point, in engineering unit: for example, 2345 represents 23.45 degrees Celsius. Some vendors provide simultaneously the values in the two formats: for example, register 30001 for the version proportional to the defined range and register 31001 for the decimal version.
A concrete example
Let's see concretely how you can access the temperature measurement and the setpoint value of a Schneider Electric Zelio REG48 temperature controller. Here is an extract of the technical user guide:
Extract of the register table of the Zelio REG48 controller
If you have paid attention, you have understood that this table describes input registers. The base register use the proportional format, and the one at offset +1000 is in decimal form (engineering unit). If you use a Yocto-RS485 you can thus access it with the modbusReadRegisters() function. Beware, as indicated in the documentation, this function uses the relative position of the register (indexed from zero):
var serial = YSerialPort.FindSerialPort("RS485-REG48");
// Read first two registers, in "engineering unit"
var slaveID = 1;
var firstRegs = serial.modbusReadInputRegisters(slaveID, 1000, 2);
// Decode fixed point decimal number
var processVal = firstRegs[0] / 10;
var setpointVal = firstRegs[1] / 10;
Another possibility of use with the Yocto-RS485: you can configure it with the web interface so that it automatically reads those registers, without needing you to interact with a computer to trigger the measures.
A job to periodically read a register
Thanks to this, the Yocto-RS485 can serve as a data logger to store the measures received by RS485 on its flash memory (up to 500'000 measures).
You can go even farther: if you connect the Yocto-RS485 on a YoctoHub-Ethernet and if you load on it a small web page with some JavaScript, you can transform this simple RS485 temperature controller based on technology from the 70's into a connected product in the fashion of the Internet of Things. Any browser running on a tablet can then connect to the interface and interact with the temperature controller:
Neat, isn't it?
