QModbusDevice timeout

[Mark81]

About the signal timeoutChanged the documentation says:

This signal is emitted if the response is not received within the required timeout.

But I experience a different behavior. This is my test code:

QModbusTcpClient *modbus = new QModbusTcpClient(this);
connect(modbus, &QModbusClient::timeoutChanged, this, &ModbusMaster::timeoutChanged);
connect(modbus, &QModbusClient::stateChanged, this, &ModbusMaster::stateChanged);
connect(modbus, &QModbusClient::errorOccurred, this, &ModbusMaster::errorOccurred);

modbus->setConnectionParameter(QModbusDevice::NetworkPortParameter, 502);
modbus->setConnectionParameter(QModbusDevice::NetworkAddressParameter, "127.0.0.1");    

modbus->setTimeout(250);
modbus->setNumberOfRetries(1);
modbus->connectDevice();

Actually, the timeoutChanged signal is emitted when I set the timeout (modbus->setTimeout(250);) it seems more like a notifier signal than a real "timeout happened".

Furthermore, if the server is not available, I would expect an error (errorOccurred signal and stateChanged to UnconnectedState) within the set timeout value (250 ms). Instead they fire after more than 40 seconds!!!!

Where's my fault here?

[J.Hilk]

hi, @Mark81 said in QModbusDevice timeout:

Actually, the timeoutChanged signal is emitted when I set the timeout (modbus->setTimeout(250);) it seems more like a notifier signal than a real "timeout happened".

Furthermore, if the server is not available, I would expect an error (errorOccurred signal and stateChanged to UnconnectedState) within the set timeout value (250 ms). Instead they fire after more than 40 seconds!!!!

Where's my fault here?

timeoutchanged is indeed a notifyer that is emited when the timeout time is actually changes, that happens by each call to setTimeout, probably has something to do with QProperty and QML.

the actual timeout of this Qtimer triggers a QModbusDevice error, this one

QModbusDevice::TimeoutError	5	A timeout occurred during I/O. An I/O operation did not finish within a given time frame.

That is not triggered during connection, but only when exchaning packages with the ModbusMaster

[Mark81]

Perhaps my English is not so good, but it seems the documentation is misleading here.
Ok, I made a workaround using a QTimer and manually handle the connection timeout - sadly.

[aha_1980]

Hi @Mark81,

I guess your English is good enough, as I find the documentation incorrectly too.

What I expect the signal void QModbusClient::timeoutChanged(int newTimeout) to do is to react on void QModbusClient::setTimeout(int newTimeout) and nothing else.

I'll check that and prepare a documentation fix.

Regards

[J.Hilk]

@aha_1980 said in QModbusDevice timeout:

Hi @Mark81,

I guess your English is good enough, as I find the documentation incorrectly too.

What I expect the signal void QModbusClient::timeoutChanged(int newTimeout) to do is to react on void QModbusClient::setTimeout(int newTimeout) and nothing else.

I'll check that and prepare a documentation fix.

Regards

now I'm confused, to what else is it reacting?

[Mark81]

@J.Hilk said in QModbusDevice timeout:

now I'm confused, to what else is it reacting?

The problem is on the documentation only, as it implies it would reacting to an actual timeout:

This signal is emitted if the response is not received within the required timeout.

and doesn't say it is fired whenever the property is changed.

[aha_1980]

Hi @J.Hilk,

if you look at https://code.woboq.org/qt5/qtserialbus/src/serialbus/qmodbusclient.cpp.html#_ZN13QModbusClient10setTimeoutEi you see when the signal is emitted.

That is it's only purpose.

Documentation fix is here: https://codereview.qt-project.org/#/c/241620/1

[J.Hilk]

oh!
ok, thats defenitly a contradictory entry! I only read the Note myself. x)

void QModbusClient::timeoutChanged(int newTimeout)
This signal is emitted if the response is not received within the required timeout. The new response timeout for the device is passed as newTimeout.

Note: Notifier signal for property timeout.

[aha_1980]

Hi @Mark81,

what stays is the connection timeout. I think the ~40 seconds come from the default TCP connection timeout and I'm not sure how to easily change that (I'm not that familiar with the Modbus code).

You could ask on the interest mailing list if there's a way to set this timeout. At least it looks like some reasonable thing to do if a machine in the local network is not responding, 30-40 seconds is far to long.