There are so many communications standards out there: Modbus, Fieldbus, Profibus, Hart, and that’s just a few. You can get systems with HMI’s and PLC’s and RTU’s and… Yikes!
So how do you choose? What do they mean? “I just want to get the readings from my sensors!”
We hear you. We make several of our sensors Modbus-compatible, but we don’t do it for our sake, or even Modbus’s sake. We do it for you. So today, let’s take a look at what Modbus is, and why we use it.
What is Modbus?
Modbus is a “communication protocol suite … used to establish master-slave/client-server communication between intelligent devices.” Clears things right up, doesn’t it?
Ok, a bit more generally, Modbus is a framework (that’s the protocol) for storing and sharing information (that’s the communication part) between instruments (sensors, transducers, etc.) and controllers (that’s the master-slave/client-server part). The Modbus framework specifies four general characteristics of the devices and communication between them:
- The master-slave relationship
- The message architecture
- The data storage architecture on slave devices
- The physical characteristics of the network connecting the devices.
Modbus Master-Slave Relationship
Modbus requires a specified master-slave relationship between the instruments and controller on a Modbus network. Each Modbus network must have one master device and at least one slave device.
Slave devices are the instruments: the sensors, transducers, valves, servos, etc., that collect or act on the conditions in your process system. Each slave device has a unique network number that serves as its address, enabling the master to address one device at a time. A slave device does not act on communication that is addressed to another device. This allows slaves to be daisy-chained, rather than wired individually to the master device.
Master devices are the controllers, generally a computer or PLC. However, any device programmed with controlling capabilities and a human interface can function as master device. There can only be one master device on a Modbus network, so if multiple control-capable devices are connected together, all but one must be able to function as slaves.
Communication between a master and slave(s) is only initiated by the master device. The master device can communicate in unicast mode, addressing only a single slave, or in broadcast mode, addressing all of the slaves with a single message. The master device can either write information to the slaves, or read specific information from the slaves.
Modbus Message Architecture
Any communication protocol worth its salt has to specify how the messages are put together. This covers both what fancy people call the ADU and PDU (Application Data Unit and Protocol Data Unit. See? Fancy!) and the message frame. For Modbus over serial communication, the frame consists of the slave address, the function code, any data being passed, and frame error checking. Modbus also establishes timing required for communication between devices. This includes minimum time between messages and maximum silence within a message.
Modbus Data Storage Architecture
One of the most unique features of Modbus is the specific-yet-flexible data storage architecture. Modbus specifies data addresses corresponding to four tables in each slave device. Two in particular are the most interesting: the Input Registers and Holding Registers.
As seen from the perspective of the master device, the Input Registers on a slave device contain the information to be read into the master device. That is, this is where the slave device stores its output data. These registers are read-only for the master device. The Holding Registers are where configuration information (i.e., parameters) is written by the master device. While they are primarily for being written to by the master device, the Holding Registers can also be read by the master device to confirm their contents.
Modbus Network Characteristics
In keeping with the specific-yet-flexible theme, Modbus networks are allowed some variations within a defined set of requirements. Because Modbus is usually implemented on a serial line system, the primary requirement is paired data conductors. Whether using two or four wires, the transmitting wires are configured as balanced pairs to match the Transmitting and Receiving connections on the devices. The connections and wires are generally labeled using the serial conventions or Tx+ and Tx-, or A and B, or sometimes both. Most manufacturers of serial transceiver chips use A/Tx- and B/Tx+ notations, but some reverse the relationships (i.e., A/Tx+ and B/Tx-). As far as Modbus (and RS-485) is concerned, neither is right or wrong; as long as the pair is balanced, it will work for Modbus.
Why Does APG Use Modbus?
APG’s use of Modbus grew out of the needs of you, our customers, to be able interface our sensors with existing control systems. Proprietary communications work well with proprietary instruments and controllers, but they don’t integrate well with other systems. Because Modbus is widely excepted and implemented, and is an open-source standard, devices that use Modbus provide high value to users. Modbus also allows the flexibility to connect slaves and controllers from a multitude of manufactures.
At APG, while we enjoy and take great pride in designing and manufacturing high quality sensors and transducers, our efforts would be pointless if they didn’t match up to our customers’ needs. In essence, we chose to manufacture Modbus devices because they represent the greatest value for you.
Have questions about your Modbus device, or how to incorporate Modbus into your existing system? Let our Measurement Experts help you! Our thorough knowledge is available to you via phone, email, and on-line chat.
Want dependable control and display? The DCR-1006A has what you need: