Industrial Automation
Industrial Automation | Europe


Main > Product Type > Automation Systems > Networks
Minimize Text   Default    Enlarge Text


Getting Started With Modbus

This article will help you getting started implementing a Modbus-IDA solution, and to understanding other data sources and sample programs that are available.
The basic MODBUS protocol

MODBUS is a communications protocol originally developed by Modicon in 1979. It is currently managed by the Modbus Organisation. It can seem quite a primitive protocol (i.e. Modbus messages lack basic features such as terminators) but it is very popular within the industrial automation industry, and many Omron devices support it.

A basic MODBUS message consists of a single byte function code, followed by a variable length data segment. The length of the data depends on the function code. The MODBUS protocol includes a basic memory model for devices - each device is seen as consisting of a sequence of coils (boolean flags) and registers (2 byte words). Registers may be either read-only (input registers) or read-write (holding registers). When a device receives a MODBUS message, it is responsible for mapping the MODBUS message to an actual memory location or change in device behaviour. For example, when a device receives a request to write a value of true to coil 1, it may interpret this as a "run" command, whilst a value of false may be interpreted as "stop".

The specification for the base MODBUS protocol is here.

To learn more about the benefits of Modbus integration on a real pack stacking machine, explore the customer reference in the packaging solutions area.


MODBUS serial communications

For RS232 and RS485 MODBUS communications, a wrapper is added to the base protocol. The wrapper consists of

  • Slave address: 1 byte - identifies the target device
  • Modbus message: variable length
  • CRC: 2 bytes
  • Slave address Function code Data CRC

The CRC is a checksum calculated according to a standard mathematical algorithm (CRC-16-IBM).

MODBUS serial communications support 2 transmission modes:

  • RTU: 11 bit format. Default mode for all devices and mandatory support.
  • ASCII: Optional mode for 10 bit format requiring 2 bytes per character.

The specification for MODBUS over serial can be found here.


When used over TCP/IP, a 7 byte header is added to the start of every MODBUS message. This header consists of the following fields:

  • Transaction ID: 2 bytes - this is used to link requests to responses
  • Protocol ID: 2 bytes - always set to 0
  • Length: 2 bytes - Length of the rest of the message (including unit ID)
  • Unit identifier: 1 byte - identifies the target device. This may be translated into a slave ID when gatewaying to serial MODBUS devices.

The specification for MODBUS TCP/IP can be found here.

Links to Samples
Protocol Master/Slave Hardware Type Link
RTU Master CJ1, CS1, CP1L, CP1H for 3GMV, V7 Function Block sample
RTU Master CP1L to CelciuX/EJ1N, V1000 Function Block + ladder sample
RTU Master CJ/CS/CP to MX2/RX or JX/MX-Inverter Function Block sample
RTU Master CJ1, CS1, CQM1 Ladder sample
RTU Master for EV, HV and FV Protocol Macro sample
RTU Master for 3G3MV Protocol Macro sample
RTU Master CP1H to E5CN Easy Master sample
RTU Master NQ to MX2 Inverter Tag list sample
RTU Master NS to JX/MX invertor (using PLC Modbus master) SAP sample
RTU Master General purpose CX-Supervisor application sample
RTU Slave CJ1, CP1L, CP1H Function Block sample
RTU Slave CJ1, CS1, CP1L Ladder sample
TCP Client CJ1, CS1, CJ2 Function Block sample
TCP Client DyaloX, IPC CX-Supervisor Tutorial
ASCII Slave CJ1, CS1, C200, CQM1 and CPM2  ladder sample



Comments (View All Comments / Add Comment)

Related Articles
No related articles found.
Created 2009-08-18
Modified 2020-10-08
Views 113515


You are not logged in.