Mismatch between response and requist
RobPee2023 opened this issue · comments
Do not use to discuss topics!
Describe the bug
A clear and concise description of what the bug is. Which components of eModbus did you use?
When using the ModbusServer TCP WiFi library on ESP32, there is an issue where the device continues to reply to outdated messages if it momentarily loses and then re-establishes a connection.
Logger:
////START/////
09:09:55.448 Tx DeviceAddr: 1 FC: 3 Start: 2 Length: 2
09:09:55.535 Rx DeviceAddr: 1 FC: 3 Start: 2 Register length: 2
09:09:55.745 Tx DeviceAddr: 1 FC: 3 Start: 2 Length: 2
09:09:56.756 Block with function 3 gives an IOException: Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
09:09:56.972 Tx DeviceAddr: 1 FC: 3 Start: 2 Length: 2
09:09:57.990 Block with function 3 gives an IOException: Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
09:09:58.207 Tx DeviceAddr: 1 FC: 3 Start: 2 Length: 2
09:09:58.217 Block with function 3 gives an IOException: Response was not of expected transaction ID. Expected 8, received 6.
////END/////
Expected behavior
It should keep responding on the latest message it receives. now there will be continuing a mismatch until i reconnect the Master.
To Reproduce
Start polling the ESP32. Cover it with your hand until you'll receive an error on your modbusmaster that there is a connection issue. then let it regain signal and you'll see in the modbusmaster that there is a different response on a different request.
Example code
Default ModbusServer TCP Wifi example.
Put code here to reproduce the bug, if possible
See "To Reproduce"
Additional context
I've tried looking additional programming to printout everything (modbusrequest and response). Only part i'm missing is the transactionID. My guess the error will probably lay there since it seems it isn't possible to read it out.
Since almost all is missing to see what the library does, please compile both library and your code with -DLOG_LEVEL=6. If you happen to be using the Arduino IDE, please temporarily modify the Logging.h library source right at the beginning to set the default LOG_LEVEL to LOG_LEVEL_VERBOSE. The resulting log should give some insights into what is happening.
Utilizing another program to poll from the ESP32 where i'm able to receive these errors (that i have shown in the logger)
Yeah, but still... I would like to see what the ESP32 does.
Using the Arduino IDE and did what you suggested:
#ifndef LOG_LEVEL
#define LOG_LEVEL LOG_LEVEL_VERBOSE
#endif
Serial plotter isn't showing any additional information with this change. Still only the amount of client is printed out.
That is strange - normally lots of tracing should be printed to the Serial Monitor (not the Plotter, of course!). Can you try again?
My bad meant serial monitor. Fixed the library issue (didn't save ofc...)
What is seeing is following:
Arduino IDE (keeps adding transaction ID with 1)
0 clients running.
[D] 220755| ModbusServerTCPtemp.h [ 210] accept: Started client 0 task 1073573132
[D] 220756| ModbusServerTCPtemp.h [ 239] serve: Accepted connection - 1 clients running
[D] 220756| ModbusServerTCPtemp.h [ 261] worker: Worker started, timeout=10000
[D] 220785| ModbusServer.cpp [ 22] getWorker: Need worker for 01-03 : Worker found for 01/03
[D] 220786| ModbusServerTCPtemp.h [ 314] worker: Data response
[V] Response: @3FFD7468/13:
| 0000: 00 01 00 00 00 07 01 03 04 02 03 04 05 |............. |
[D] 221774| ModbusServer.cpp [ 22] getWorker: Need worker for 01-03 : Worker found for 01/03
[D] 221775| ModbusServerTCPtemp.h [ 314] worker: Data response
[V] Response: @3FFD7468/13:
| 0000: 00 02 00 00 00 07 01 03 04 02 03 04 05 |............. |
[D] 224997| ModbusServer.cpp [ 22] getWorker: Need worker for 01-03 : Worker found for 01/03
[D] 224997| ModbusServerTCPtemp.h [ 314] worker: Data response
[V] Response: @3FFD7494/13:
| 0000: 00 03 00 00 00 07 01 03 04 02 03 04 05 |............. |
1 clients running.
[D] 227185| ModbusServer.cpp [ 22] getWorker: Need worker for 01-03 : Worker found for 01/03
[D] 227186| ModbusServerTCPtemp.h [ 314] worker: Data response
[V] Response: @3FFD74C0/13:
| 0000: 00 04 00 00 00 07 01 03 04 02 03 04 05 |............. |
[D] 228716| ModbusServer.cpp [ 22] getWorker: Need worker for 01-03 : Worker found for 01/03
[D] 228716| ModbusServerTCPtemp.h [ 314] worker: Data response
[V] Response: @3FFD7494/13:
| 0000: 00 05 00 00 00 07 01 03 04 02 03 04 05 |............. |
ModbusPoller:
10:40:04.497 Tx DeviceAddr: 1 FC: 3 Start: 2 Length: 2
10:40:04.569 Rx DeviceAddr: 1 FC: 3 Start: 2 Register length: 2
10:40:05.483 Tx DeviceAddr: 1 FC: 3 Start: 2 Length: 2
10:40:06.499 Block with function 3 gives an IOException: Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
10:40:07.413 Tx DeviceAddr: 1 FC: 3 Start: 2 Length: 2
10:40:08.427 Block with function 3 gives an IOException: Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
10:40:09.346 Tx DeviceAddr: 1 FC: 3 Start: 2 Length: 2
10:40:10.362 Block with function 3 gives an IOException: Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
10:40:11.281 Tx DeviceAddr: 1 FC: 3 Start: 2 Length: 2
10:40:11.340 Block with function 3 gives an IOException: Response was not of expected transaction ID. Expected 5, received 2.
10:40:12.247 Tx DeviceAddr: 1 FC: 3 Start: 2 Length: 2
10:40:12.478 Block with function 3 gives an IOException: Response was not of expected transaction ID. Expected 6, received 3.
10:40:13.394 Tx DeviceAddr: 1 FC: 3 Start: 2 Length: 2
10:40:13.394 Block with function 3 gives an IOException: Response was not of expected transaction ID. Expected 7, received 4.
10:40:14.308 ModbusRunner ended
Note that around address 2 i put my hand around the ESP and then let it regain connection
I see in the log that the responses are counted up from 1 without repetition, so where do you see the duplicates? The TCP header is copied from the request anyway.
Not saying there are duplicates.
The ModbusMaster (Client) log indicates that it failed to read data due to a lack of connection, as the ESP32 (Server) was covered, affecting three addresses. Following this, once the ESP32 (Server) reestablished connection, it continued to respond to the 'timed out' requests from the ModbusMaster (Client).
So after a connection issue there is a mismatch between Client & Server on the transaction ID part
So after a connection issue there is a mismatch between Client & Server on the transaction ID part
Well, yes? So what would you propose for the server to do - "Uh, I had a glitch, let's drop all we did so far!" versus "I think this was just a glitch, so send the response anyway."
By the way: the ESP32 has not even noticed a dropout (There is no further "Accepting connection..." in the log), according to the log, so it could not have acted differently.
The ESP isn't receiving the older requests.
ModbusMaster sends out a request and has a few TimeOut errors which means he isn't receiving responses of the ESP. After the communication is back 'online' the esp starts responding on the transaction ID's when it was 'offline' even though the client is now polling with a higher transaction ID.
Is it possible to read out the request from client as well since now the terminal is only showing the response
You could add a logging line in ModbusServerTCPtemp.h here, like
HEXDUMP_V("Request:", m.data(), m.size());
Ok this confirmed it isn't about the modbus driver, thanks! will close.