Modbus Protocol Support

Robotics & Industrial

Modbus RTU/TCP

What is Modbus?

Modbus is a serial communication protocol originally published by Modicon in 1979, now one of the most widely used protocols in industrial automation, building management, energy systems, and SCADA applications. Modbus defines a master-slave (client-server) architecture where one master device communicates with up to 247 slave devices. Two primary serial variants exist: Modbus RTU (binary encoding with CRC-16 error checking) and Modbus ASCII (ASCII hex encoding with LRC error checking). Modbus RTU is the more common variant, operating over RS-232, RS-422, or RS-485 physical layers at baud rates typically ranging from 9600 to 115200. The protocol defines function codes for reading discrete inputs, reading coils, reading holding registers, reading input registers, writing single/multiple coils, and writing single/multiple holding registers. Each transaction consists of a device address, function code, data payload, and error check. Modbus is valued for its simplicity, reliability, and broad device support across thousands of PLCs, sensors, meters, drives, and actuators from hundreds of manufacturers. Protocol analysis for Modbus is essential in industrial environments to diagnose communication failures, verify register maps, debug exception responses, and optimize polling cycles. Engineers need to decode Modbus frames to identify device addressing errors, function code mismatches, register value discrepancies, and CRC failures that prevent reliable data exchange.

Modbus Quick Reference

type Serial, asynchronous (RTU) or TCP
signals RS-485 differential or Ethernet
max Speed 115.2 kbps (serial)
voltage Range RS-485 differential
topology Master-slave

Acute Instruments Supporting Modbus

Recommended Solutions

Recommended for Decode

TB3016F

TB3016F

With Analog Channels

MSO2116E

MSO2116E

All Supporting Products

Protocol Decode
Hardware Trigger
Protocol Exerciser

LA4000 Series

MSO2000 Series

TravelBus Series

TravelLogic Series

Ready to analyze this protocol?

See how Acute instruments capture and decode this protocol in real time. Request a demo or contact our team.

How to Analyze Modbus with Acute Instruments

1

Connect your Acute logic analyzer to the Modbus serial lines — TX and RX for RS-232, or A and B data lines for RS-

2

Attach a ground lead to the system ground reference.

3

In the Acute software, select the Modbus RTU or Modbus ASCII protocol decoder and assign the data channels.

4

Configure the baud rate, data bits (typically 8), parity (even, odd, or none), and stop bits to match the Modbus network settings.

5

Capture and view decoded Modbus frames showing slave addresses, function codes, register addresses, data values, CRC/LRC status, and any exception responses.

Frequently Asked Questions

What sample rate do I need for Modbus analysis?
Modbus serial communication typically runs at baud rates between 9600 and 115200. For reliable decoding, sample at 8x to 16x the baud rate. For 9600 baud, 100 kHz is sufficient. For 115200 baud, use at least 1 MHz. These rates are easily within the capability of all Acute logic analyzers.
Why is my Modbus decoder showing CRC errors or incomplete frames?
Modbus RTU uses 3.5-character-time silence gaps to delimit frames. If the decoder settings do not match the actual baud rate and framing (data bits, parity, stop bits) exactly, frames will not be properly delimited and CRC calculations will fail. Verify these settings match the actual network configuration. For RS-485, also check that the direction-enable timing does not truncate the start or end of frames.
How many channels are needed for Modbus analysis?
For RS-232 Modbus: 1-2 channels (one per direction, TX and RX). For RS-485 half-duplex Modbus: 1 channel for the data line, optionally adding a second for the direction-enable (DE/RE) signal. For RS-485 full-duplex: 2 data channels. Most industrial Modbus networks use RS-485 half-duplex, so a single data channel is sufficient.

Related Protocols

Need help choosing the right instrument for your protocol? Contact our engineering team.