Communications Modbus Functionality

Master/Client Function Code and Data Type Support

The following table lists the Modbus data type, the function code and the CPU source data type that is supported when the CPU is the Client or Master on a Modbus TCP or serial connection.

Modbus Client/Master Support (Using MRX and MWX Instructions)
Function Code	Function Name	Modbus 984 Addressing (Zero Based)	Modbus 984 Addressing	Productivity Suite Tag Types (Data designation or source)
01	Read Coil Status	000000 - 065535	000001 - 065536	Discrete Output (DO)
				Boolean (C )
				Boolean System (SBRW)
02	Read Coil Status	100000 - 165535	100001 - 165536	Discrete Input(DI)
				Boolean (C )
				Boolean System (SBRW)
03	Read Holding Registers	400000 - 465535	400001 - 465536	Integer 8 bit Unsigned (U8)
				Integer 16 bit (S16)
				Integer 16 bit Unsigned (U16)
				Integer 16 bit BCD (B16)
				Integer 32 bit (S32)
				Integer 32 bit BCD (B32)
				Integer 32 bit Float (F32)
				Integer 16 bit System (SWRW)
04	Read Input Registers	300000 - 365535	300001 -365536	Integer 8 bit Unsigned (U8)
				Integer 16 bit (S16)
				Integer 16 bit Unsigned (U16)
				Integer 16 bit BCD (B16)
				Integer 32 bit (S32)
				Integer 32 bit BCD (B32)
				Integer 32 bit Float (F32)
				Integer 16 bit System (SWRW)
05	Write Single Coil	000000 - 065535	000001 - 065536	Discrete Input (DI)
				Discrete Output (DO)
				Boolean (C )
				Boolean System (SBRW)
				Boolean System Read Only (SBR)
06	Write Single Register	400000 - 465535	400001 - 465536	Integer 8 bit Unsigned (U8)
				Integer 16 bit (S16)
				Integer 16 bit Unsigned (U16)
				Integer 16 bit BCD (B16)
				Integer 32 bit (S32)
				Integer 32 bit BCD (B32)
				Integer 32 bit Float (F32)
				Integer 16 bit System (SWRW)
				Integer 16 bit System Read Only (SWR)
15	Write Multiple Coils	000000 - 065535	000001 - 065536	Discrete Input (DI)
				Discrete Output (DO)
				Boolean (C )
				Boolean System (SBRW)
				Boolean System Read Only (SBR)

Modbus Client/Master Support (Using MRX and MWX Instructions) Continued
Function Code	Function Name	Modbus 984 Addressing (Zero Based)	Modbus 984 Addressing	Productivity Suite Tag Types (Data designation or source)
16	Write Multiple Registers	400000 - 465535	400001 - 465536	Integer 8 bit Unsigned (U8)
				Integer 16 bit (S16)
				Integer 16 bit Unsigned (U16)
				Integer 16 bit BCD (B16)
				Integer 32 bit (S32)
				Integer 32 bit BCD (B32)
				Integer 32 bit Float (F32)
				Integer 16 bit System (SWRW)
				Integer 16 bit System Read Only (SWR)

Slave/Server Function Code and Data Type Support

The following table lists the Modbus data type, the function code and the CPU source data type that is supported when the CPU is the Server or Slave on a Modbus TCP or serial connection.

Modbus Server/Slave Support
Function Code	Function Name	Modbus 984 Addressing	Productivity Suite Tag Types
01	Read Coil Status	000001 - 065536	Discrete Output (DO)
			Boolean (C )
			Boolean System (SBRW)
02	Read Coil Status	100001 - 165536	Discrete Input (DI)
			Boolean System Read Only (SBR)
03	Read Holding Registers	400001 - 465536	Integer 8 bit Unsigned (U8)
			Integer 16 bit (S16)
			Integer 16 bit Unsigned (U16)
			Integer 16 bit BCD (B16)
			Integer 32 bit (S32)
			Integer 32 bit BCD (B32)
			Integer 32 bit Float (F32)
			Integer 16 bit System (SWRW)
			String
04	Read Input Registers	300001 -365536	Analog Input, Integer 32 bit (AIS32)
			Analog Input, Float 32 bit (AIF32)
			Integer 16 bit System Read Only (SWR)
05	Write Single Coil	000001 - 065536	Discrete Output (DO)
			Boolean (C )
			Boolean System (SBRW)
06	Write Single Register	400001 - 465536	Integer 8 bit Unsigned (U8)
			Integer 16 bit (S16)
			Integer 16 bit Unsigned (U16)
			Integer 16 bit BCD (B16)
			Integer 32 bit (S32)
			Integer 32 bit BCD (B32)
			Integer 32 bit Float (F32)
			Integer 16 bit System (SWRW)
			Integer 16 bit System Read Only (SWR)
			String
15	Write Multiple Coils	000001 - 065536	Discrete Output (DO)
			Boolean (C )
			Boolean System (SBRW)

Modbus Server/Slave Support (Continued)
Function Code	Function Name	Modbus 984 Addressing	Productivity Suite Tag Types
16	Write Multiple Registers	400001 - 465536	Integer 8 bit Unsigned (U8)
			Integer 16 bit (S16)
			Integer 16 bit Unsigned (U16)
			Integer 16 bit BCD (B16)
			Integer 32 bit (S32)
			Integer 32 bit BCD (B32)
			Integer 32 bit Float (F32)
			Integer 16 bit System (SWRW)
			Integer 16 bit System Read Only (SWR)
			String

Assigning Modbus Addresses to Tags

There are many different data types in the CPU. Because of this, the Modbus addresses need to be mapped to the various tag data types in the CPU.

There are two ways to map Modbus addresses to Tags in the Programming software:

Modbus mapping in Tag Database window.

Modbus mapping when creating Tags.

Modbus mapping in Tag Database window:

There are only two data sizes in the Modbus protocol: bits and words. In the CPU, there are multiple size types, so it is sometimes necessary to map multiple Modbus addresses to a single Tag entity. There are also array data structures in the CPU. When Modbus addresses are mapped to arrays, they will be mapped as a contiguous block of addresses. This is, in fact, the most efficient method to handle Modbus communications.

In the Tag Database window, there are two columns named ModStart and Mod End. To map a Modbus address to a tag in the Tag Database window, simply double-click in the ModStart field for the Tag.

When you do this, you will see two values appear in the field. The left most value is the Modbus data type. This is fixed based upon the tag data type. The chart below indicates the four different Modbus data types in the 984 addressing scheme.

Address Identifier	Modbus 984 Address Type
0xxxxx	Coil (Read/Write bit)
1xxxxx	Input (Read Only bit)
3xxxxx	Input Register (Read Only 16 bit word)
4xxxxx	Holding Register (Read/Write 16 bit word)

The right most value that you see in the ModStart field is the address offset (range is from 1 - 65535). You can accept the value that is pre-filled for you or the value can be changed. The software automatically pre-fills the address offset with the next available address.

Modbus mapping when creating Tags:

Modbus addresses can be assigned to Tags as they are created in the Tag Database.

Type in the Modbus offset value when entering the Tag Name and Data Type. If the address is already assigned, a warning message will appear.

Modbus Options

The Modbus protocol does not have a specific method outlined for data types outside of bits and 16-bit words. Most systems now have 32-bit data types. In order to transport 32-bit data types across Modbus, they must be placed into two Modbus 16-bit registers. Unfortunately, some devices do not support this and there are sometimes incompatibilities in the order of the 16-bit high word and low word handling between the devices.

In order to help alleviate this situation, there are some options for handling this in the programming software. To find the Modbus Address options, go to File and click on Project Properties and then click on the Modbus Server Settings tab.

No exception response for non-existing Modbus address requests: Because the Modbus addresses can be manually assigned to tags, it is possible that gaps can occur in the Modbus address mapping. For example: Tag1 has Modbus address 400001 assigned to it and Tag 2 has Modbus address 400003 assigned to it.

Most Modbus Master/Client devices will attempt to optimize their data requests to a Modbus Slave/Server device by requesting blocks of data instead of individual registers. In the case above, most Modbus masters would send one read request starting at 400001 and a size of three instead of sending two read requests starting at 400001 with size one and 400003 with size one as shown below.

In the example shown above on left, a Modbus Slave/Server device should give an exception response since there is no Modbus Address of 400002 in the device. This method can causes a lot of inefficiencies. By selecting the No exception response for non-existing Modbus address requests option, the CPU will not give an exception response to the request. Note that if Modbus address 400002 by itself were requested it would give an exception response.

Word swap option (S-32, AIS-32, AOS-32, F-32, FI-32, FO-32):

Word swap allows the word order of 32-bit tags to be changed when sending the values across Modbus. The default selection is on, which returns the data low word first.

Map value to a single 16 bit Modbus register:

This option allows for compatibility with devices that do not support 32-bit Modbus functionality. This option can be selected individually for the Analog Input and Output Signed 32 data types and the Internal Signed 32 data types, including the array form of these data types. This function is only useful when the value contained in a 32-bit tag does not exceed a signed 15-bit value (32,765).

Tag1 (Integer, 32-Bit) = 22136 (hex = 0x00005678)

With "Map Value to a single 16-Bit register" turned OFF =

Tag1 Modbus address = 400001, 400002

Modbus reply for Tag1 (Word Swap ON) = 01 03 04 56 78 00 00

With "Map Value to a single 16-Bit register" turned ON =

Tag 1 Modbus address = 400001

Modbus reply for Tag1 = 01 03 02 56 78

Map value to two consecutive 16-bit Modbus registers: Allows for 32-bit data types to be mapped to two consecutive 16-bit registers. This option is selected as default.

All of the options in the Modbus Address tab of the Project Properties only apply to the Modbus Slave/Server functionality. Similar options are available for the Modbus Master/Client functions as well and are available in the MRX and MWX Modbus instructions.

Modbus Instructions

To read or set data in other Modbus Slave/Server devices, there are two instructions available in the programming software, Modbus Read and Modbus Write.

The Modbus Read (MRX) instruction is used to read data from other Modbus devices into Tags of the CPU.

The MRX instruction can be used for Modbus TCP or Modbus RTU. There are several status bits that can be used to determine whether the read message was successful and if it was not, the reason why.

There is an Automatic Polling feature in the instruction to make it easier to read a device on a pre-determined poll rate. There is also a poll offset field that can be used when simultaneous instructions are enabled with the Automatic Polling feature to help stagger the flow of messages being sent to the network.

The Modbus Write (MWX) instruction is very similar in layout and configuration to the MRX instruction. It is used to write values to a Modbus device from the tags in the CPU.

The MWX operates very similarly to the MRX instruction. There are also many status bits to indicate the success or reason of failure when sending a message.

The Automatic Polling option is also available to the MWX instruction, although greater care should be taken when using this feature in this instruction. This is explained in better detail in the Message Queue section.

Network Instructions

The Network Read (RX) and Network Write (WX) instructions are used to communicate to other CPUs. They are very similar in operation to the MRX and MWX instructions but they target Tag Names instead of Modbus addresses in the other CPU. There is also a significant performance gain in using the RX and WX instructions when communicating to other CPUs as opposed to using the MRX and MWX instructions.

The same status bits are available in the RX instruction as in the MRX instruction and operate in the same manner. The greatest difference in the RX versus the MRX is that with the RX, the Tag Name in the target CPU can be referenced directly and does not need a corresponding Modbus address. The way this is accomplished is by mapping local and remote tagnames together within the local CPU's RX instruction. Once the instruction is set up to read a remote project, the Tags of Remote Project or Array Tags of Remote Project drop down lists will be accessible. Map the Tag of the Remote project to a Tag in the Local project to read this data.

The WX instruction operates in the same manner except that the data from the Local tags will be written into the Tags of the remote project. No Modbus mapping is required.

Note: The PC programming software project for the Remote CPU must be accessible by the PC running the programming software for the Local project.

Automatic Poll versus Manual Polling and Interlocking

In many cases when performing multiple communications requests to other devices, the message flow must be explicitly controlled in ladder code so that a message is not sent while another one is in operation. This usually requires writing interlocking code between the instructions which typically involves the use of timers and shift registers, etc. Sometimes this is necessary because of the application but in other cases where the CPU just wants to read changing values from other devices and the frequency of that update is not critical it would be much more efficient to skip the unnecessary code complexity of interlocking.

The desire to make it easier to communicate to other devices brought about the Automatic Polling feature and the Message Queue in the CPU. The Automatic Polling feature allows the user to choose the rate at which they desire to send messages without having to use a separate timer and enable logic. The Message Queue allows the user to stage the messages from the ladder code to go out to each physical communications port without requiring interlocking logic.

The implementation of how the message queue works is slightly different based on whether the request is a read request or a write request.

Write requests will fill the queue much faster than read requests. That's why it is advisable to carefully choose when doing write requests whether to use the Automatic Poll feature or to manually send write requests only when needed (data to write has changed). When designing a system, it is important to know the total time it takes to send a request and get a reply for each target device. The Poll time should be longer than this time. The longer the poll time can be, within tolerance of the application, the better the overall network performance. So, for efficiency in programming and for the best possible performance for the system, conservative poll rates should be used when utilizing the Automatic Poll feature.

There is also a Poll offset field in the communications instructions. This helps prevent the instructions from being queued all at the same time. When the CPU project starts, there is a master timer that begins. The ladder scan will look to see if the instruction is enabled. If it is enabled, it will begin the Automatic Poll timer at the specified poll offset value from the master time clock.

Message Queue

If the application requires more explicit, orderly control of each message sent to the devices, turn off the Automatic Poll feature. Using the instruction's status bits, logically control each message as required.

All of the above explains how messages get into the queue. There are several factors involved with how each queue (1 for each physical port) is emptied.

Serial port queues: The serial port queues empty slower than the Ethernet port queues, not just because of the hardware speed itself but because of the nature of serial communications. Each request sent must wait for a response or a timeout (whichever comes first). Once the reply is received for a request or a timeout has occurred, the next item in the list can be sent. So, the response time of the slave devices on the network will largely affect the speed at which the queue fills and empties.
Ethernet port queues: The Ethernet port queue can empty faster because when sending requests to multiple devices, the CPU does not have to wait on a response from one device before sending a request to another device due to the inherent nature of the Ethernet hardware. However, sending multiple requests to the same Ethernet device does necessitate that the CPU waits for a response from the first request before sending another request to that same device.

Another difference in the Ethernet port queue versus the Serial port queue spawns from the TCP 'connection' based behavior of Modbus TCP. If a TCP connection is lost to a device and there are still requests in the queue for that device, those requests will be dropped from the queue. There are three ways this can happen:

If a TCP timeout occurs (server device fails to respond within specified timeout value), the TCP connection is lost.
If the server device closes the connection, then all of the requests will be dropped.
And, finally, if all rungs with communications instructions to a device are disabled for five seconds, the CPU will drop the TCP connection for that device in order to free up valuable resources that could be used elsewhere in the system.

There is another factor that should be considered when designing the system. If it is imperative that no message be lost when communicating to a device, each instruction should be explicitly handled one by one (interlocking logic).

Note: Another side effect of the queueing mechanism is that the instruction status bits may not be seen in the ladder. When an instruction has completed (Success, Exception Response, or Timeout), the CPU firmware will set the appropriate status bits. At the point that the CPU firmware pulls another message off the queue, it will reset the status bits of that instruction. The timing can work out in such a way that the status bits get set but the CPU firmware pulls off the instruction that contains those same status bits and resets them to start another iteration before the ladder code examines those bits.
Two things can be done to ensure reliable detection of status bits:
1. Do not use Automatic Poll and use interlocking logic to detect status completion of an instruction before enabling that instruction again. This is the most reliable method.
2. Ensure that the Automatic Poll time is long enough to prevent queuing of that same instruction.

Modbus Ethernet Throughput

(messages per second)

To determine the total number of Modbus messages that can be sent per second (Ethernet throughput), use the following calculation:

Example:

Number of Modbus Masters/Slaves = 8

'Peak Scan Interval' System Tag = 10 msec.

8 x 10 msec. (100 scans)= 800 messages per second

Note: The number and size of the tags used in a specific Modbus message will increase the scan time thus affecting the overall throughput.