Closed JensInternal closed 2 years ago
Thank your for submiting, please be sure you followed template or your issue may be dismissed.
Using putty should work - unless FluidNC does not give answer because FW is busy, ESP has limited resource do you use WebUI in same time as telnet ? or serial in same time as telnet ?
Thanks, Luc, for your advice.. I set up a test case:
So, in my thinking, something within VSC/PlatformIO/Serial monitor/my programm seems to be an issue.
I think if you do permanent pollling on serial, the telnet has no time to respond on time because FW is busy with serial. remember ESP board is little chip with good capabilities but not supporting really multithreading like a PC
Ok, test case adjusted to avoid interference with
WebUI
serial connection
VSC/PlatformIO/Serial monitor
Any open connections are closed at the beginning
WiFi is close at the beginning, then opened again
Connection is closed after successful interaction with FluidNC
My program now switches on the internal LED, if a connection is established.
Switched on FluidNC, Homed XYZ, idle mode, no other external connections
Connected ESP32/USB
Once I hit the reset button in WebUI, I get a connect immediately (LED on)
Pressing reset button delivers repeatable results
Later, I switched serial on again, proper results.
So, in my understanding I didn't close the client connection before reset when leaving serial monitoring with CTRL-C, the program was still running with an open connection to FluidNC. Seems any timeout or open connections survived the reset.
Let´s see :-)
Issue probably found.
Adding a client.stop() after doing Grbl processing and before the while loop looks good. The while loop is left suddenly and the ESP32 is blinking. The argument with VSC/serial monitoring was not the right way, although it looked like this at first.
Learning:
<reading and writing to Grbl>
client.stop();
delay(5000);
Log.verbose("Before while loop");
while (client.connected()) {
while (client.available()) {
Serial.write(client.read());
}
}
<blinkSeveralTimes>
The last code line can be reached only by a preliminary client.stop();
Current test loop (opening, sending, receiving, closing, ESP.restart) runs for couple of minutes, so this looks promising.
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
My setup is FluidNC3.2.8 with current WebUI.
I have another ESP32, connected via WiFi/Telnet to FluidNC, it´s programmed via Windows/PlatformIO/Arduino platform via serial. In parallel, the WebUI of FluidNC is open.
The issue is unreliable connections after reset. Once it´s established, it works perfect.
My simple question is, how can I establish a -reliable- socket connection to port 53 of the FluidNC WebUI (esp. by often interrupting/re-uploading a program)?
Current perception:
My program runs in a loop, I do CTRL-C regularly to do further programming. Added client.stop() after X sec. of inactivity from serial control console, but of no help sofar.
I´m aware of the single Telnet connection, maybe timing or releasing from client side is an issue? Or should I close the client-side connection in a different way?
To better understand my potential mistake, I wrote a test program with many log messages (-> Serial.print). Hope this gives an indicator how to establish a reliable connection better - thanks for any suggestions.