Software issues with Modbus Server Tester - request frame error


Thread Starter

Julian Kraemer

I'd like to use the Modbus Server Tester (version 0.1.5) for serial communication with a Modbus server (RTU).

The Modbus Server Tester (MST) can access and open the serial port (19200,8,E,1) without any problems. But I'm getting error messages when I attempt to read data (e.g. Input Register on address 0, qnt 1).

a) menu: <b>Tests -> Synchrone Request</b>:
First error message: <i>"Get Request Frame Error (0x9000)"</i>
Second error message right after the first one: <i>"Synchrone Request 4 Error (0xFFFF9000)"</i>

b) menu: <b>Tests -> Asynchrone Request</b>:
error message: <i>"Synchrone Request 4 Error (0xFFFF9000)"</i>

<pre>No Date Type Frame
1 Req 01 04 00 00 00 01
2 Req 01 04 00 00 00 01
I ran MST under Windows 7 and Windows XP. Even different compatibility modes like "Windows NT4.0 SP5" had no effect on the issue.

Other Modbus master simulation software do work without any problems (so I guess hardware, driver, Windows settings etc. seem to be okay).

Does someone have a clue?

Thanks in advance!
It is very unusual/unexpected to see parity enabled for ModBus RTU protocol. CRC checking is a far more capable means of detecting errors then is parity checking.
How do you figure?
Have a look at <i>MODBUS over serial line specification and implementation guide V1.02</i> page 19 or page 34.

The device (server) and the application MST (client) do both, parity checking and frame checking (CRC).
You can do anything you want as long as your master and slave(s) are all playing the same game. To me, seeing parity enabled raises a red flag, as in, are all my devices configured for parity?
>No Date Type Frame
>1 Req 01 04 00 00 00 01
>2 Req 01 04 00 00 00 01</pre>
The trace-log is not complete. The actual poll would need to be 8 bytes, the CRC bytes are not shown, they would be 0x31 and 0xCA.

We can only guess as good as the "goodness" of the information provided. Just trying to help.
That's exactly why most of the Modbus devices support even, odd and _no_ parity.

I totally agree with most of your statements, but I don't think it is unusual or unexpected to use parity check on RTU.
...but we shouldn't end up arguing about message validation :)