Introduction

The Modbus I/O Servers are CDPComponents that convert CDP values to and from the Modbus protocol format. For more information about Modbus details, refer to the MODBUS protocol specification.

For a step-by-step setup guide on how to set up both a Modbus Master and a Modbus Slave, see the Modbus TCP Master and Modbus TCP Slave setup guide.

Usage

To implement Modbus communication in CDP Studio, determine the transport type (Serial, UDP, or TCP) and whether your device will act as a Modbus Master (client) or Modbus Slave (server). Choose the appropriate model from the ModbusIO resource.

Pre-configured Models

For devices with stackable modules (e.g., Wago, B&R, Weidmueller), select one of the pre-configured IOServer models, such as ModbusIO.Wago-750-UDP or Weidmueller-UR20-FBC-MOD-TCP. These models have pre-configured device settings and a pre-setup IO packet that allows you to add modules in physical order, simplifying the setup.

Generic Models

If your device does not have a pre-defined setup in CDP Studio, use the following models:

• ModbusIO.ModbusMasterTCP, ModbusIO.ModbusMasterUDP, ModbusIO.ModbusMasterRTU for Modbus masters (clients)
• ModbusIO.ModbusSlaveTCP, ModbusIO.ModbusSlaveUDP, ModbusIO.ModbusSlaveRTU for Modbus slaves (servers) (see Modbus Slave Setup below)

Modbus IOServers organize data in packets, each containing a SlaveId, FunctionCode, ReadAddress, and WriteAddress. The packets contain IOModules, which contain the data represented by CDPSignalChannels. A packet can contain one or more IOModules that together make up the Modbus packet data.

You need to know the address and size of the data for your Modbus device. Some devices may require multiple packets to handle all the necessary data. Always refer to the device’s datasheet to avoid mistakes.

Modbus Protocol Quick Guide

Modbus is a request/reply protocol with one client (Modbus master) and one or more servers (Modbus slaves). Each slave has a unique address (SlaveId). CDP Studio supports SlaveIds from 0 to 255, with SlaveId 0 reserved for broadcast requests when using Modbus/RTU.

The Modbus master sends a request to the slave, and only a slave matching the SlaveId will respond.

Modbus Requests and Function Codes

Each request from the Modbus master contains a FunctionCode, which instructs the slaves on what action to perform. CDP Studio supports the following FunctionCodes:

Data Handling

• Write requests are filled with values from Input=1 CDPSignalChannels.
• For Read requests, the Modbus response data is decoded into the Input=0 CDPSignalChannels.
• See ModuleOrdering, DigitalModuleHandling and DigitalRegistersAreLinear for special ordering options.

Commonly used FunctionCodes include ReadWriteMultipleRegisters, ReadHoldingRegisters, and WriteMultipleRegisters. Other FunctionCodes exist for compatibility with older devices.

Addressing

The Modbus master packet specifies the ReadAddress and/or WriteAddress for where the slave should begin reading or writing data. If certain addresses should not be accessed, split the data into multiple packets with different start-addresses.

Modbus addresses are 16-bit and range from 0 to 65535. Each address typically identifies a 16 bit value. Some manufacturers use 1-based addressing and/or add a prefix to signify address type. See the translation table below. CDP Studio uses 0-based addressing.

Modicon to CDP Studio Translation Table

Some vendors use '1', '3' and '4' prefixes to their Modbus address to signify both access type and address. The conversion to a CDP Studio modbus address is done by removing the prefix and subtracting 1 from the address, as shown in the table below:

Transport Configuration

Configure the transport to determine how the IOServer sends and receives data. Supported transports include:

• TCPTransport
• UDPTransport
• SerialTransport

The Transport has a configurable Timeout in seconds (e.g., 0.5). This defines how long to wait for a response after sending a packet.

Pre-made ModbusIOServers

Pre-made Modbus IOServers simplify device configuration. These models typically include an IO packet and (possibly watchdog) initialization packets, as well as advanced settings to make the modules map correctly into the modbus data packet. To configure these IOServers, set up the transport and add modules matching the physical configuration to the pre-defined packet(s).

Generic Modbus Configuration

To configure a generic Modbus I/O server:

• Set the fs property to define the periodic Send-rate of a Modbus master.
• Set the transport layer in the Transport table (UDP, TCP, or Serial) and define a sensible Timeout.
• Unless there are pre-made packets that can be used, add and configure packet(s) in the Packets table.
• Add IOModule(s) to packets to determine the data to read or write.
• Make sure the IOModules have CDPSignalChannels in correct order and size so that they 'map' into the modbus data packet.

If a pre-configured IOServer is not available, additional properties (e.g., DigitalModuleHandling, DigitalRegistersAreLinear, and ModuleOrdering) must be configured.

Debug Information

Set the Debug property to enable various levels of debug output to the Application log:

• 0 – Only startup errors are printed.
• 1 – Prints configuration details during Configure() and connection information during packet sends.
• 2 – Prints packet data sent and received.
• 3 – Prints byte offsets for mapped channels.

Watchdog

Some Modbus slaves have a watchdog function, which resets device outputs to a default state if communication is lost. When enabled, the Modbus master must send packets fast enough to prevent the watchdog from timing out.

Value Change on Error

When a Modbus Packet goes offline, it defaults to setting all physical input channels to 0. Use the KeepLastValueOnDisconnect argument to change this behavior:

• 1 – Retain the last values of physical inputs when the packet goes offline.
• 0 – Set physical inputs to 0 when the packet goes offline.

To change the default behavior for all packets, adjust the KeepLastValueOnDisconnect property in the ModbusIO component.

Principle of Operation

Every period (as defined by fs), the Modbus master will try to send packets that are marked ready to send, in the order they are defined. If a response for a packet is not received within the Transport Timeout (or packet ResponseTimeout, if configured), then that slave ID is marked as inactive and put at the end of a retry list together with a time for when to retry. See ExponentialBackoffTime for more information on the exponential backoff time calculation.

After sending all packets that are marked ready to send, the Modbus master will pick the first packet from the retry list which is at or later than the packet send Time, and try to send that. When ResponseTimeout is set to a sensible value in relation to the Modbus fs, this ensures that non-responding Modbus slaves will cause minimal disturbance for the other responsive Modbus slaves.

The Modbus master implements the internal states Init, Error and Online for handling of each Modbus SlaveId as shown in the image below. The states correspond to the packet SendMode, except that state Online handles packets with SendMode Periodic, Trigger and OnChange:

A Modbus slave receives requests from a Modbus master. If the request matches a defined packet, then that response packet is returned to the Modbus master. If there is no matching Modbus SlaveID, or there is a Broadcast request (slave ID 0 for Modbus/RTU) then no response is returned to the Modbus master.

States and Status

The Modbus I/O has the following states, as represented by the CurrentState property:

The signals NumberOfNodes and NumberOfNodesOnline can be used to tell how many packets are configured, and how many nodes are online.

Each packet also has an Online Property that is continuously updated based on the reception of data.

When the Modbus IO goes Offline, the Transmission Error alarm is set, indicating a failure. See CDPAlarm for more information on how to set up Alarms.

Packets

Periodic packets are sent at the configured I/O server frequency (fs).

A Modbus slave packet has the following settings:

A Modbus master packet has the following additional properties:

ExponentialBackoffTime Timings

Modules

A Modbus packet in CDP Studio contains one or more modules. Modules are named groupings of channels and are typically used to reflect a physical I/O module. Many hardware manufacturers have stackable modules that can be put on their bus couplers to add physical conversion to and from physical signals.

To enable easy configuration of these, the concept is mirrored in CDP Studio.

A Modbus I/O Module has the following properties, most of which are there to handle module/data-packing quirks:

Digital Channels in Modules

Boolean (digital) channels are bit-packed into 16-bit Modbus registers so that the first channel becomes bit 0, the next is bit 1, and so on. Bitpacking per module is done according to the configuration of DigitalModuleHandling. Digital channels from adjacent modules are put together according to the ModuleOrdering configuration.

Large Data-types

The Modbus standard does not specify how to transfer data larger than 16 bits. This poses a challenge when working on data types larger than 16 bits, as the byte sequence of that data is not properly defined. The CDP Automation add-on defines a ByteSwap operator operator which can be used to manipulate the byte order of a signal.

In Modbus, int, {unsigned int},float, double and other large datatypes might require a ByteSwap operator on that signal to be converted correctly, depending on the implementation in the device being communicated with. IEEE754 defines the byte sequence for floats and doubles, but some devices send these values byte-swapped. For instance, the byte-sequence of float data '0123', where 0,1,2 and 3 represent bytes in the float, could be sent as '2301'. As devices have different implementations of the byteswapping of large data-types, it is advisable to test that the values sent match the values received. We recommend using a 'Hex to float' converter to test this. By generating a known number on one side, it is possible to test that the other side converts this correctly, and if not, use the 'Hex to float' converter to determine how the swapping becomes incorrect.

For instance, the hex value '0x1122331f' corresponds to the float value '1.27953e-28'. '11' fills one byte, '22' fills the next byte, '33' fills the third byte, and '1f' fills the last byte. (Note that the last byte can not be '44' due to restrictions in the IEEE 754 floating-point format). Send the value '1.27953e-28' from the transmitting side, and check the hex value that is received in a 'float to hex' converter. By looking at the byte positions of '11', '22', '33' and '1f' in the received hexadecimal number, it should be possible to determine how the ByteSwap operator should be configured to produce the correct result.

See ByteSwap operator for more information about the ByteSwap operator.

I/O Channel Scaling

Physical analog I/O modules typically accept 2-byte (short) values from the control-system. To see how these values map to physical values, please consult the manufacturer documentation for the module in question.

Let's say you are controlling a +/- 10 Volt output. In CDP Studio, your program code might be working with the values -1 to 1, since it is convenient to decouple the external details from your code. By looking up the manufacturer documentation for the Analog Output module, you learn that the module will output -10 Volt when it receives the value -32768, and that +10 Volt is output when the module receives a value of 32767. Values in-between scale linearly between -32768 and 32767.

We can add a ScalingOperator<double> to the output channel that scales the value '-1' to '-32768' and the value '1' to '32767':

The above scaling-operator scales an input of -1 to -32768 , 0 is 0 and 1 is scaled to 32767. See the ScalingOperator for more information about how the scaling is done and how it works.

Value Change on Error

When a Modbus Packet goes to Offline state, the default behavior is to set all physical input channels to 0. It is the Packet Argument KeepLastValueOnDisconnect that controls this behavior:

• When it is set to 1 and the packet goes Offline, the packet keeps its physical input values to its last value.
• When it is set to 0 and the packet goes Offline, the physical inputs in the packet are forced to value 0.

All packet KeepLastValueOnDisconnect Arguments are by default Routed to the governing KeepLastValueOnDisconnect property that is present in the ModbusIO component:

To change the default behavior so that all packet physical inputs hold their last values when the packet(s) go Offline, change the ModbusIO KeepLastValueOnDisconnect property to 1.

If you have KeepLastValueOnDisconnect set to 1 in the ModbusIO, and only want to change an individual packet's behavior so that it sets its physical inputs to 0 when it goes Offline, remove the Routing in the KeepLastValueOnDisconnect Argument for that packet, and set the Argument Value to 0:

See also the related topic Safe Value CDPSignals.

Modbus Slave Setup

The Modbus slave is set up from the perspective of the Modbus master. If the Modbus master has a packet with 'ReadHoldingRegisters', then the slave should also be set up with a packet with 'ReadHoldingRegisters'. The only difference is in the CDPSignalChannels' Input property, which is set up inversely to that of the Master. In other words, set up the Modbus slave packet exactly as you would set up the Modbus master packet, but make sure to invert the Input in the Modbus slave CDPSignalChannels relative to the Modbus master channels.