different manufacturers, same Modbus RTU syntax?

Hello, I have never worked with Modbus before.
I am planning to buy some sensors with Modbus RTU output. However, each sensor is from a different manufacturer. Can I connect the sensors to one data logger? Or could each sensor have its own semantic and syntax, so each needs its own data logger from each manufactor.
 
Yes. Modbus is a standardized protocol. If a product claims support for Modbus, then it should work across different manufacturers.

Although, there are certain exceptions to this. For example, not all devices may support the same function codes (i.e. commands). Be sure to check the products' documentation to make sure the commands you need to use for your application are supported by both the sensors and the data logger.

If you can post links to the documentation of the sensors and data logger, I can review and advise on compatibility.
 
I'm in the "there are no guarantees" camp. The implementation of Modbus depends on the vendor. Some implementations are great, most are adequate, a few are awful and a few are not even conventional Modbus.

Here are some issues that can arise getting different model slaves to talk to the master:

1. RS-485 serial comm settings
All the slaves on an RS-485 serial network need to use identical serial settings.

If the slave uses Modbus RTU, then it will use 8 bit data words, but Modbus ASCII uses a 7 bit data word, meaning RTU and ASCII are mutually exclusive - they will not work together on the same network. Make sure all slaves run RTU.

The parity setting and stop bit count have to be the same for all slaves and the master. Although the Modbus spec says that all Modbus devices need to implement Even parity, there are some that do not. Although the Modbus spec says that no parity should use 2 stop bits, many devices nowadays do not offer an option to use 2 stop bits; they'll use 8-N-1 and nothing else. I've run into one slave that offered 8-N-2 and nothing else and it wouldn't work with 8-N-1 devices.

2. Function codes
The Modbus spec lists a host of Function Codes, maybe 25 (?), I've never counted them, but mosts vendors implement only a subset that covers the typical tasks most people use Modbus for. One vendor in my Hall of Shame implements only one Function code in their slave and it is a Function Code that no Master that I've ever run into can use. One would have to have a fully programmable master and write some code to talk to that slave. A situation like this is not common, but it's happened.

3. Floating Point formats
There are 4 word/byte formats for floating point values, of which 2 are common and 2 are uncommon. If any of the slaves use an uncommon FP word/byte format, your datalogger's Modbus Master programs either has to offer a choice of all 4 word/byte formats or it needs programmable and you need to program to move bytes around to get the value interpreted properly.

4. Common mode voltage ground loops
RS-485 is a differential signal WITH RESPECT TO SIGNAL GROUND. So called 2 wire RS-485 is supposed to be 3 wire RS-485 with the 3rd wire being a signal ground, as opposed to the earth ground connection for that device. Many, many vendors to not offer a connection for the 3rd wire signal ground.

When different devices get wired to the same network in the field, the differences in earth ground potential at each location can create ground loops along the network multidrop network. These ground loops can be minor enough to be tolerated, bad enough to saturate the drivers and cause the network to 'crash' or even burn out the RS-485 driver circuits. RS-485 isolator repeaters have always solved the problem for me, but it is added expense and time and effort to fix things.

5. Modbus that isn't conventional Modbus and therefore isn't useable Modbus
Here are some examples of vendors claiming Modbus functionality that is not conventional Modbus functionality.

A. Slave devices with a fixed slave address of 0. It means that that one can neither get data from the slave nor address any individual slave.

B. Format packing in the high order byte of an integer value
The integer value is only 8 bits, the low order byte of the register.
The high order byte provides the sign bit (typical), but then the remaining bits are the code for the multiplying factor.

Interpreting an 'integer' value requires some bit banging to get the end result. (The conventional method is to document what the multiplying factor is and then use all 15 bits for the integer value and the MSB for the sign bit)

C. Needing to write a value before reading any value
Convention says that one can read any Input register (3xxxx with FC04), Holding register (4xxxx with FC03), coil status (0xxxx with FC01), or discrete input (1xxxx with FC 02) with the associated Function Code.

One maverick device insisted on 'activating' a read function by requiring a write-to-coil first, for each and every read transaction.
 
I always consider modbus one of the most easy to implement, reliable and: cheap interfaces to implement. And values are available for read/write on addresses. So its some kind of memory mapped IO, but then over RS-485 or ethernet connetion.
Example:
Values of data are stored on addresses and in the PLC or touchpanel that you connect to it, you configure the MODBUS RTU (RS-485) or MODBUS TCP (ethernet) interface to it addresses the correct modbus slave connected to the PLC or touchpanel.
Say we connect a PID controller of brand A to the PLC.
The modbus address (every modbus device must have an address, either a number for RS-485 or a fixed IP address for TCP). Since most temperature controllers work with RS-485 we say it has modbus RTU RS-485 address 10.
It has the temperature setpoint on modbus address 7 and the measured value on address 3
On your PLC/touchpanel (which is the modbus RTU master, that takes initiative to read/write to its slaves) you read the measured value from PID controller with modbus slave 10 from its address 3.
And you write the setpoint to address 7

If you have a PID controller of brand B, it will most certainly also have a measured value and a setpoint, but they can be on another address.

But here comes the big benefit of Modbus: it is -very easy- to change the address to another brand: you just change the variables list coupled to the modbus addresses in your application and that's it. That's all you need to change.

Modbus is a way of making sure you can keep the system running for a very long time with many other brands of equipment.

It is very easy and most important: very open!
 
Thank you very much for the detailed and helpful answers. I will take your recommendations into account in my further course of action.
 
Top