Consider Modbus "T delay" (Minimum time before new query)
sauvant opened this issue · comments
Describe the bug
At least the energy meters I communicate with (https://gavazzi.se/app/uploads/2020/11/em330_em340_et330_et340_cp.pdf) define a minimum delay between end of latest response and next request. When not respecting it, I receive a "E0" timeout every now and then. I use syncRequest() here, dont know if addRequest() behaves different.
Expected behavior
Respect the delay. Is it Modbus standard? Then please implement it. If it is not: add a parameter to specify the delay and make sure it is respected.
To Reproduce
Send a requests with bus idle time after latest response < expected delay
Are you referring to ModbsuRTU? ModbusClientTCP has such a waiting time between requests: documentation.
With the synchronous requests there will be no issue anyway, as you are able to wait as long as you like before sending the next.
I did not implement such a feature in ModbusClientRTU yet, because the server addressed last is not kept anywhere. With TCP we have a single connection, thus we always will know that we are connected to the same server.
Yes, I am referring to ModbusRTU.
With the synchronous requests there will be no issue anyway, as you are able to wait as long as you like
before sending the next.
And that is what I do now after I had a hard time to understand what is happening here... Therefore my idea to add that to the library avoiding same trouble for others.
I did not implement such a feature in ModbusClientRTU yet, because the server addressed last is not kept anywhere.
It is not even related to one client. In my case it appeared when switching to another client. The first request to that client got the timeout every now and then because the request was sent to fast after the first client's response.
It is not even related to one client. In my case it appeared when switching to another client. The first request to that client got the timeout every now and then because the request was sent to fast after the first client's response.
That is hinting to a problem with the server - it seems not to be able to maintain the minimum required interval between messages on the bus. This is in fact respected by the eModbus code, so the server seems to recover too slow. You can check that by setting the inter-message interval yourself to some longer value. There is a parameter with the begin() call of the RTU client: documentation.
Cool, thank you. I will give it a try!