Chapter 3
Diagnostic Subfunctions
V 
Modbus Function 08-Diagnostics
V Diagnostic Codes Supported by Controllers
V Return Query Data
V Restart Communications Option
V Return Diagnostic Register
V Change ASCII Input Delimiter
V Force Listen Only Mode
V Clear Counters and Diagnostic Register
V Return Bus Message Count
V Return Bus Communication Error Count
V Return Bus Exception Error Count
V Return Slave Message Count
V Return Slave No Response Count
V Return Slave NAK Count
V Return Slave Busy Count
V Return Bus Character Overrun Count
V Return IOP Overrun Count (884)
V Clear Overrun Counter and Flag (884)
V Get / Clear Modbus Plus Statistics
V Modbus Plus Network Statistics
3.1 Function 08-Diagnostics
Modbus function 08 provides a series of tests for checking the
communication system between the master and slave, or for
checking various internal error conditions within the slave.
Broadcast is not supported.
The function uses a two-byte subfunction code field in the query to
define the type of test to be performed. The slave echoes both the
function code and subfunction code in a normal response.
Most of the diagnostic queries use a two-byte data field to send
diagnostic data or control information to the slave. Some of the
diagnostics cause data to be returned from the slave in the data
field of a normal response.
Diagnostic Effects on the Slave
In general, issuing a diagnostic function to a slave device does not
affect the running of the user program in the slave. User logic,
like discretes and registers, is not accessed by the diagnostics.
Certain functions can optionally reset error counters in the slave.
A slave device can, however, be forced into `Listen Only Mode' in
which it will monitor the messages on the communications system
but not respond to them. This can affect the outcome of your
application program it it depends upon any further exchange of
data with the slave device. Generally, the mode is forced to
remove a malfunctioning slave device from the communications
system.
How This Information is Organized in Your Guide
An example diagnostics query and response are shown on the
opposite page. These show the location of the function code,
subfunction code, and data field within the messages.
A list of subfunction codes supported by the controllers is shown
on the pages after the example response. Each subfunction code is
then listed with an example of the data field contents that would
apply for that diagnostic.
Query
Here is an example of a request to slave device 17 to Return
Query Data. This uses a subfunction code of zero (00 00 hex in the
two-byte field). The data to be returned is sent in the two-byte
data field (A5 37 hex).
Response
The normal response to the Return Query Data request is to
loopback the same data. The function code and subfunction code
are also echoed.
The data fields in responses to other kinds of queries could
contain error counts or other information requested by the
subfunction code.
3.2 Diagnostic Codes Supported by Controllers
Subfunction codes are listed in decimal; Y indicates that the
subfunction is supported, and N indicates that it is not supported.
3.2.1 00 Return Query Data
The data passed in the query data field is to be returned (looped
back) in the response. The entire response message should be
identical to the query.
3.2.2 01 Restart Communications Option
The slave's peripheral port is to be initialized and restarted, and
all of its communications event counters are to be cleared. If the
port is currently in Listen Only Mode, no response is returned.
This function is the only one that brings the port out of Listen
Only Mode. If the port is not currently in Listen Only Mode, a
normal response is returned. This occurs before the restart is
executed.
When the slave receives the query, it attempts a restart and
executes its power-up confidence tests. Successful completion of
the tests will bring the port online.
A query data field contents of FF 00 hex causes the port's
Communications Event Log to be cleared also. Contents of 00 00
leave the log as it was prior to the restart.
3.2.3 02 Return Diagnostic Register
The contents of the slave's 16-bit diagnostic register are returned
in the response.
3.2.4 How the Register Data is Organized
The assignment of diagnostic register bits for Modicon controllers
is listed below. In each register, bit 15 is the high-order bit. The
description is TRUE when the corresponding bit is set to logic 1.
3.2.5 03 Change ASCII Input Delimiter
The character CHAR passed in the query data field becomes the
end of message delimiter for future messages (replacing the
default LF character). This function is useful in cases where a
Line Feed is not wanted at the end of ASCII messages.
3.2.6 04 Force Listen Only Mode
Forces the addressed slave to its Listen Only Mode for Modbus
communications. This isolates it from the other devices on the
network, allowing them to continue communicating without
interruption from the addressed slave. No response is returned.
When the slave enters its Listen Only Mode, all active
communication controls are turned off. The Ready watchdog timer
is allowed to expire, locking the controls off. While in this mode,
any Modbus messages addressed to the slave or broadcast are
monitored, but no actions will be taken and no responses will be
sent.
The only function that will be processed after the mode is entered
will be the Restart Communications Option function (function
code 8, subfunction 1).
3.2.7 10 (0A Hex) Clear Counters and Diagnostic Register
For controllers other than the 584 or 984, clears all counters and
the diagnostic register. For the 584 or 984, clears the counters
only. Counters are also cleared upon power-up.
3.2.8 11 (0B Hex) Return Bus Message Count
The response data field returns the quantity of messages that the
slave has detected on the communications system since its last
restart, clear counters operation, or power-up.
3.2.9 12 (0C Hex) Return Bus Communication Error Count
The response data field returns the quantity of CRC errors
encountered by the slave since its last restart, clear counters
operation, or power-up.
3.2.10 13 (0D Hex) Return Bus Exception Error Count
The response data field returns the quantity of Modbus exception
responses returned by the slave since its last restart, clear
counters operation, or power-up. For a description of exception
responses, see page .
3.2.11 14 (0E Hex) Return Slave Message Count
The response data field returns the quantity of messages
addressed to the slave, or broadcast, that the slave has processed
since its last restart, clear counters operation, or power-up.
3.2.12 15 (0F Hex) Return Slave No Response Count
The response data field returns the quantity of messages
addressed to the slave for which it returned no response (neither a
normal response nor an exception response), since its last restart,
clear counters operation, or power-up.
3.2.13 16 (10 Hex) Return Slave NAK Count
The response data field returns the quantity of messages
addressed to the slave for which it returned a Negative
Acknowledge (NAK) exception response, since its last restart,
clear counters operation, or power-up. For a description of
exception responses, see page .
3.2.14 17 (11 Hex) Return Slave Busy Count
The response data field returns the quantity of messages
addressed to the slave for which it returned a Slave Device Busy
exception response, since its last restart, clear counters operation,
or power-up. For a description of exception responses, see page
.
3.2.15 18 (12 Hex) Return Bus Character Overrun Count
The response data field returns the quantity of messages
addressed to the slave that it could not handle due to a character
overrun condition, since its last restart, clear counters operation,
or power-up. A character overrun is caused by data characters
arriving at the port faster than they can be stored, or by the loss
of a character due to a hardware malfunction.
3.2.16 19 (13 Hex) Return IOP Overrun Count (884)
The response data field returns the quantity of messages
addressed to the slave that it could not handle due to an 884 IOP
overrun condition, since its last restart, clear counters operation,
or power-up. An IOP overrun is caused by data characters
arriving at the port faster than they can be stored, or by the loss
of a character due to a hardware malfunction.
Note: This function is specific to the 884.
3.2.17 20 (14 Hex) Clear Overrun Counter and Flag (884)
Clears the 884 overrun error counter and resets the error flag.
The current state of the flag is found in bit 0 of the 884 diagnostic
register (see subfunction 02).
Note: This function is specific to the 884.
3.2.18 21 (15 Hex) Get / Clear Modbus Plus Statistics
Returns a series of 54 16-bit words (108 bytes) in the data field of
the response (this function differs from the usual two-byte length
of the data field). The data contains the statistics for the
Modbus Plus peer processor in the slave device.
In addition to the Function code (08) and Subfunction code (00 15
hex) in the query, a two-byte Operation field is used to specify
either a Get Statistics or a Clear Statistics operation. The two
operations are exclusive-the Get operation cannot clear the
statistics, and the Clear operation cannot return statistics prior to
clearing them. Statistics are also cleared on power-up of the slave
device.
The operation field immediately follows the subfunction field in
the query:
V -- A value of 00 03 specifies the Get Statistics operation.
V -- A value of 00 04 specifies the Clear Statistics operation.
Query
This is the field sequence in the query:
Get Statistics Response
This is the field sequence in the normal response to a Get
Statistics query:
Clear Statistics Response
The normal response to a Clear Statistics query is an echo of the
query:
3.2.19 Modbus Plus Network Statistics
Note: Word 07 bitmaps are used internally by the peer
processor to determine which paths have already had a
command sent to them during the current token ownership. This
limits the number of commands per path to one during a single
token ownership.
Note: Words 08 ... 12 are token owner work tables. They are
bitmaps representing work that needs to be done by the node the
next time it gets the token. Each byte is a bitmap corresponding
to work requested of each of the eight paths of the indicated
type.
Note: Words 13 ... 22 contain pairs of 8-bit counters that
pertain to certain types of error conditions as well as to
successful transactions. Under normal operating conditions, the
only bytes that change are word 20 LO and HI. Word 14 HI
could also increment because of an MSTR or similar
programming error in the application. If any other bytes
increments, a possible problem exists on the network-e.g., in a
single station or wiring connection.
Note: Words 23 ... 26 contain the active station bitmaps. An
active station is any one that has sent packets of data over the
network.
Note: Words 27 ... 30 contain the token station table bitmaps.
A token station is any one that has token-passing capabilities.
Note: Words 31 ... 34 contain the global data present table
bitmaps. Each time a station passes a token, it also passes the
global data, even if there are zero bytes of global data. When one
station sees another pass the token with global data, it sets its
bit in its table for that other station. The bit remains set until
the station reads the global data from that other station, after
which the bit is cleared. A second read of global data indicates
that no global data is present.
Note: In screen 2 of the MBPSTAT program, the number of
global data words present is indicated under the station number.
If this field is filled with spaces, then MBPSTAT has requested
the global data from a second time before the other station
passed the token.
Note: The LO bytes of words 35 ... 37 indicate the use of the
internal receive buffers within the peer processor.
www.automatas.org
