Let’s start with a simple Modbus definition.

Modbus is what you’ll call a communication protocol built for industrial controllers. It enables industrial controllers or PLCs to communicate with sensors, actuators, HMIs, and other modules used in instrumentation and control. Almost every integrable industrial device supports Modbus.

Modbus is a half-duplex, serial digital communication protocol. It works perfectly with the popular communication medium for industrial controllers, which is RS485. RS485 enables Modbus communication over long distances. Modbus is also compatible with other serial communication interfaces, such as RS232 and RS422.

Here's how the Modbus story started.

It all began in 1979 when Modicon, now Schneider Electric, built a protocol to make communication easier for its range of PLCs. Modbus is an application layer protocol, which means that it’s independent of the electrical medium of transfer. The Modbus standard covers the format, fields, and transmission sequence of the Modbus frame.

Today, the Modbus Organization manages the protocol. The de-facto industrial protocol has evolved throughout the decades. Initially, there were two types of Modbus protocol — Modbus RTU and Modbus ASCII. With the emergence of ethernet networking, Modbus TCP was introduced to leverage the connection-based nature of TCP protocol.

Why Is Modbus Popular?

You would have thought a protocol that spans over 40 years would have been rendered obsolete. Not with Modbus. It remains the most common protocol used by modern industrial systems. Modbus is such a hit with industrial engineers, equipment manufacturers, and PC programmers for a few reasons.

Cost-Effective

Modbus is an open-source protocol. Thus, manufacturers can incorporate the protocol into their industrial products without paying royalty fees. Incorporating Modbus into a controller is also reasonably straightforward. It’s a matter of adding the Modbus driver into the controller’s firmware.

Modbus has an advantage over the direct connection of switches (input) and solenoids (output) in terms of wiring. Modbus only takes a pair of twisted cables for an RS485 connection, while a direct link will require as many wiring connections for the individual I/O.

Given that cabling cost is always on the rise, it makes sense to opt for Modbus.

Simplicity

You’ll never get a more straightforward protocol than Modbus. It provides read/write operation on an industrial device’s coil, status, input registers, and holding registers, mapped to a range of addresses.

Programming skills are not needed to operate a Modbus-featured controller. The concept of writing and reading from coils and registers is easy to comprehend. With the aid of a visual interface, system engineers can set up and control Modbus-operated devices without any programming skills.

A Mature Ecosystem

Over the decades, Modbus has matured into a large ecosystem of industrial control products. As a result, PLC programmers and system engineers are accustomed to working with Modbus.

There isn’t a growing need for a different form of protocol. Unlike consumer applications, industrial controls do not need streaming megabytes of data in real-time. Existing Modbus infrastructures are unlikely to undergo drastic changes even with technology upgrades.

How Does Modbus Work?

Modbus simplifies data acquisition and output control for an industrial controller. A Modbus connection requires a master controller and at least one slave device. The master controller sends Modbus commands, and slave devices respond with data or acknowledgment.

Modbus can’t have more than one master controller. Doing so will result in corrupted data packets when multiple controllers try to send commands simultaneously on the Modbus network.

Modbus replaces individual connections to I/O modules. As such, it retains familiar terms like coils and inputs in its data representation. All Modbus protocols share the same data types, which are allocated to specific addresses.

Modbus Data Type

Here’s how Modbus data types are represented:

Fig 1 - Modbus Data Type

The coil data type will be typically associated with a solenoid output or solid-state relays. Discrete inputs are often flow switches, limit switches, or other single-bit digital inputs. Input registers are similar to discrete inputs, except that it returns a 16-bit data.

The holding register is a read/write storage that can be used for various purposes—for example, writing and reading parameter configuration on a Modbus actuator. In addition, the holding register can be used to set parameters like maximum torque, alarms, relay contact, fail-safe measures by writing the appropriate 16-bit data variable.

Modbus Message Frame

The next question lies in how a Modbus data packet is transferred between master and slave devices. The following diagram of a typical Modbus message frame gives a clearer picture.

Fig 2 - Modbus Message Frame

The above message frame is valid for Modbus RTU and Modbus ASCII. In Modbus TCP, the Checksum and End fields are removed, and the Start field is replaced with a 6- byte overhead. We’ll explain the differences between these protocols in the next section.

Each Modbus message frame is wrapped by a start and end field. It allows the receiving unit to segregate different data packets.

The Device ID indicates the recipient of the Modbus message. The device ID ranges from 1 to 247, but the limit differs based on the transmission medium. Most industrial systems run on RS485, which allows up to 32 connected devices. If you’re using RS232, you’ll have a maximum of 2 devices. Running Modbus on TCP will expand the device count, subjected to the network switches and gateways.

Modbus Function Code

The core of Modbus lies in the Function Code, Register Address, and Data. They are also known as the Protocol Data Unit (PDU). These fields provide specific instruction to Modbus slaves on what information needs to be retrieved, written, and where they are located.

These are standard function codes supported by industrial Modbus devices.

Fig 3 - Modbus Function Codes

Modbus Communication Flow

So, how does data get moved around in a Modbus connection?

Modbus communication always starts with a master controller sending a request to a slave device. It can be a write or read request, depending on the function code selected in the message frame.

The controller specifies the register address, register count, and data written on the Modbus PDU for a written request. A read request has a similar format, minus the data field.

When a slave device successfully processes a request, it’ll return an acknowledgment Modbus frame to the master controller. The acknowledgment frame contains the functioned code that was executed and data if it’s a read request. If a Modbus slave fails to process the request, it’ll respond with an exception code.

Modbus Exception Code

There are instances where a master controller sends a request that is not supported by a slave device, or the latter experiences technical issues. In such cases, the slave device will respond with a Modbus exception code.

Modbus Data Integrity

Industrial automation and instrumentation rely on data integrity. Measured value from the sensor must be received without alteration by the controller. The same goes from configurations sent by a controller to a Modbus device.

It will be disastrous for the data to be corrupted during transmission and processed by the devices. For example, a temperature sensor measured 24 degrees C but returned 18 degrees C because some bits got flipped during transmission.

Therefore, the Checksum in the Modbus frame is vital to ensure the data integrity of Modbus transmission.

The 2-bytes Checksum is calculated from each byte of the Device ID and PDU. It is then appended on the Modbus message. Upon receiving a Modbus frame, the recipient will compare the checksum value against the calculated Checksum based on the received packet. If there’s a mismatch between the checksum values, the device discards the Modbus data packet.

Modbus Distance and Speed

You can run it over RS232, RS485, or an ethernet cable. Each transmission medium allows different distances and speed limits. For example, you can’t go further than 50 ft. on a 9600 baud rate with RS232.

Most installations are on RS485, which works up to 4,000 feet and a speed limit of 115,200 baud. Ethernet cable provides a distance of 100 meters and the speed of the network switches.

Theoretically, Modbus RS-485 has an upper limit of 115,200 baud rate, but real-life applications rarely go beyond 19,200. Often, there isn’t a need for such a high data transfer rate, and most slave devices aren’t built to handle such a high baud rate.

Common Modbus Protocols

Not all Modbus devices are built equal. When you’re setting up a Modbus system, you’ll need to ensure that all devices can communicate on the same protocol. Modbus RTU is the most popular protocol, but if you’re choosing a Modbus ASCII or Modbus TCP sensor, you’ll need to ensure that the master controller supports both protocols.

The protocols differ in formatting and size. So let’s take a deeper look at each protocol.

What Is Modbus RTU

Fig 5- Modbus RTU Frame

The Modbus RTU protocol transmits data in 8-bits (byte) binary format. For example, the function code of 16 is represented by a single byte 0x10 hexadecimal value. Using the Modbus RTU format allows you to send or receive data with the smallest bandwidth.

It’s interesting to point out how Modbus RTU uses a period of science to indicate the start and end of a message. Timing is crucial for a Modbus RTU device as it needs to time the silence interval to mark the end of a message frame.

What Is Modbus ASCII

Fig 6- Modbus RTU Frame

The Modbus ASCII shares the same field types with Modbus RTU, but that's where the similarity ends. Instead of binary formatting, Modbus ASCII uses ASCII characters to encode the data into the message frame. For example, function code 16 is represented by two characters of 0x31, 0x36.

ASCII formatting also limits the device limit to 247 (0xF7). Thus, the most significant device ID on a Modbus ASCII frame is 0x46, 0x37, the ASCII values for 'F' and '7'. The same applies to the register address and data that are passed in the message body.

A 2-byte LRC checksum is calculated for error-checking and appended to the message.

Unlike Modbus RTU, Modbus ASCII uses characters to indicate the starting and ending of a message. It uses 0x3A (:) as a start character and CRLF (0x0D, 0x0A) to terminate the transmission.

The payload uses only alphanumeric characters, which means that it produces intelligible text string when monitored on a Modbus sniffer software. It's also less sensitive to timing requirements as the message starts and ends with characters.

The downside of Modbus ASCII is that it takes at least twice the size of Modbus RTU. For example, it takes 2 bytes to transfer 0x5469 in Modbus RTU, but it'll take 4 bytes to convert the value to ASCII representations of 0x35, 0x34, 0x36, 0x39.

What Is Modbus TCP

Fig 7- Modbus TCP Frame

The 1990s saw the introduction of the 10-Base-T ethernet standard and the internet going mainstream. In 1999, Modbus TCP was introduced to leverage ethernet connectivity.

TCP is a connection-based transport layer protocol on the OSI stack. It automates connection synchronization, handshaking, error checking, and packet handling. With TCP taking care of the data transfer mechanism, some of the fields in the original Modbus frame become redundant.

The Start and End bits are no longer needed, and the same goes for the checksum. Therefore, the Modbus TCP saw a revision in its data frame. The Start, Stop, and checksum were removed. They are replaced by a 6-bytes header.

What’s new in the Modbus TCP is the Transaction Identifier, which is used to determine that a request is followed by a matching response. In addition, the Protocol Identifier is set to 0, indicating TCP protocol, while the Length Field indicates the remaining byte in the data packet.

What about Modbus Plus?

Despite sounding similar, Modbus Plus is not Modbus. Instead, it is a high-speed peer-to-peer communication protocol developed by Schneider that allows data transfer at 1 Mbps.

Modbus Plus specification includes protocol and hardware layers such as cabling and terminating connector. It involves token-passing in a flat network hierarchy, which differs from Modbus’s master-slave configuration.

Understanding Modbus Addressing And Messaging

We’re about to dive deeper into the workings of Modbus. Understanding how Modbus addressing and messaging works helps when you’re configuring and troubleshooting a Modbus network.

Device ID

A single byte can hold up to 255 possible Device IDs. However, Modbus specifications limit the valid IDs from 1 to 247. So, if you’re sending address 0x00 or 0xF8-0xFF on a Modbus RTU frame, the data frame will be ignored.

Relative Addressing

The standard Modbus specification allocates 9,999 memory points for different data types ( coil, discrete input, input register, holding register). On a Modbus device, these data are stored in volatile and non-volatile memories.

For example, configuration values for a Modbus transducer are stored on a non-volatile memory like an EEPROM. Meanwhile, sensor values are stored and updated on an SRAM. Of course, the physical storage is abstracted for a PLC programmer. A programmer needs to know how to access the data with the address allocation of each data type.

Here’s where it gets tricky.

Modbus data frame takes in relative addresses and not absolute addresses. The absolute and relative address for the data types are as follow:

Fig 8- Modbus Addressing

The relative address is the result of discarding the tenth-thousandth decimal from the address. For example, an input register at an absolute address at 35,468 has a relative address of 5,468.

A device receiving the Modbus frame will determine the data type from the relative address by inspecting the function code. For example, a Read Holding Register request has a function code of 04, and the device automatically translates the relative address to 35,468.

It gets trickier.

The register address sent in a Modbus frame is deducted by one from the corresponding relative address. To read a coil at an absolute address at 00100, you’ll need to send a command request with an address of 0x63 (00099) in the data frame.

Extended Addressing

Each of the data types is allocated 9,999 memory spaces. Often, they will be sufficient for most applications. However, some devices require registries exceeding the standard allocation, and that's where extended addressing comes in.

Extended addressing stretches the address limits to 65,535 (0xFFFF), which is the maximum address possible with 2-byte addressing. The Modbus protocol remains the same in fields and syntax with extended addressing. However, devices that don't support extended addressing will respond with an exception when responding to a request with a vast address range.

How To Interpret Modbus Values

We wouldn’t call this a Bible of Modbus without showing what Modbus data packets look like when observed on a protocol sniffer software. Here, you’ll start piecing together what you’ve learned about Modbus and gain clarity.

Modbus Transmission Example 1 - Read Input Register

Let’s consider an example where a PLC reads 1 input register 30100 from a device (ID 2)

The PLC will transmit the following sequence in Modbus RTU (Hex).

02 04 00 63 00 01 C1 E7

Request frame breakdown.

• 02 - Device ID
• 04 - Function Code for Read Input Register
• 00 63 - the relative data address for 30100 deducted by 1
• 00 01 - the number of registers to be read.
• C1 E7 - the CRC checksum for the PDU.

The slave device responds with the next data frame.

02 04 01 5F 27 74 DA

Response frame breakdown

• 02 - Device ID copied from the received data frame.
• 04 - Function code copied from the data frame.
• 01 - the number of data bytes returned
• 5F 27 - the register value.
• 74 DA - the CRC checksum for the PDU.

The above protocol sequence is similar when you’re performing a Read Holding Register request.

Modbus Transmission Example 2 - Write Holding Register

Write holding register is usually used for setting configuration parameters on a Modbus device.

For example, a PLC writing 0x782A and 0xB7C3 into register 40078 and 40079 on a device (ID 3)

The request sequence will be as follow:

03 10 00 4C 00 02 78 2A B7 C3 B7 05

Request frame breakdown

• 03 - Device ID
• 10 - Function code 16 for writing multiple holding registers.
• 00 4C - starting address of the holding register.
• 00 02 - the number of registers to be written
• 78 2A B7 C3 - values to be written
• B7 05 - CRC checksum

When successfully executed, the device will respond with:

03 10 00 4C 00 02 81 FD

Response frame breakdown

• 03 - Device ID copied from the received frame.
• 10 - Function copied from the received frame.
• 00 4C - starting address of the written registers.
• 00 02 - number of registers written.
• 81 FD - CRC checksum

Modbus Transmission Example 3 - Read Multiple Coil

Understanding the data frame for reading coils (and discrete inputs) is more challenging, as each of the addresses holds only 1 bit. When retrieving multiple coil values, interpreting the value requires bit-wise identification.

A PLC reading 10 coils from an address 00500 from a Device ID 4 has the following request sequence.

04 01 01 F3 00 0A 4F 97

Request frame breakdown

• 04 - Device ID
• 01 - Function code
• 01 F3 - Starting address of the coil.
• 00 0A - number of coils to be read.
• 4F 97 - CRC checksum.

Assuming that coils 501 and 508 are set, the response will be as follow:

04 01 02 01 02 F5 AD

Response frame breakdown

• 04 - Device ID copied from the received frame.
• 01 - Function code copied from the received frame.
• 02 - number of bytes returned.
• 01 02 - binary representation of coil values.
• F5 AD - CRC checksum

The value of the coils returns as 0x01, 0x02. How does this correspond to the 10 coil addresses?

Modbus is a Big-Endian protocol. It means that the most significant bytes are transmitted first. Within a byte, the value starts with the most significant bit from left to right.

Therefore, the coil value can be mapped to the following columns.

Fig 9- Interpreting Modbus Coil Values

What Is A Modbus Map

Learning about Modbus protocol gives you an idea of how data is transferred and stored on Modbus devices. You now know the ‘how’ of sending and reading data on a Modbus connection. However, the Modbus protocol tells nothing about which information is being read or written.

You’ll have to turn to the Modbus map, documentation on which registers are used in a device and what they represent. Each Modbus device will have its own definition of the registers and coils. Therefore, you’ll need to refer to the user manual to learn how to set up and operate the device.

For example, the following screenshot denotes the Input Registers for APG LOE Ultrasonic Level Sensor. Only the specified address is used on the device, and they carry values specific to the sensor.

A Modbus map also includes a specific description of how data is stored on each register, including byte-ordering and valid values. The LOE Ultrasonic Sensor returns the following value on register 30299:

If you try reading a holding register not supported on the device’s Modbus map, you’ll get an exception error indicating it’s a non-supported address. The same goes for when you’re writing a value that is not supported on the device. The request sequence will be met with an 03 exception code.

How To Setup Modbus Communication?

There are many factors to consider when setting up a Modbus communication network. It’s possible to get overwhelmed if you don’t know where to start, and the challenge differs from what you’re trying to do.

Adding a single Modbus sensor on an existing Modbus network is relatively easy compared to setting up a new multi-device system. Nevertheless, both involve the following considerations.

Choosing The Right Device

A typical Modbus installation involves PLC and I/O units such as sensors, actuators, VFDs, and HMIs. For example, an irrigation control system requires a PLC capable of supporting Modbus RTU moisture sensor, PH sensor, and a VFD for flow control.

All devices must share the same Modbus protocol. If the moisture sensor works on Modbus ASCII, you’ll need a PLC that supports Modbus ASCII too. Most Modbus devices are based on Modbus RTU on serial communication, and web-based devices support Modbus TCP.

Never assume that a PLC will be equipped with the necessary Modbus driver for the devices. For example, some PLCs don’t have a built-in Modbus driver, which means you’ll need an additional Modbus interface module. Others may only support Modbus RTU but not Modbus TCP.

Is it possible to set up a Modbus network without a PLC? Yes.

Some systems work on a PC server, where a customized software is developed to configure and monitor the connected Modbus devices. The PC requires a serial communication port or ethernet connection, depending on the type of Modbus devices on the network.

Communication Infrastructure Installation/Upgrade

When you’re starting with a new installation, you’ll need to determine the transmission medium. Some sensors are built with only RS485 support, which limits communication over a serial twisted-pair cable. Others, like APG LOE Level Sensor, can be connected to an RS485 or an ethernet network.

Your choice of devices will determine the communication infrastructure for a new installation. If you’re upgrading from an old RS485 installation to an ethernet network, you can retain the existing Modbus devices. However, you’ll need a signal converter for RS485 to ethernet conversion.

In some setups, you’ll be installing Modbus devices on a non-Modbus network. For example, BACnet is the preferred protocol for building automation. If you’re adding a Modbus sensor on a BACnet network, you’ll need a Modbus gateway. A Modbus gateway converts Modbus to other industrial protocols.

Slave Device Setup

Setting up the slave device comes next, and it should never be overlooked. For Modbus RTU and Modbus ASCII devices, you’ll need to configure the Device ID. This is usually done through the DIP switches or setup software.

Having multiple Modbus devices with the same ID means more than one device will respond to a request. It results in corrupted data packets on the Modbus network.

It’s also critical to ensure that the devices share the same baud rate and serial communication settings (odd/even, parity bits, stop bits) as the master controller. Industrial devices usually operate with 9600 or 19200 baud and 8-N-1 serial port settings. Communication between master and slave is impossible if the settings are mismatched.

For a Modbus TCP slave device, you’ll need to configure the IP address and the TCP port for establishing a connection. The TCP port should match the same one used by the Modbus master.

Modbus Register Mapping

Chances are, you’ll be controlling a few devices on the Modbus network. Therefore, you’ll need to read up the user manual of those devices and familiarize yourself with the Modbus map.

The Modbus map provides details on what functions are available, which data addresses are accessible and how parameters are represented on the device. Modbus maps are unique to different manufacturers. Modbus sensors from various manufacturers will likely have different Modbus maps.

Master Controller/PLC Setup

Once you're done setting up the slave devices, you'll need to work on the master controller. The master controller, often a PLC, needs to be configured before sending and receiving Modbus packets.

Often, the configuration is done with the accompanying PLC software. The software allows you to set up the serial communication or ethernet port for Modbus connection. You'llYou'll need to configure the baud rate and serial communication settings for Modbus RTU or Modbus ASCII. Configuring the PLC for Modbus TCP requires setting up the IP address and TCP port.

To send or receive Modbus packets, you'll need to create communication channels or blocks with the PLC software. It involves specifying the device ID, function, and data address for each channel. The channels can then be used on the PLC program to send or retrieve the respective parameters. In TCP mode, each of the slave device's IP address needs to be set before connections can be established.

Note that how a Modbus channel is created, applied, and associated with program parameters differs across PLC manufacturers. You'll need to consult the PLC software manual for the finer details of controlling Modbus devices.

Customized PC-Modbus Software

A Modbus master is not restricted to a PLC. In some cases, a PC is turned into a Modbus master controller. The PC can be configured to communicate with a PLC or a network of Modbus slaves. In the former scenario, the PLC is configured as a slave.

A PC with Modbus capability requires the installation of customized software. The software is built to send and receive data packets from serial or ethernet ports. A PC Modbus setup is helpful for consolidating, processing, and analyzing data from Modbus sensors and devices.

How To Test Modbus Connection

Ideally, you’ll want a Modbus connection to be up and operational upon installation. However, there are times where things didn’t work out as you wish.

The PLC may fail to retrieve the measured value from a Modbus sensor, or configuration parameters sent are not saved on a connected device. In such circumstances, you’ll need to conduct a test on the Modbus connection.

You’ll need Modbus tester software that enables monitoring and sending of Modbus data packets. First, install the tester software on a PC and connect to the Modbus network. Then, monitor the packet exchange between the PLC and the sensor.

If the PLC is sending the correct packet but the slave does not respond, determine that the slave is configured correctly and does not suffer from hardware failure.

Sometimes, cabling faults will result in connection issues. To eliminate such possibilities, establish a direct connection between the tester software and the slave device. Then, send a valid request to the slave.

Carrying out the above measures will isolate where the problem lies — the master, slave, or the physical connection.

Are There Limitations To Modbus?

As versatile as it is, Modbus is not a perfect protocol. It does have a few limitations when it comes to real-life implementations.

Susceptible To Cable Fault

In an RS485 Modbus network, devices are connected in a daisy chain configuration. The Modbus connection is susceptible to cable fault and device failure. A disconnected cable will result in a partial or total outage of the network. Slave devices beyond the breakpoint are unable to receive incoming data packets from the master controller.

It is also possible for the communication port of a device to fail and pull down the entire RS485 bus, resulting in a total communication breakdown.

You wouldn’t have such issues with Modbus over TCP as each ethernet cable is routed to a network switch or gateway. However, failure on the network switch will affect devices linked to it.

Device Failure Reporting

Whether the Modbus device operates on an RS485 or an ethernet connection, the protocol is by nature half-duplex. It means that slave devices shall never initiate communication unless being sent a request. Therefore, a slave device may suffer failure on specific components, but the master controller remains oblivious unless it sends a request.

Security

Modbus data frames are unencrypted. The transmission can easily be intercepted by a sniffer tool by parties with ill-intention. The commands can be replicated and injected into the network to control or retrieve information from the connected devices forcefully.

Where Is Modbus Commonly Used and Why

Modbus remains the most preferred protocol for industrial automation and instrumentation. You’ll find Modbus devices installed in manufacturing, transportation, agriculture, oil & gas, healthcare, and other systems that require remote controls.

Almost every industrial product is equipped with Modbus functionality or integrable with a Modbus interface module. Instrumentation products like flow sensors and pressure sensors are available as Modbus transducers.

The ability to automate and acquire instrumentation data by sending simple commands proves to be popular throughout the decades. Modbus protocol remains viable and practical even with modern interfaces. It is possible to send Modbus packets over ethernet, fiber optic, and wireless networks without altering the protocol format.

Modbus For Liquid Management

If you’re in the oil & gas and agricultural industry, liquid management is a subject that demands detailed attention. Instrumentation precision is mandatory in both sectors. Incorporating Modbus into sensors enables measured values to be retrieved accurately by the controllers.

How Modbus Works In Measuring Different Mediums

Agriculture

In the agricultural industry, managing water level and flow is vital for irrigation systems. It’s crucial to ensure that the crops receive the right amount of water after considering the weather, soil PH, and other factors. As such, flow sensors and level sensors play an essential role in the industry.

In an irrigation system, the flow sensor detects how much water is channeled to the pumps and sprinklers, while the level sensor ensures that the tank holds sufficient water. Both sensors are connected to a centralized PLC.

Modbus is the connection of choice as it is economical, simple, and a commonly-used automation protocol. The sensors would measure the parameter, hold the values in the transducer’s memory, and send them to the PLC upon request.

Oil & Gas

The oil & gas industry requires strict compliance with regulations. It is, by itself, a complex operation that demands sophisticated monitoring and control systems. Therefore, it is only natural for an oil rig platform to be installed with various types of sensors.

Level sensors are a standard instrumentation product in the oil & gas infrastructure, are used at oil tanks and for measuring drilling fluid in mud tanks. It’s complemented by flow switch installations that help monitor gas, fuel, or wastewater flowing through the pipes.

Oil quality monitoring is aided by viscosity sensors, which help detect potential contaminants or aging by reporting viscosity and temperature in real-time.

When installed on a Modbus network, a PLC or central server can retrieve the parameters from the sensors. The sensors are built with a Modbus controller, which responds to request commands by sending the parameter through the Modbus frame.

Why Choose Modbus Over Other Options?

Their output types can broadly segregate industrial sensing products. The outputs are either digital, analog, or protocol-based.

A float switch with an on-off state produces a digital On and Off signal when wired to a PLC.

Meanwhile, a contiguous float sensor transmits the measured value over an analog channel, often via 4-20 mA or a varying voltage range. Finally, protocol-based sensors return the measured values by data packets.

Both agricultural and oil & gas sectors are known for their harsh operating conditions. Sensors need to be robust and capable of transmitting accurate values to the PLC over a considerable distance. This makes digital and analog voltage signaling poor choices for both industries.

Digital signals are susceptible to interference and cable fault. For example, the PLC could read a false positive if the cable is shorted or will never receive any positive input if it’s disconnected.

Meanwhile, transferring analog voltage over a lengthy cable is not a good idea. Voltage readings are susceptible to differential drop due to the cable’s resistance. The voltage drop will affect the reading accuracy at the PLC unless it’s manually compensated.

The 4-20mA current transmitting sensor seems to be a good choice as it’s not compromised by cable fault or resistance. However, each sensor will require a 2-wire direct connection to the PLC. It isn’t the most cost-effective measure when you have dozens of sensors spanning across a large area.

Protocol-based sensors, specifically Modbus, remain the ideal option for complex automation and instrumentation. Modbus minimizes cabling cost, is simple to operate, and is supported by a massive range of industrial products.

Summary

Modbus is a technology from the past, but it remains relevant for the foreseeable future. It will remain a prominent fixture as industries evolve. Its simplicity appeals to system engineers and non-programming technicians.

Modbus remains relevant, despite the introduction of modern, high-speed connectivities. System integrators will favor Modbus for large-scale installations for its economic advantage.

Contact us to find out more about how Modbus technology can be used for your oil or water measurement needs.