Doesn't connect with eModbus #15
Comments
|
From a quick overview of eModbus, I see that the library supports an ESP32 being either client or server. I am assuming that the connection is successful if using the AsyncTCP original library in all cases. Is this correct? Which devices are ESP32 using eModbus plus AsyncTCPSock? The client? The server? Both? If there are two ESP32 involved, which one shows the error? Have you tried flashing just one of them with AsyncTCPSock, and then only the other, to see which side is actually faulty (client or server)? What snapshot of AsyncTCPSock have you tested? The latest commit was at September 2. Have you used Wireshark or similar sniffers to check out the traffic with both a successful and a failing case? |
|
Hi, sorry I dropped the email without too much information. I am using the client (I have around 20), and running it with AsyncTCP It works (some errors about the mismatch of the PCB but 0.6% failed requests of 600k). About the code base is my full project, an extensive code base. I am compiling with No sorry I used didn't run Wireshark or something similar, the boards are running in a dedicated WiFi. I will try to run an example file from eModbus and check if works. |
|
I created https://github.com/mcuadros/eModbusTCPAsyncSocket, this contains The output is |
You should enable the eModbus full verbose debugging output, and if possible, the full ESP32 debugging output too. From code examination, it seems you need to enable the LOG_LEVEL macro at the project level to the same value as LOG_LEVEL_VERBOSE, defined as After doing that, please repeat your test and paste the extended error messages. |
|
Just to check, I compiled your program with Arduino IDE 2.0.0 and Arduino-ESP32 2.0.5, and flashed it into a spare ESP32 board. I had to disable the portion in which the gateway, ip, and subnet were explicitly set in the WiFi connction, and instead relied on standard DHCP to get an address. I also ran a netcat listening on port 502 and running /bin/cat on every incoming connection so there is some data, even if invalid. I get the following: In my scenario, the library does connect and starts exchanging data. The only thing that is different, besides different WiFi credentials, is using DHCP instead of static IP and gateway information. |
|
Ok, I was able to make it "run" more or less. Looks like something is going slow or the callbacks are not triggered properly. I am using https://github.com/mcuadros/eModbus/blob/pointer/src/ModbusClientTCPasync.cpp#L383, and removing this line, It's running BUT... The 10% of the request fail with a timeout (the timeout is set to 500ms), and the success requests are slow around 120ms. Same code TCPAsync, I have 0.01% timeout and avg request of 30ms. Any idea? Thanks for your time. |
I have a theory of what might be happening. The diff --git a/src/AsyncTCP.cpp b/src/AsyncTCP.cpp
index 217d862..21d777c 100644
--- a/src/AsyncTCP.cpp
+++ b/src/AsyncTCP.cpp
@@ -898,7 +898,7 @@ void AsyncClient::_sockIsReadable(void)
void AsyncClient::_sockPoll(void)
{
- if (_socket == -1) return;
+ if (!connected()) return;
uint32_t now = millis();
Flush any compiled code caches that might apply, recompile your test program and test. If this fixes your issues, I will make a proper commit to the library. Do not forget to undo your patch to eModbus as part of your tests - this is important to test the fix to the API compatibility bug. |
|
Sadly nothing changed :/ |
|
Just to be in the same page, could you please tell me:
There is something strange about your line numbers within that backtrace that does not line up with my git checkout of the project. Also, a crash in the middle of taking a semaphore is unexpected in that code path. |
|
I am using the code from my branch since About arduino-esp32 I am using 2.0.5. One question... eModbus expects to have the full message available to read on |
I have not really reviewed the eModbus code, but if what you mention is true, then it is an eModbus library bug. The received TCP stream is, conceptually, a continuous stream of ordered bytes. The AsyncTCP API cannot guarantee that a certain amount of buffering will be made - it just reads the stream and calls the |
|
https://github.com/eModbus/eModbus/blob/master/src/ModbusClientTCPasync.cpp#L233 It doesn't buffer it; just check if the onData has more than 6 bytes, and if yes, it decodes the message and try to read the full message directly based on the 6 bytes (the head with the length of the message). |
I am trying to make it work with eModbus, but apparently doesn't work, doesn't panic or error, just says can't connect. It's a complex project, so I can provide a sample code sorry for that.
In theory, is a drop-in replacement for AsyncTCP, right? Any hint to make it work?
Thanks for this wonderful initiative, AsyncTCP is very useful and convenient, but I always reach glitches that make me spend dozens of hours on debugging.
The text was updated successfully, but these errors were encountered: