Connect ioSender to esp3d(telnet,websocket) to grblHal

[semos2k]

Hi, i connected board running esp3d to other board running GRBLHal STM32F407 when connect using ioSender not work telnet o websocket. when test lightburn works correctly is posible use ioSender using esp3d intermediate for use telnet or websocket ?

[phil-barrett]

I think you are trying to have the esp board act as a network to serial (usb?) adapter. If lightburn connects to the F407 board via the esp board then I would look at how the network connection from lightburn is being made. If lightburn is still running, then I would close it as that would prevent ioSender from connecting.

Also, could you post details on the esp3d board? hardware and software.

[terjeio]

when connect using ioSender not work

What is not working? ioSender fails to connect? Errors after connecting? ...?
AFAICT ESP3D acts as a bridge so should in principle work.

An alternative to ESP3D is ESP-AT, a grblHAL plugin has been made for that - configuration of it is done via regular grblHAL settings. It only supports Telnet and is still in an experimental state.

[semos2k]

Hi, erros after connecting, when view the console on iosender show 3 times the result of the command ? And next close the iosender due comunication errors

ESP-AT interesting option, thx

[semos2k]

i tested when esp3d open in the browser and closed the result is the same, the config

this is the exact error

and the output on esp3d

?

<Idle|MPos:0.000,0.000,0.000|Bf:100,1023|FS:0,0|Pn:P>

ok

<Idle|MPos:0.000,0.000,0.000|Bf:100,1023|FS:0,0|Pn:P|WCO:0.000,0.000,0.000|WCS:G54|A:|Sc:|MPG:0|H:0|T:0|TLR:0|Fan:0|FW:grblHAL>

<Idle|MPos:0.000,0.000,0.000|Bf:100,1023|FS:0,0|Pn:P>

<Idle|MPos:0.000,0.000,0.000|Bf:100,1023|FS:0,0|Pn:P|WCO:0.000,0.000,0.000|WCS:G54|A:|Sc:|MPG:0|H:0|T:0|TLR:0|Fan:0|FW:grblHAL>

<Idle|MPos:0.000,0.000,0.000|Bf:100,1023|FS:0,0|Pn:P>

<Idle|MPos:0.000,0.000,0.000|Bf:100,1023|FS:0,0|Pn:P|WCO:0.000,0.000,0.000|WCS:G54|A:|Sc:|MPG:0|H:0|T:0|TLR:0|Fan:0|FW:grblHAL>

<Idle|MPos:0.000,0.000,0.000|Bf:100,1023|FS:0,0|Pn:P|Fan:0>

<Idle|MPos:0.000,0.000,0.000|Bf:100,1023|FS:0,0|Pn:P>

<Idle|MPos:0.000,0.000,0.000|Bf:100,1023|FS:0,0|Pn:P|WCO:0.000,0.000,0.000|WCS:G54|A:|Sc:|MPG:0|H:0|T:0|TLR:0|Fan:0|FW:grblHAL>

<Idle|MPos:0.000,0.000,0.000|Bf:100,1023|FS:0,0|Pn:P>

<Idle|MPos:0.000,0.000,0.000|Bf:100,1023|FS:0,0|Pn:P>

<Idle|MPos:0.000,0.000,0.000|Bf:100,1023|FS:0,0|Pn:P>

<Idle|MPos:0.000,0.000,0.000|Bf:100,1023|FS:0,0|Pn:P>

<Idle|MPos:0.000,0.000,0.000|Bf:100,1023|FS:0,0|Pn:P|Ov:100,100,100>

<Idle|MPos:0.000,0.000,0.000|Bf:100,1023|FS:0,0|Pn:P>

<Idle|MPos:0.000,0.000,0.000|Bf:100,1023|FS:0,0|Pn:P>

<Idle|MPos:0.000,0.000,0.000|Bf:100,1023|FS:0,0|Pn:P>

<Idle|MPos:0.000,0.000,0.000|Bf:100,1023|FS:0,0|Pn:P>

<Idle|MPos:0.000,0.000,0.000|Bf:100,1023|FS:0,0|Pn:P|WCO:0.000,0.000,0.000>

<Idle|MPos:0.000,0.000,0.000|Bf:100,1023|FS:0,0|Pn:P>

[terjeio]

No, the corruption happens because ioSender expects CRLF line endings. When the CR is missing the last character in the string is chopped off instead of the expected CR.

What is more problematic is that the timeouts in ESP3D are far too long, e.g. the Telnet receive code waits for 1500 ms before processing a real-time character command. I fixed this by changing the isPrintableChar() method, which ensures it get processed immediately. This is just a quick workaround that happens to work with Grbl/grblHAL.

IMO the Telnet receive method should be changed in a similar way to what I have done on the receiveCb method? There I shorten the timeout delay to 1ms when a character has been received (should rather be two since the ms counter might be microseconds away from incrementing).

Shortening the timeout after something has been received could potentially be used to get rid of testing for LF and CR? Instead use timeouts and buffer full events to decide when to forward received data for processing? This way it might be possible to make the bridge 100% transparent - which it ideally should be.

[luc-github]

I strip crlf because some firmware need / send only \r or \n , so a \r\n do ok twice for one command

Yes indeed telnet (or any input) does not check if char is a realtime command char, that is a problem - I will had the support, so flush will be immediate if grbl/grblHAL - realtime command should not have a timeout

I will add also \r\n as endline on telnet output, it was set in ESP3D 2.1 but I see it is missing in 3.0, and I may add it as an option for all outputs actually for consistency

the corruption happens because ioSender expects CRLF line endings

@terjeio May I know why you are so strict ? is there some reason (standard /rfc) ? others programs are ok with only \n, e.g: lightburn is working well

@semos2k please open issue on https://github.com/luc-github/ESP3D for this topic - I will work on it tomorrow, it late for me now

[terjeio]

I strip crlf because some firmware need / send only \r or \n , so a \r\n do ok twice for one command

IMO that is not something you should be concerned about. If it is an issue either the original receiver or sender should be fixed to handle it. If your code is required to fix line endings for them perhaps this should be a configurable option?

May I know why you are so strict ?

I coded ioSender for what Grbl (and grblHAL and other ports I know about) use as end-of-line termination, simple as that. It may even be part of the original Grbl specification.

BTW there is another potentional issue with the bridge, the grblHAL SD-card plugin supports 8-bit YModem file transfers. Beeing 8-bit it requires the communication channel to pass data unmodified, IIRC even the 0x0 C string terminator. So any man-in-the-middle code has to pass data unmodified for it to work. Reminds me I have to check that the ESP-AT plugin handles this...

[luc-github]

I just did a request to claude ai and answer is mixed :

Here's a complete overview of line endings in different CNC and 3D printing firmwares:
3D Printing Firmwares:

Marlin Firmware:


Accepts both \n and \r\n
Most slicers default to \n with Marlin
Very tolerant of mixed line endings


RepRap Firmware (RRF):


Accepts both formats
Generally prefers \n
Good compatibility with mixed files


Klipper:


Primarily uses \n
Very tolerant of different formats
Can handle mixed line endings


Prusa Firmware (Marlin-based):


Like Marlin, accepts both formats
Configured by default for \n
Good compatibility


Smoothieware:


Accepts both formats
More commonly used with \n
Generally forgiving with format

CNC Firmwares:

GRBL:


Primarily accepts \n (LF)
Can handle \r\n (CRLF)
Usually doesn't handle lone \r well
GRBL HAL (ARM version): same behavior


TinyG/g2core:


Prefers \n
Tolerates \r\n
More flexible in interpretation


LinuxCNC:


Primarily uses \n
Unix/Linux line ending compatible
Less tolerant of Windows endings


Mach3/Mach4:


Accepts \r\n (Windows format)
Can handle \n
Windows-centric by default


UCCNC:


Windows format \r\n by default
Can interpret \n
Less flexible than 3D printer firmwares

Key Differences:

3D printer firmwares are generally more tolerant of mixed line endings
CNC firmwares tend to be stricter about line ending format
Industrial CNC systems often prefer specific formats due to their industrial heritage
Most modern CAM software will automatically output the correct format for the target machine

These line endings are critical for proper command interpretation and execution in both CNC and 3D printing applications.

BTW there is another potentional issue with the bridge, the grblHAL SD-card plugin supports 8-bit YModem file transfers. Beeing 8-bit it requires the communication channel to pass data unmodified, IIRC even the 0x0 C string terminator. So any man-in-the-middle code has to pass data unmodified for it to work. Reminds me I have to check that the ESP-AT plugin handles this...

Indeed currently ESP3D only support Text base GCODE - binary GCODE like repetier GCODE is not supported - I have to add support in future version , because ESP3D is not only a bridge it also handle [ESPXXX] commands, nothing is impossible but was not requested until now

[terjeio]

GRBL:

Primarily accepts \n (LF)
Can handle \r\n (CRLF)
Usually doesn't handle lone \r well
GRBL HAL (ARM version): same behavior

The official Grbl 0.9 and 1.1 (and I assume 1.0) does not handle CRLF (or LFCR) as a single line terminator, it will output an extraneous 'ok' if received. CR and LF are both treated as valid line terminators. "Usually doesn't handle lone \r well" must be some port(s) misbehaving or Claude AI making it up. ioSender sends CR as the terminator.

grblHAL after build 20181022 (since 5 years ago) interprets CR, LF, CRLF and LFCR as a single line terminator. And from even longer back the stream subsystem supports the full 8-bit range, including 0x0. Same for non ARM grblHAL drivers (ESP32, MSP430F5529).

BTW output from Grbl and grblHAL is always terminated with CRLF.

Indeed currently ESP3D only support Text base GCODE - binary GCODE like repetier GCODE is not supported - I have to add support in future version , because ESP3D is not only a bridge it also handle [ESPXXX] commands, nothing is impossible but was not requested until now

Yes, binary is a bit harder to code for since data length has to be passed with the data, but as you say not impossible.

[phil-barrett]

I strip crlf because some firmware need / send only \r or \n , so a \r\n do ok twice for one command

IMO that is not something you should be concerned about. If it is an issue either the original receiver or sender should be fixed to handle it. If your code is required to fix line endings for them perhaps this should be a configurable option?

I agree with Terje. The key point here is that a bridge needs to be transparent. It is just a "wire" connecting 2 devices. There may be cases where translation is needed but that should be explicitly called out and require an option for the user to select. Anything else is just asking for trouble (as we see in this thread).

[luc-github]

As mentionned ESP3D is not only a bridge but also has direct commands and currently [ESPXXX] only respond with \n not \r\n so all ESP3D commands responses will be troncated as well

If only need single wire bridge between 2 FW - ESP3D is really an overkill solution

As I wrote I will work on supporting \r\n for the bridge part, just removing \r translation should be ok, and also fix the lack of realtime command support - but for the [ESP3D]command response format it is different, I need to think about it

[semos2k]

Hello, I hope you forgive my delay, the code modified by @terjeio works correctly, I will proceed to open the case directly in esp3d. Thank you for your time, I only have one question left, I close this conversation?

luc-github/ESP3D#1065

[semos2k]

Original ESP3D code include the implementation and work very well, thx for your time.