Modbus Configuration Manual
The Modbus I/O Servers are CDPComponents that transform CDP values to and from the format required by the MODBUS protocol specification.
Click here for a quick guide how to set up a Modbus TCP Master/Slave Demo
Modbus Protocol Quick Guide
Modbus is a Request/Reply protocol where there is one master and one or more slaves. The master sends a Request to the slave(s) and the slave(s) process the Request and return a Reply. Each request contains register values, where each register is defined as 16 bits of data. There are several types of requests (FunctionCodes) a Modbus master can issue. The following FunctionCodes are supported by CDP Studio:
|Name of Function Code||Number||Description|
|ReadCoils||0x01 / 01||The master requests the slave to return a range of coil (digital) values. This FunctionCode can be used if the packet contains only physical digital input data|
|ReadDiscreteInputs||0x02 / 02||The same as ReadCoils, but FunctionCode is 2.|
|ReadHoldingRegisters||0x03 / 03||The master requests the slave to return a range of register values. This FunctionCode can be used if the packet contains only physical input data.|
|ReadInputRegisters||0x04 / 04||The same as ReadHoldingRegisters, except the functioncode is 4.|
|WriteMultipleCoils||0x0f / 15||The master requests the slave to write a supplied range of coil (digital) values to the specified register range. This FunctionCode can be used if the packet contains only physical digital output data.|
|WriteMultipleRegisters||0x10 / 16||The master requests the slave to write a supplied range of register values to the specified register range. This FunctionCode can be used if the packet contains only physical output data.|
|ReadWriteMultipleRegisters||0x17 / 23||The Modbus master asks the modbus slave(s) to write an amount of data to registers starting at specified address, and to return a specified range of register values. This FunctionCode can be used if the packet contains both physical input and output data.|
Typical function codes used are ReadWriteMultipleRegisters, ReadHoldingRegisters and WriteMultipleRegisters. The other functioncodes are there to provide compatibility with old devices.
Note: The FunctionCode must be selected according to the data in the packet. Only if there is both input and output data in the packet, can FunctionCode ReadWriteMultipleRegisters be used. For only physical inputs, use ReadHoldingRegisters, and for only physical outputs, use WriteMultipleRegisters.
Note: CDP Studio does not do any mapping of ReadAddress or WriteAddress according to the functioncode. (f.i. the ReadHoldingRegisters function code can be used with any modbus address, not just the 40000 (decimal) address range). It is the user's responsibility to set up the Read and Write addresses correctly.
Modbus in CDP Studio
The Modbus protocol is implemented in the following base I/O-servers:
|ModbusMasterUDP||A modbus master that sends Modbus/TCP requests to a slave using the UDP network protocol.|
|ModbusMasterTCP||A modbus master that sends Modbus/TCP requests to a slave using the TCP network protocol.|
|ModbusMasterRTU||A modbus master that sends Modbus/RTU requests to a slave using a serial bus protocol.|
|ModbusSlaveUDP||A modbus slave that accepts Modbus/TCP requests from the UDP network protocol|
|ModbusSlaveTCP||A modbus slave that accepts Modbus/TCP requests from the TCP network protocol|
|ModbusSlaveRTU||A modbus slave that accepts Modbus/RTU requests from a serial bus protocol|
In addition, some pre-configured I/O-servers have been made, to simplify setting up Modbus communication with supported devices, see Pre-made ModbusIOServers below.
States and Status
The Modbus I/O has the following states:
|Offline||Indicates broken communication with one or more nodes. Communication is still attempted, but as long as one or more nodes do not respond, the IOServer will be in Offline State.|
|Online||Indicates successful communication with all nodes.|
As can be seen from the table above, the Modbus I/O can be in Online or Offline state. In both states, Periodic packets are being sent at the configured frequency. When the Modbus I/O is Online, all packets are being sent/received successfully, and when the Modbus IO is Offline, responses from one or more nodes are not received.
The signals NumberOfNodes and NumberOfNodesOnline can be used to tell how many nodes are configured, and how many nodes are online.
Each packet also has an Online Property that is continously updated.
When the Modbus IO goes Offline, the Transmission Error alarm is set, indicating a failure. See CDPAlarm for more information on how to control Alarms.
Note: All this information can be used by other components in the system, to enable or disable system functionality. The relevant information can be Routed, or queried through a CDPConnector or CDPPort.
The Transport must be configured to tell the IOServer how to send and receive the data. The available transports are:
The Transport has a configurable Timeout (in seconds, f.i. '0.5'). This is the allowed amount of time to pass from a packet being sent until an answer is received. If no answer is received within the Timeout, the IOServer enters Offline state.
Periodic packets are sent at the configured frequency (CDPComponent fs).
The different transports handle Timeouts in their own way:
|TCP||After sending a request, wait Timeout seconds for a response. If no response within Timeout, enter Offline state.|
|UDP / Serial||Send (Periodic) packets each Period, even if no answer within a period. If no response within Timeout, enter Offline state.|
Note: In the event that no response is received within a Process Period, UDP and Serial will refresh the packet data and send the packet again, while TCP will resend the last packet without refreshing its data.
Some pre-made ModbusIOServers are provided. These are pre-set up for communicating with the device, and to function correctly, they usually only need modules (that match physical configuration) added to them. See the models for the Weidmüller-UR20-FBC-MOD for an example of this.
Generic Modbus Configuration
The Modbus I/O Servers send the requests to Slaves (numbered nodes) in the form of Modbus Packets.
First, select a suitable Modbus I/O server to use (see table above), either master or slave, TCP, UDP or RTU. Choose one of the pre-configured I/O servers if available for your target node; it simplifies the setup. Then set it up:
- The fs property determines the Send-rate for a modbus master.
- The transport layer configuration must be set up in the Transport table. This can be either UDP, TCP or Serial. Take care to set a sensible Timeout as explained above.
- Packet(s) must be added into the Packets table and configured. See the table below for configuration options.
- Modules must be added to a packet to determine what data to read or write. A module is a logical grouping of CDPSignalChannels that encapsulates data to send or receive.
If there is no pre-configured I/O server available for your Node, the following properties must also be set:
- Set DigitalModuleHandling, see table below for more information.
- Set DigitalRegistersAreLinear, see table below for more information.
- Set ModuleOrdering, it is typically set to AsConfigured, see table below.
- Set NetworkConvert according to the node specification.
A Modbus Slave packet has the following properties:
|SlaveID||The unique Modbus Slave identifier|
|ReadAddress||The address that the first input channel uses. The following input channels get their data from the following addresses.|
|WriteAddress||The address that the first output channel uses. The following output channels write their data to the following addresses.|
|FunctionCode||How to transmit the data in the packet: If the data is read only, use ReadHoldingRegisters. Channels in the packet must have Input="0". If the data is write only, use WriteMultipleRegisters. Channels in the packet must have Input="1". If the data is read and write, use ReadWriteMultipleRegisters. Channels that have Input="0" will receive the 'Read' part, and Channels that have Input="1" will be sent to the connected node.|
|DigitalRegistersAreLinear||When this is 1, the digital registers are transfered 'Most Significant Byte' first. This is typically set for devices where digital channels are linear, but the analog channels are byteswapped (In other words; NetworkConvert is 1, but not for digital content registers). If DigitalRegistersAreLinear is set to 0, then the NetworkConvert property decides how to transfer the bytes in the Packet.|
|DigitalModuleHandling||Sets how to handle digital channels in memory.|
|ModuleOrdering||Sets how to handle module ordering organization in memory.|
|Name||Unique packet name|
|NetworkConvert||When checked, data will byteswapped (this can also be controlled on a per-channel level).|
|Online||When packet data is being communicated correctly, then the packet is Online (1). If not, it is Offline(0).|
A Modbus Master packet has the following additional properties:
|SendMode||How to send the data:|
Modules in Packets
A Modbus packet in CDP Studio contains one or more modules. Modules are named groupings of channels, and typically used to reflect a physical I/O module. Many hardware-manufacturers have stackable modules that can be put on their 'buscouplers' 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:
|Name||The name of the module|
|InputBytesReservedBefore||The number of bytes to reserve before the actual input data in this module. Set this to the number of 'gap' bytes in front of the input data in this module (Typically set to 0).|
|OutputBytesReservedBefore||The number of bytes to reserve before the actual output data in this module. Set this to the number of 'gap' bytes in front of the output data in this module (Typically set to 0).|
|InputBytesReservedAfter||The number of bytes to reserve after the actual input data in this module. Set this to the number of 'gap' bytes after the input data in this module (Typically set to 0).|
|OutputBytesReservedAfter||The number of bytes to reserve after the actual output data in this module. Set this to the number of 'gap' bytes after of the output data in this module (Typically set to 0).|
Channels in Modules
Depending on the FunctionCode used, a Modbus Master writes channels that have Input="1", and it reads channels that have Input="0". A Modbus slave handles write requests into channels that have Input="0", and it handles read requests from channels that have Input="1". This means that for a Modbus Slave to mirror a Modbus Master, then the setup of the Modbus Master and Modbus Slave is equal for the Packet setup (For instance, the Modbus Slave has the same FunctionCode as the Modbus Master). Note that the channels differ, in that the Input attribute on the Modbus Master and Modbus Slave is inverted (A Modbus Slave has Input="1" and a Modbus Master has Input="0" for the corresponding channel).
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.
The Modbus standard does not specify how to transfer data larger than 16. This poses a challenge when working on data- types larger than 16 bits, as the byte-sequence of that data is not defined. The CDP Automation add-on defines a ByteSwap operator which can be used to manipulate the byte order of a signal.
In Modbus, float and double datatypes require a ByteSwap operator on that signal to be converted corrrectly, depending on the NetworkConvert setting. For instance, the byte-sequence of float data '0123', where 0,1,2 and 3 represent bytes in the float, could be converted to '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 see what is received. Type the received value into the 'float to hex' converter. By looking at 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, your program code is 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 inbetween scale linearily between -32768 and 32767.
We can add a ScalingOperator 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.
Some Modbus nodes have a watchdog function. A watchdog is typically a counter that counts down at a determined time-interval. If the watchdog is allowed to reach 0, the physical outputs of the node are set to a pre-defined value (typically 0, or last value). Whenever a modbus access is performed, the watchdog is reloaded, preventing a timeout. This mechanism can help ensure that when communication to the physical equipment is lost, the equipment stops safely. Note that the component fs property must be set high enough so that the watchdog does not time out.
Value Change on Error
When a node goes to Offline state, the default behavior is to keep the last value for all physical input channels. To make all the physical input values go to 0 when the node goes to Offline state, see Safe Value CDPSignals.
Modbus TCP Master / Slave Demo
Modbus TCP Master / Slave Demo - Describes how to run and configure a ModbusMaster and slave TCP Demo