Qt Modbus RTU timeout

szergejbubka

Hi,

I have a PLC communicating with Modbus RTU. I compiled and run the Modbus master example in Qt 5.11, and it throws timeout errors, when I try to read the holding registers. I set all parameters correctly and the PLC works well too. I know it, because if I compile the same Qt example with Qt 5.8 instead of 5.7, 5.9, 5.10 or 5.11, it works well and responses correctly. The debug messages show that the response arrives correctly on all versions, but somehow not processed by the Qt Modbus module, instead throws error after the timeout period elapsed. I use Ubuntu Linux 64bit, and previously already deployed an industrial project using modbus with Qt 5.8 successfully. Can this false behaviour somehow changed? Maybe a new parameter somewhere?

Thanks.
Best,
Andras

Cleiton Bueno

Hi, @szergejbubka

What register value are you trying to read?
Could you please attach the error here?

Cleiton Bueno

Blog | Linkedin | B2Open

szergejbubka

Hi @Cleiton-Bueno,

I tried multiple holding register read starting from 0 and reading 1 register (but I even tried other parameters, more registers, starting from 1, etc.). The connection parameters are 115200,8,N,1, it is a virtual com port on /dev/ttyACM0. The device address is 2. The timeout is 1000ms and the retries are 3 attempts. With Qt 5.11 I get this output:

qt.modbus: (RTU client) Sent Serial PDU: 0x0300000001
qt.modbus.lowlevel: (RTU client) Sent Serial ADU: 0x0203000000018439
qt.modbus.lowlevel: (RTU client) Response buffer: "0203020000fc44"
qt.modbus: (RTU client) Received ADU: "0203020000fc44"
qt.modbus: (RTU client) Send successful: 0x0300000001
qt.modbus: (RTU client) Receive timeout: 0x0300000001
qt.modbus: (RTU client) Sent Serial PDU: 0x0300000001
qt.modbus.lowlevel: (RTU client) Sent Serial ADU: 0x0203000000018439
qt.modbus.lowlevel: (RTU client) Response buffer: "0203020000fc44"
qt.modbus: (RTU client) Received ADU: "0203020000fc44"
qt.modbus: (RTU client) Send successful: 0x0300000001
qt.modbus: (RTU client) Receive timeout: 0x0300000001
qt.modbus: (RTU client) Sent Serial PDU: 0x0300000001
qt.modbus.lowlevel: (RTU client) Sent Serial ADU: 0x0203000000018439
qt.modbus.lowlevel: (RTU client) Response buffer: "0203020000fc44"
qt.modbus: (RTU client) Received ADU: "0203020000fc44"
qt.modbus: (RTU client) Send successful: 0x0300000001
qt.modbus: (RTU client) Receive timeout: 0x0300000001
qt.modbus: (RTU client) Sent Serial PDU: 0x0300000001
qt.modbus.lowlevel: (RTU client) Sent Serial ADU: 0x0203000000018439
qt.modbus.lowlevel: (RTU client) Response buffer: "0203020000fc44"
qt.modbus: (RTU client) Received ADU: "0203020000fc44"
qt.modbus: (RTU client) Send successful: 0x0300000001
qt.modbus: (RTU client) Receive timeout: 0x0300000001

Whereas with Qt 5.8 I get this one:

qt.modbus: (RTU client) Sent Serial PDU: 0x0300000001
qt.modbus.lowlevel: (RTU client) Sent Serial ADU: 0x0203000000018439
qt.modbus.lowlevel: (RTU client) Response buffer: "0203020000fc44"
qt.modbus: (RTU client) Received ADU: "0203020000fc44"

It really seems like the error is in the processing of the response.

Thanks,
András

Pablo J. Rogina

@szergejbubka if you look at Qt SerialBus module source code, is this change maybe related to the behavior you mentioned?

Due to the nature of our serial bus device, a frame could already
be send completely, but the bytes written did not report that yet.
Then we received an answer before we reached the receive state,
messing up the whole state logic. Now we process incoming frames
only if we are in receive state, otherwise drop full frames.

szergejbubka

@Pablo-J.-Rogina I do not know. How could I test it? Can this behaviour be changed by using parameters? For example by forcing a receive state? What was the reason of this change? This seems to be broken for me now.

Thanks,
András

aha_1980

@szergejbubka said in Qt Modbus RTU timeout:

I do not know. How could I test it?

You could simply revert the patch and compile QtSerialBus again for testing.

Can this behaviour be changed by using parameters?

Not that I'm aware of.

For example by forcing a receive state?

That would be an awful hack... I think usually the module should be in receive state when data is received. Anything else sounds like a bug.

What was the reason of this change?

QTBUG-62144 and QTBUG-62299, as stated in the commit message.

This seems to be broken for me now.

Then please verify if its really this patch that causes your problems and then create your own bugreport, providing as much information as possible.

Please also provide a link to your report here. Thanks.

aha_1980

It seems this is now tracked as QTBUG-69188.

AlexBlasche

I believe this is fixed by https://codereview.qt-project.org/#/c/221549/ and was caused by the fix for bug https://bugreports.qt.io/browse/QTBUG-62299.