Modbus serial protocol decoding

4 channel differential oscilloscope

See the difference with the new PicoScope 4444

With four true differential channels, the PicoScope 4444 enables high-resolution measurements of differential voltage waveforms. This oscilloscope eradicates the problem of making accurate voltage waveform measurements on circuit elements that are not ground-referenced, without the risk of short circuits that could damage the device under test or the measuring instrument.

4 channels
20 MHz bandwidth
Flexible 12-bit or 14-bit resolution
Up to 400 MS/s sampling rate
256 MS capture memory
High common-mode rejection ratio
Balanced high-impedance inputs for a low circuit load

From just ^£899

Introduction

Modbus is a low-speed serial data protocol commonly used in industrial applications where a supervisory computer (master) controls or monitors multiple remote devices (slaves).

The specification was originally published in 1979 by Modicon (now Schneider Electric) for use with its programmable logic controllers (PLCs).

In a standard Modbus network there is one master, and up to 247 slaves each with a unique address from 1 to 247.

PicoScope (Beta) software provides support for Modbus RTU and Modbus ASCII.

Modbus protocol versions

Several versions of Modbus have been developed to suit the transmission medium being used. Most common are:

Modbus RTU (Remote Terminal Unit) - typically for use over RS-232 single-ended or RS-485 differential lines, uses binary coding and CRC error checking.
Modbus ASCII - also for use over RS-232 or RS-485 lines, uses ASCII characters instead of binary, making it more readable but less efficient, and it uses less effective LRC error checking. ASCII mode uses ASCII characters to begin and end messages whereas RTU uses time gaps of 3.5 character times for framing. Modbus ASCII messages require twice as many bytes to transmit the same content as a Modbus RTU message.
Modbus TCP – for use over TCP/IP networks, typically Ethernet, (not currently supported by PicoScope).

Modbus frame structure

The Modbus protocol defines a Protocol Data Unit (PDU), which is independent of the underlying communication layers. Additional fields may be introduced in the Application Data Unit (ADU) depending on the type of bus or network employed.

Protocol Data Unit (PDU) contains:

The Function Code that indicates the kind of action to be performed.
The Data Field of frames sent from a master to slave devices that contains additional information about action defined by the function code. This can include items like discrete and register addresses, the quantity of items to be handled, and the count of actual data bytes in the field. The data field may be nonexistent (of zero length) in certain kinds of requests.

Application Data Unit (ADU) contains:

The Protocol Data Unit (PDU)
The Slave ID
The CRC Error Check

Error Codes - When the server responds to the client it uses the function code field to indicate either a normal (error-free) response or that some kind of error occurred, called an exception response. For a normal response the server simply echoes the original function code and returns the data requested.

Data storage

Data is stored in slave devices in four different tables. Two of them store on-off (1-bit) values called Coils and Discrete Inputs, and two store numerical values as 16-bit words called Registers. Each is either read-only or read/write.

Each table has 9999 locations.

Function codes

There are three categories of Modbus function codes:

Public Function codes – From 1 to 127 except for user-defined codes, validated by Modbus.org community, publicly documented and guaranteed unique.
User-Defined Function Codes – in two ranges from 65 to 72 and from 100 to 110.
Reserved Function Codes – Used by some companies for legacy products and not available for public use.

Examples of commonly used function codes are shown in the table.

The full specification for Modbus is freely available from www.modbus.org

Decoding Modbus with Picoscope

When errors occur, troubleshooting with a PicoScope using Modbus protocol decoding allows you to correlate decoded frames with the data captured by the oscilloscope. This helps identify where data is corrupted due to noise, interference or incorrect voltage levels, for example.

Acquiring Modbus data on your PicoScope

Use two oscilloscope channels, one for the master transmit lines and the other for the slave transmit lines. Where Modbus is transmitted over RS-422 or RS-485, use differential probing.

Set memory length to enough to acquire as many frames as required, and with enough sampling resolution to resolve individual bits.

Alternatively use the buffer memory index to capture short bursts of frames whilst ignoring any dead time in between.

Use the horizontal zoom control to view a single frame in detail.

Add a second scope view to display master and slave data frames simultaneously.

Modbus Master and Slave waveforms captured and displayed on PicoScope

Setting up the Modbus decoder

Select Serial Decoding from the Tools menu.

List of PicoScope serial bus decoders, with Modbus selected.

Click Create and choose from either Modbus RTU or Modbus ASCII.

In the setup window most fields are automatically populated. Just define which channel is master and which is slave.

If Graph is checked, a colour-keyed trace will appear in the graph display, time-correlated with the acquired data.

If Table is checked, all the data will be presented in a table format. There are several useful features available with the table:

Double-click a frame in the graph format and the corresponding frame will be highlighted in the table.
Select Export to save the table data in CSV format.
Set up a Link file so that data in the table can be displayed as meaningful text.
Filter on the table to search any field for specific values - for example, invalid CRCs.

PicoScope Modbus decoded waveforms in graph and table formats

Summary

Modbus RTU and Modbus ASCII decoders are a standard feature with PicoScope (Beta) software and can be used with all real-time PicoScope models.