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.
Modbus is a “Modbus Protocol is a messaging structure ... used to establish 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 client-server part). The Modbus framework specifies four general characteristics of the devices and communication between them:
Yes, there are further specifics within each of these general characteristics, but those are details we don’t need to spell out here.
Modbus requires a specified client-server relationship between the instruments and controller on a Modbus network. Each Modbus network must have one server device and at least one client device.
Client devices are the instruments: the sensors, transducers, valves, servos, etc., that collect or act on the conditions in your process system. Each client device has a unique network number that serves as its address, enabling the server to address one device at a time. A client device does not act on communication that is addressed to another device. This allows clients to be daisy-chained, rather than wired individually to the server device.
Server devices are the controllers, generally a computer or PLC. However, any device programmed with controlling capabilities and a human interface can function as server device. There can only be one server device on a Modbus network, so if multiple control-capable devices are connected together, all but one must be able to function as clients.
Communication between a server and client(s) is only initiated by the server device. The server device can communicate in unicast mode, addressing only a single client, or in broadcast mode, addressing all of the clients with a single message. The server device can either write information to the clients, or read specific information from the clients.
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 client 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.
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 client device. Two in particular are the most interesting: the Input Registers and Holding Registers.
As seen from the perspective of the server device, the Input Registers on a client device contain the information to be read into the server device. That is, this is where the client device stores its output data. These registers are read-only for the server device. The Holding Registers are where configuration information (i.e., parameters) is written by the server device. While they are primarily for being written to by the server device, the Holding Registers can also be read by the server device to confirm their contents.
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.
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 accepted and implemented, and is an open-source standard, devices that use Modbus provide high value to users. Modbus also allows the flexibility to connect clients 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.
top photo credit: Adam Foster via flickr cc
