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 quickguide
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, FunctionCode ReadWriteMultipleRegisters can be used. Use ReadHoldingRegisters (for only physical inputs) or use WriteMultipleRegisters for only physical outputs.
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 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|
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. 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.
- Packet(s) must be added into the Packets table and configured. See the table below for configuration options.
- Set DigitalModuleHandling, see table below for more information.
- Set ModuleOrdering , it is typically set to 'AsConfigured', see table below.
- 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.
A Modbus Slave packet has the following properties:
|SlaveID||The Slave identifier to communicate with|
|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 MSB first. This is typically set for devices where digital channels are linear, but the analog channels are byteswapped (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.|
|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 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, but 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, then next is bit 1 and so on, but bitpacking per module is done according to configuration of DigitalModuleHandling. Digital channels from different modules are put together according to 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 data require a ByteSwap operator on that signal to be converted corrrectly. For instance, the byte-sequence of float data '0123' (where 0,1,2 and 3 are bytes in the float) could be converted to '2301'. As there are many 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. 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, and that 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 1 to 32767:
The above scaling-operator scales an input of -1 to -32768 , 0 is 0 and 1 is scaled to 32767. Note that CDP will linearily scale values between the scaling points, so an InValue of -0.5 in the above example would generate an OutValue of -16384.
Note that any number of scaling-points can be added to a ScalingOperator. This may help eliminate dead-zones or similar.
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.
Modbus TCP Master / Slave Demo
Modbus TCP Master / Slave Demo - Describes how to run and configure a ModbusMaster and slave TCP Demo