Modbus Master Connector

Devices compatible with Modbus protocol.

Overview

Modbus driver implements communication with PLC and IO devices compatible with Modbus Open Standard protocol. It operates as a Client on TCP/IP or serial networks. The communication blocks are dynamically created according to the pooling cycle defined on the AccessType for each Device Point.

The following drivers are related with the Modbus Protocol:

• Modbus Master Protocol.  (this driver)
• Modbus Slave Protocol
• Schneider Electric Control Expert Unity Pro PLCs. Relies on Modbus protocol, but it was its own Import Wizards.

Master Slave Nomenclature

The terminology Master and Slave refers to the original Modbus terms. The Modbus Organization announced the replacement of "master-slave" terminology with "client-server" in its communications protocol. The new nomenclature reflects the specific roles of the devices within the Modbus network. Here's the definitions:

1. Modbus Master (Client): In the context of the Modbus protocol, the "master" is the device that initiates communications. It’s called a Client because it requests data from other devices. The master actively controls when and how data is requested and collected in the network.

2. Modbus Slave (Server): Slave devices are referred to as Servers because they serve data to the master upon request. They passively wait for requests and respond by sending the requested data or performing actions based on the commands received. They do not initiate communication; they only respond to the master’s requests.

In the product User Interface, as will in the documentation URLs, we opted to keep the original historical nomenclature, in order to ensure compatibility, as well to avoid potential confusion with the terms Server and Client which already have other meanings in the context of the software platform.

Connector Configuration

At Designer, solution configuration tool, add the connector at:

• Devices / Protocols

The following options are also available to this connector:

• Solution / TagImport Wizards
• UNS Tags / paste rows from clipboard

This document has only information about the device connection settings and its address syntax.

For further Information on its configuration, see:

• Devices Module
• Devices Module Reference

The configuration for this protocol can be created using The Tag Import CSV tools, or copy-paste directly to UNS Tags table.

Supported Operands

Channels Configuration

Protocol Options

• BlockSize: Defines the maximum amount of items per group, the default value is 250.

If the communication points are configured in sequence and the BlockSize equals to 250, the driver can create the internal groups with 125 Registers or 2000 Coils.

• Encoding:  Determines how the information will be packed into the message fields and decoded. The options are:
  • RTU: Remote Terminal Unit mode, where each 8–bit byte in a message contains two 4–bit hexadecimal characters
  • ASCII: The message is encoded in ASCII mode, where each 8–bit byte in a message is sent as two ASCII characters
  • RTU TCP: The default transmission mode when the message is carried on a MODBUS TCP/IP network. It contains information to allow the recipient to recognize message boundaries even if the message has been split into multiple packets

• SingleWrite: Indicates the driver behavior for the writings with only one item:
  • Use block write : The driver uses the 0x0F command for Coils, or the 0x10 (Function Code 16) command for Holding Registers
  • Use single write: The driver uses the 0x05 command for Coils, or the 0x06 (Function Code 6) command for Holding Registers

• Offset address:  Indicates the driver is zero based address.

Settings

Serial and MultiSerial channels:

• Default configuration for ASCII mode :
  • DataBits: 7
  • StopBits: 1 if parity is used; 2 if no parity is used

• Default configuration for RTU mode :
  • DataBits: 8
  • StopBits: 1 if parity is used; 2 if no parity is used

Set the other fields according to your Serial or MultiSerial port configuration.

TCP/IP channels:

• NodeConnections: Defines the maximum number of parallel requests that will be sent to each node (asynchronous communication)

Nodes Configuration

Station Configuration

• SlaveId:  Set this field with the address of the slave device in the Modbus Network. They can be addressed from 1 to 247 for serial nodes, or 0 to 255 for TCP/IP nodes. The address 0 is used for the broadcast.

Serial channels:

• Station syntax: <SlaveId>

E.g.: 1

MultiSerial channels:

• Station syntax: <Com Port> ; <SlaveId>

Where: 

<Com Port>: the serial port number

• Ex: com1 ; 1

TCP/IP channels:

• Station syntax: <IP address> ; <Port number> ; <SlaveId>

Where :

• <IP address>: IP address of the slave device in the modbus network
• <Port number>: TCP port where the slave device is listening (default is 502)

E.g.: 192.168.1.101 ; 502 ; 1

Points Configuration

The syntax for the Modbus communication points is: <Operand><Address>

Where:

• <Operand>: indicates the memory area
• <Address>: indicates the data address in the memory area, from 1 to 65535

E.g.: 400001 (Operand = Holding Register, Address = 1)

 Configure ASCII Communication:

• To use the ASCII communication with Modbus, it is necessary to modify the column Modifiers. In StringLength you need to put an even value number.
• Create a new AccessType to use only with ASCII type points.

Device Identification (Function 43)

Devices that implement MODBUS function 43 with MEI type 14 (Read Device Identification) publish a set of standard text objects describing themselves: vendor name, product code, revision and, optionally, model and application names. The connector reads these objects as read-only text Points, so a solution can identify equipment automatically instead of depending on vendor specific holding registers mapped by hand for each device model.

Addressing

Use the ID operand. The address is the MODBUS Object Id itself, 0-based, written with the same 5-digit padding as any other Modbus address. The object ids below are defined by the MODBUS specification and are the same on every device that implements the function.

E.g.: ID00001 reads the device product code.

Configuring the Points

• Identification Points are read-only. Write commands to them are rejected.
• Bind them to Text tags. The values are text; a numeric tag displays 0 with no error.
• The Offset address option in the channel Protocol Options does not apply to these Points. Object ids are always 0-based, whether or not that option is enabled for register addressing.
• The length of each value comes from the device itself, so the StringLength modifier used for ASCII register Points is not needed here.
• All identification Points of a node are served by a single request per poll, whatever their object ids, so adding more of them costs no extra communication.
• Identification data is static. Assign these Points to a slow AccessType rather than polling them at process data rate.

When identification data is not available

AccessType Configuration

To perform block writes (as done with function 16), you should use WriteTrigger-based writing so that all addresses are sent in the same block (i.e., within the same network packet). To do this, create a separate Devices / AccessType with the “WriteEvent” column disabled, and add a tag in the WriteTrigger column to trigger the message.

Troubleshoot

Driver Revision History

In this section...

In this section...