These log entries are made when the Std option in interpreted logging is selected, provided that the data can be interpreted as a Modbus message. In common with raw data logging, the timestamp is followed by the character '<' for an incoming message or '>' for an outgoing message. However, the interpretation of the raw data s displayed as two lines.

10:59:31.510: < transid 146 slave 1 pdulen 5 func 3: 00 1a 00 02
10:59:31.514:       Request: Read Holding Registers: address 26, count 2

In the first line the transaction identifier starts the remainder of the line (if it is a TCP packet), and this is followed by the slave identifier, PDU length (in bytes), function code, and then the first few bytes of the body of the message (in hex).

The second line of a message trace provides further interpretation of the main fields in the message. After the time stamp, the line starts with either "Request", "Response" (where there is no error) or "Error response". "Request" and "Response" labels are followed by the function code (expressed in words) and the main fields of the message (e.g. address, count, etc.), Here is the "Response to the "Request" example above:

10:59:31.523: > transid 146 slave 1 pdulen 6 func 3: 04 00 01 00 00
10:59:31.534:       Response: Read Holding Registers: byte count 4, data bytes 4

Where the message is an error response, the second line contains "Error response" followed by the error code (expressed in words), and possibly by further explanation of the error. Here is an error response along with its request:

12:19:39.659: < transid 147 slave 1 pdulen 5 func 3: 00 14 00 02
12:19:39.709:       Request: Read Holding Registers: address 20, count 2
12:19:39.713: > transid 147 slave 1 pdulen 2 func 131: 02
12:19:39.721:       Error response: Illegal data address - 
                     No Holding Register at model address 20 (message address 20)

If ModSlaveSim receives any data that can not be interpreted as a Modbus message, it will trace the ill-formed data. It is displayed in hex on a separate line, preceded by the time and the incoming message character '<'. This line is followed by a second line with the word "Discarded" followed by the number of bytes discarded and an explanation of what is wrong with the format. For example:

15:18:13.554: < 00 01 00 00 00 06 01 03 00 64 02 01
15:18:13.555:       Discarded 12 bytes: Invalid CRC

Lines with "Response not sent" following the time may also be displayed in the trace window following a "Request" line. These indicate that ModMultiSim did not send a response to a request from the master - the rest of the line says why the response was not sent. For example:

16:19:18.776: < slave 0 pdulen 5 func 6: 00 c8 00 0c
16:19:18.777:       Request: Write Single Register: address 200, data bytes 2
16:19:18.778:       Response not sent: Request was broadcast

These log entries are made when the option to extend tracing to include register values written (Ext (W)), or values both read and written (Ext (W/R)), is selected. Following the standard tracing of the "Request", each read or write of a defined register is traced as a single line in the log.

The line starts with the timestamp. followed by the character 'R' or 'W' for a value read or written respectively. This is followed by the slave ID, the register address and the value read or written. Note that the register address is a "model" address (see Map Addresses). For example:

10:25:11.952: < transid 2 slave 5 pdulen 5 func 3: 00 05 00 03
10:25:11.978:       Request: Read Holding Registers: address 5, count 3
10:25:11.983:         R  5  5  251.985
10:25:11.985:         R  5  6  35.9978
10:25:11.986:         R  5  7  71.9957