Content Type Support Article

Article # 000023337

Title Understanding Modbus Send and Receive Response Logging for Diagnostics

Legacy DocId TN1038

Confidence Expert Reviewed

Published On 3/11/2016

Understanding Modbus Send and Receive Response Logging for Diagnostics

PROBLEM

Title

Understanding Modbus Send and Receive Response Logging for Diagnostics

SOLUTION

Summary

This Tech Note outlines how to interpret the DASSend and DASReceive logging that is available for Wonderware Modbus Ethernet DAServer
(DASMBTCP). You can view the message contents in the Wonderware System Management Console log for troubleshooting purposes.

Situation

Application Versions

Wonderware Modbus Ethernet DAServer (DASMBTCP) v2.0

Modbus Protocol Specifications

Every interaction between DASMBTCP and the PLC via Ethernet requires a request to be sent and a response to be received. The structure of the
data in this interaction is predefined within the Modbus Protocol Specifications.

First, the server needs to send a request to the client (PLC). This message to the client is in hexadecimal and contains several parts, a header, slave
identification, actions requested, registers to interact with, and checksums, etc.

Read Messages

The Send message for a register read is constructed as follows:

Transaction ID – 2 bytes – This is a unique identifier for the transaction. This is key info, especially when the Maximum Outstanding Messages
option is set higher than 1 and the device supports concurrent messages. This ID is used by the server to match the sent requests with the
received data.
Protocol ID – 2 bytes – 0 indicates Modbus protocol.
Length of data to follow – 2 bytes – How many bytes are contained in the remainder of the sent message. (Checksum)
PLC Unit ID – 1 byte – Used to direct the message to a slave device in a bridge configuration. Non-bridge Modbus configurations assume slave
ID 255. This ID will be returned in the response to link the sent requests and received data.
Modbus Function Code – 1 byte – What Modbus function to execute against the tags in this message

Code Name Description

01
Read Coils Reads the ON/OFF status of discrete outputs (0X references, coils) in the slave.
(0x01)
02
Read Discrete Inputs Reads the ON/OFF status of discrete inputs (1XXXXX references) in the slave.
(0x02)
03 Read Holding
Reads the binary contents of holding registers (4XXXXX references) in the slave.
(0x03) Registers

Terms of Use| Privacy Policy

© 2016 AVEVA Group plc and its subsidiaries.All rights reserved.
04
Read Input Registers Reads the binary contents of input registers (3XXXXX references) in the slave.
(0x04)
05
Write Single Coil Forces a single coil (0X reference) to either ON or OFF.
(0x05)
06 Write Single
Presets a value into a single holding register (4XXXXX reference).
(0x06) Register
15
Write Multiple Coils Forces each coil (0XXXXX reference) in a sequence of coils to either ON or OFF.
(0x0F)
16 Write Multiple
Presets values into a sequence of holding registers (4XXXXX references).
(0x10) Registers
20 Read General
Returns the contents of registers in the Extended Memory file (6XXXXX) references.
(0x14) Reference
21 Write General
Writes the contents of registers in the Extended Memory file (6XXXXX) references.
(0x15) Reference
Modifies the contents of a specified (4XXXXX reference) holding register using a combination of an AND mask, an OR
22 Mask Write Holding
mask, and the register's current contents.
(0x16) Register
The function can be used to set or clear individual bits in the register.

Starting address – 2 bytes – Address of the first register to read. (0-based)

Number of registers to read – 2 bytes – How many contiguous registers, including the starting register, will be read. This is where the
efficiencies of reading contiguous registers can be realized because individual registers don’t need to be requested, therefore reducing
messaging overhead.

The Receive message for a register read is constructed as follows:

Transaction ID – 2 bytes – This is a unique identifier for the transaction. This is key info, especially when the Maximum Outstanding Messages
option is set higher than 1 and the device supports concurrent messages. This ID is used by the server to match the sent requests with the
received data.
Protocol ID – 2 bytes – 0 indicates Modbus protocol.
Length of data to follow – 2 bytes – How many bytes are contained in the remainder of the receive message. (Checksum)
PLC Unit ID – 1 byte – Used to indicate the slave device which sent this data in a bridge configuration. This is used to link the sent requests and
received data.
Modbus Function Code – 1 byte – If the sent function executed successfully, the original code is returned, otherwise an exception code is
returned with details. (See the Exception Code Section of this document)
Length of data to follow – 1 byte – How many bytes are contained in the remainder of the receive message. (Checksum)
Values read – 2 bytes per register – The values contained in the registers that were requested in the sent message.

Write Messages

The Send message for a register write is constructed as follows:

Transaction ID – 2 bytes – This is a unique identifier for the transaction. This is key info, especially when the Maximum Outstanding Messages
option is set higher than 1 and the device supports concurrent messages. This ID is used by the server to match the sent requests with the
received data.
Protocol ID – 2 bytes – 0 indicates Modbus protocol.
Length of data to follow – 2 bytes – How many bytes are contained in the remainder of the sent message. (Checksum)
PLC Unit ID – 1 byte – Used to direct the poke message to a slave device in a bridge configuration. Non-bridge Modbus configurations assume
slave ID 255. This ID will be returned in the response to link the sent requests and received data.
Modbus Function Code – 1 byte – What Modbus function to execute against the tags in this message.

Code Name Description

01
Read Coils Reads the ON/OFF status of discrete outputs (0X references, coils) in the slave.
(0x01)
02
Read Discrete Inputs Reads the ON/OFF status of discrete inputs (1XXXXX references) in the slave.
(0x02)
03 Read Holding
Reads the binary contents of holding registers (4XXXXX references) in the slave.
(0x03) Registers
04
Read Input Registers Reads the binary contents of input registers (3XXXXX references) in the slave.
(0x04)
05
Write Single Coil Forces a single coil (0X reference) to either ON or OFF.
(0x05)
06 Write Single
Presets a value into a single holding register (4XXXXX reference).
(0x06) Register

Terms of Use| Privacy Policy

© 2016 AVEVA Group plc and its subsidiaries.All rights reserved.
15
Write Multiple Coils Forces each coil (0XXXXX reference) in a sequence of coils to either ON or OFF.
(0x0F)
16 Write Multiple
Presets values into a sequence of holding registers (4XXXXX references).
(0x10) Registers
20 Read General
Returns the contents of registers in the Extended Memory file (6XXXXX) references.
(0x14) Reference
21 Write General
Writes the contents of registers in the Extended Memory file (6XXXXX) references.
(0x15) Reference
Modifies the contents of a specified (4XXXXX reference) holding register using a combination of an AND mask, an OR
22 Mask Write Holding
mask, and the register's current contents.
(0x16) Register
The function can be used to set or clear individual bits in the register.

Starting address to poke – 2 bytes – Address of the first register to interact with. (0-based)
Number of registers to poke – 2 bytes – How many contiguous registers, including the starting register, will be poked.
Length of data to follow – 1 byte – How many bytes are contained in the remainder of the poke message. (Checksum)
Values poked – 2 bytes per register - The values poked to the registers that were indicated in the sent message.

The Receive message for a register write is constructed as follows:

Transaction ID – 2 bytes – This is a unique identifier for the transaction. This is key info, especially when the Maximum Outstanding Messages
option is set higher than 1 and the device supports concurrent messages. This ID is used by the server to match the sent requests with the
received data.
Protocol ID – 2 bytes – 0 indicates Modbus protocol.
Length of data to follow – 2 bytes – How many bytes are contained in the remainder of the receive message. (Checksum)
PLC Unit ID – 1 byte – Used to indicate the slave device which sent this data in a bridge configuration. This is used to link the sent requests and
received data.
Modbus Function Code – 1 byte – If the sent function executed successfully, the original code is returned, otherwise an exception code is
returned with details. (See exception code section of this document)
Starting address poked – 2 bytes – Address of the first register that was poked. (0-based)
Number of registers poked – 2 bytes – How many contiguous registers, including the starting register, were poked.

Enabling Modbus Protocol Logging

Once DASMBTCP is installed, you can enable optional log flags in order to observe the DAServer to PLC communications using the Modbus Protocol.

To enable Modbus Protocol Logging

1. Open the System Management Console and expand Log Viewer > Default Group > Local (Figure 1 below).

Figure 1: Locate and Open Log Viewer > Default Group > Local
2. Right-click Local and click Log Flags (Figure 2 below).

Terms of Use| Privacy Policy

© 2016 AVEVA Group plc and its subsidiaries.All rights reserved.
 Figure 2: Open Log Flags window
3. Select DASMBTCP in the left panel and then enable DASReceive, DASSend, and DASVerbose in the Log Flags for DASMBTCP panel
(Figure 3 below).

Figure 3: Enable DASMBTCP Log Flags

4. Close the Log Flags window and click Yes to apply the changes.

Note: Once your analysis is complete, disable these flags since they will log a large amount of data.

Analyzing the Log Messages

This Tech Note uses the wwclient Utility and a Modbus simulator to read five tags with static values (Figure 4 below).

Terms of Use| Privacy Policy

© 2016 AVEVA Group plc and its subsidiaries.All rights reserved.
 Figure 4: Example Configuration

Successful Read Messages

Now that the logs flags are enabled, you can see what is recorded in the log while reading the data (Figure 5 below).

Figure 5: DASMBTCP Register Read Log Sample

The Hex characters you see in the log messages represent the Modbus Protocol communications.

First, you can analyze the message sent from DASMBTCP to the PLC.

Message sent to PLC PORT.New_ModbusPLC_000 (9 6f 0 0 0 6 ff 3 0 0 0 5 )

Hex
Description Value
Character
9 6f Transaction ID 096F hex = 2415 decimal
00 Protocol ID 0000 = Modbus protocol
Length of data to follow (byte
06 0006 = 6 bytes to follow
count)
ff PLC Unit ID FF = 255 decimal (255 is the unit ID for this device)
3 Modbus Function Code 03 = read holding register
00 Starting address (0-based) 0000 = address 0 which is addressed as 40001 in this case
0005 = read five registers beginning at the starting address (40001
05 Number of registers to read
through 40005)

Then you can analyze the response from the PLC back to the DAServer.

Message received from PLC PORT.New_ModbusPLC_000 (9 6f 0 0 0 d ff 3 a 0 1 8 ae d 5 11 5c 15 b3 )

Terms of Use| Privacy Policy

© 2016 AVEVA Group plc and its subsidiaries.All rights reserved.
Hex
Description Value
Character
9 6f Transaction ID 096F hex = 2415 decimal
00 Protocol ID 0000 = Modbus protocol
0d Length of data to follow (byte count) 000D = 13 bytes to follow
ff PLC Unit ID FF = 255 decimal (255 is the unit ID for this device)
03 = read holding register
3 Modbus Function Code (If function is successful, the same code is returned as
requested)
Length of values to follow (byte
a 0A = 10 bytes with values to follow
count)
01 Value for first tag 0001 = 1 decimal
8 ae Value for second tag 08AE = 2222 decimal
d5 Value for third tag 0D05 = 3333 decimal
11 5c Value for fourth tag 115C = 4444 decimal
15 b3 Value for fifth tag 15B3 = 5555 decimal

Successful Write Messages

A value of 2 was poked to register 40001. The following data appears in the log (Figure 6 below).

Figure 6: DASMBTCP Register Write Log Sample

First, you can analyze the poke message sent from DASMBTCP to the PLC:

Message sent to PLC PORT.New_ModbusPLC_000 (29 d8 0 0 0 9 ff 10 0 0 0 1 2 0 2 )

Hex Character Description Value

29 d8 Transaction ID 096F hex = 2415 decimal
00 Protocol ID 0000 = Modbus protocol
09 Length of data to follow (byte count) 0009 = 9 bytes to follow
ff PLC Unit ID FF = 255 decimal (255 is the unit ID for this device)
10 Modbus Function Code 10 = 16 (decimal) write single holding register
00 Address to be poked 0000 = Address 0, register 40001
01 Number of registers to write 0001 = one register to poke
2 Length of values to follow (byte count) 02 = 2 bytes to follow
02 Value poked 0002 = Value of 2 (decimal) to be poked

Then you can analyze the response from the PLC back to the DAServer, confirming the write.

Message received from PLC PORT.New_ModbusPLC_000 (29 d8 0 0 0 6 ff 10 0 0 0 1 )

Hex Character Description Value

29 d8 Transaction ID 29D8 hex = 10712 decimal
00 Protocol ID 0000 = Modbus protocol
06 Length of data to follow (byte count) 0006 = 6 bytes to follow
ff PLC Unit ID FF = 255 decimal (255 is the unit ID for this device)
10 Modbus Function Code 10 = 16 (decimal) write single holding register
00 Starting address poked 0000 = Address 0, register 40001
01 Number of registers poked 01 = 1 register poked

Exception Code Messages

Exception code messages are received when the transaction fails. These messages are structured slightly differently, since an exception indicator and
reason must be included. In this example, all the registers are set to read-only. Then a poke was attempted using a value of 3 to holding register
400003 (Figure 7 below).

Terms of Use| Privacy Policy

© 2016 AVEVA Group plc and its subsidiaries.All rights reserved.
 Figure 7: DASMBTCP Register Write Exception Log Sample

First, you can analyze the poke message sent from DASMBTCP to the PLC.

Message sent to PLC PORT.New_ModbusPLC_000 (0 39 0 0 0 9 ff 10 0 2 0 1 2 0 3 )

Hex Character Description Value

0 39 Transaction ID 0039 hex = 57 decimal
00 Protocol ID 0000 = Modbus protocol
09 Length of data to follow (byte count) 0009 = 9 bytes to follow
ff PLC Unit ID FF = 255 decimal (255 is the unit ID for this device)
10 Modbus Function Code 10 = 16 (decimal) write single holding register
02 Address to be poked 0000 = Address 2, register 400003
01 Number of registers to write 0001 = one register to poke
2 Length of values to follow (byte count) 02 = 2 bytes to follow
03 Value poked 0003 = Value of 3 (decimal) to be poked

Then you can analyze the response from the PLC back to the DAServer, containing the exception information.

Message received from PLC PORT.New_ModbusPLC_000 (0 39 0 0 0 3 ff 90 1 )

Hex
Description Value
Character
0 39 Transaction ID 0039 hex = 57 decimal
00 Protocol ID 0000 = Modbus protocol
Length of data to follow (byte
03 0003 = 3 bytes to follow
count)
ff PLC Unit ID FF = 255 decimal (255 is the unit ID for this device)
Modbus Function/Exception 90 = 10+80 (hex) - Original sent function code 10 plus 80 to indicate
90
Code exception
01 = Exception code 01 (see chart below for exception codes that can
1 Exception code
be returned)

Exception
Code Name Explanation
(Hex)
The function code received in the query is not an allowable action for the slave. This may be because the function
code is only applicable to newer controllers, and was not implemented in the unit selected.
01 ILLEGAL FUNCTION
It could also indicate that the slave is in the wrong state to process a request of this type; for example, because it
is unconfigured and is being asked to return register values.
The data address received in the query is not an allowable address for the slave. More specifically, the
ILLEGAL DATA combination of reference number and transfer length is invalid.
02
ADDRESS For a controller with 100 registers, a request with offset 96 and length 4 would succeed, a request with offset 96
and length 5 will generate exception 02.
A value contained in the query data field is not an allowable value for the slave. This indicates a fault in the
structure of the remainder of a complex request, such as that the implied length is incorrect.
ILLEGAL DATA
03 It specifically does NOT mean that a data item submitted for storage in a register has a value outside the
VALUE
expectation of the application program, since the MODBUS protocol is unaware of the significance of any
particular value of any particular register.
Indicates that the request as framed would generate a response whose size exceeds the available MODBUS
ILLEGAL RESPONSE
04 data size.
LENGTH
Used only by functions generating a multi-part response, such as functions 20 and 21.
05 ACKNOWLEDGE Specialized use in conjunction with programming commands.
06 SLAVE DEVICE BUSY Specialized use in conjunction with programming commands.

Terms of Use| Privacy Policy

© 2016 AVEVA Group plc and its subsidiaries.All rights reserved.
 NEGATIVE
07 Specialized use in conjunction with programming commands.
ACKNOWLEDGE
MEMORY PARITY Specialized use in conjunction with function codes 20 and 21 to indicate that the extended file area failed to
08
ERROR pass a consistency check.
Specialized use in conjunction with gateways; it indicates that the gateway was unable to allocate a Modbus
GATEWAY PATH
0A Plus PATH to use to process the request.
UNAVAILABLE
It usually means that the gateway is misconfigured.
GATEWAY TARGET
Specialized use in conjunction with gateways; it indicates that no response was obtained from the target device.
0B DEVICE FAILED TO
It usually means that the device is not present on the network.
RESPOND

Terms of Use| Privacy Policy

© 2016 AVEVA Group plc and its subsidiaries.All rights reserved.