|
|
Topic: P198 |
Communications Modbus Functionality |
|
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) |
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 |
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.
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.
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.
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.
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 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.
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
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.
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 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 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.
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.
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.
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.
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:
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.
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.