dingo35
Increase modbus timeout
For a new installation I had the challenge of connecting the SensorBox to SmartEVSE which are in 2 unconnected buildings, separated 30m and no option for adding a new cable.
Given that an existing network connection exists between the buildings I opted for a RS485-Ethernet converter on both ends. One configured as a TCP-server, the other as TCP-client. I don't make use of the modbus capabilites of these devices, as this could lead to multiple masters on the same bus. So plain RS485 point-to-point tunneled over TCP.
At first glance, this seems to work without any issue, SmartEVSE reporting the currents of the Sensorbox.
However, after ~11s the error ERROR NO SERIAL COM CHECK CFG OR WIRING, which than also cleared after 1-2s. This repeats.
Redoing / checking the wiring and config didn't help.
With the debug firmware I identified that Modbus was having timeout issues, which was configured to be be 85ms.
Looking at the specs of the converter it states that Average Transmission Delay <10ms. But this is for a single conversion I assume. So for a full Request-Response cycle, we encounter this delay 4 times.
Configuring the modbus timeout to 95ms (below the mentioned 100ms) was not sufficient and the behavior remained the same.
When the timeout was increased to 200ms all communication errors disappeared and the complete SmartEVSE seems to function properly.
Open question remains: Is there an issue with having timeout > 100ms modbusRequestloop? I cannot oversee this impact, however I looks like everything works fine.
If there is no issue, I would like to contribute this change, so other users can use these converters as well. Even willing to add some diagrams / configs how to setup.
@mstegen, can you share your insights on whether this increased timeout can cause issues or not?
Hi, Thanks for explaining your use case, and the tests you have done.
For a few devices this might work fine, however if you want to use 8 SmartEVSE's plus their modbus kWh meter, then polling the status of all devices + responding to them will take more time then 2 seconds.
It used to be that every 100ms a new modbus request was made, but that caused issues as old data would come in after a new request was made. Now it waits either for a response with data or a timeout before sending the next request from the loop.
But to keep things running stable, every 2 seconds the modbusrequestloop is started from the beginning again.
So this can not easily be solved without fixing the amount of request are done per loop.
Things i can think of:
- increasing the baudrate to 19k2 (sensorbox will need update for that)
- increase the loop from 2S->4S, this will lead to slower response/ current regulation.
- do some trickery, by not polling all SmartEVSE's on every loop. (or perhaps only the ones that are 'online')
Polling for Nodes 1-7 currently takes the most amount of time, especially when there is no Node connected. When you increase the timeout to 200mS this will take 7x0.2S= 1.4S, just to see if there is a Node online. That leaves very little time for reading meters, and responding to charging requests.
Hi, Thanks for explaining your use case, and the tests you have done.
For a few devices this might work fine, however if you want to use 8 SmartEVSE's plus their modbus kWh meter, then polling the status of all devices + responding to them will take more time then 2 seconds.
It used to be that every 100ms a new modbus request was made, but that caused issues as old data would come in after a new request was made. Now it waits either for a response with data or a timeout before sending the next request from the loop. But to keep things running stable, every 2 seconds the
modbusrequestloopis started from the beginning again.So this can not easily be solved without fixing the amount of request are done per loop.
Things i can think of:
- increasing the baudrate to 19k2 (sensorbox will need update for that)
- increase the loop from 2S->4S, this will lead to slower response/ current regulation.
- do some trickery, by not polling all SmartEVSE's on every loop. (or perhaps only the ones that are 'online')
Polling for Nodes 1-7 currently takes the most amount of time, especially when there is no Node connected. When you increase the timeout to 200mS this will take 7x0.2S= 1.4S, just to see if there is a Node online. That leaves very little time for reading meters, and responding to charging requests.
Thanks for the explanation and reasoning of the < 100ms. To my understanding, there is not a technical issue with values > 100ms, however when loadbalancing is enabled the total amount of requests (and timeouts) becomes too large to also handle other communication.
Some suggestions from my side:
- The 200ms was just a wild guess, 95ms was not sufficient. What would be the upper limit? I can try which value still works for this setup.
- Would it be possible to change the timeout per type of request?
Hi Koen, It would need a rewrite of the modbusrequestloop, and connecting a scope on the modbus data line, to determine the exact upper limit. But the whole looptime is already close to 2sec.
- Request Mainsmeter current measurement
- Request Node 1 configuration (only once after powerup, or if config has changed)
- do the same for Nodes 2-7 if needed
- read Node's EV meter Energy Measurement (every 2 sec the next Node's EV meter will be read)
- read Node's EV meter Power Measurement
- Read Node 1 Status
- If there is a need to write back data to the Node 1 (Charging request OK, Mode change), write data back
- Read Node 2 Status
- do the same for node 3-7
- Read Node's EV meter Current Measurement
- Read Energy from Modbus Mainsmeter. (every 30 sec)
- Broadcast the new chargecurrent for the Nodes and/or error state
let's say that each request + response takes 100ms.. And we ignore the configuration reads, and Mode changes for now. Then it would take roughly 300ms + 700ms (Node Status read) + 300ms so 1.3 sec When we do a mode change from Smart to Solar: 300ms+ 1400ms + 300ms = 2 Sec
No the timeout is fixed for all modbus requests (eModbus library setting).