This question has been asked before with absolutely no response, not even a “No Way”. To be honest, it is a bit frustrating.
When setting up LB for a grblHAL controller, I select Grbl and the only connection option is USB/Serial. grblHAL supports an Ethernet connection. I believe Duet3 does too. Other Grbl variants use WiFi so there are a number of capable devices out there. Ethernet and WiFi connections are much more EMI resilient than USB so there is a real benefit to the customer.
I know that other Laser Controllers with Ethernet ARE supported by LB so why not Grbl? The grblHAL connection can be via Telnet or Web Sockets, FWIW.
I was able to use a network virtualizer (Redirect Serial to Telnet - COM Port Redirector) to create a virtual serial to telnet connection. LB was able to talk to the grblHAL board that way. So, it is possible to do. The ap icosts more than LB and is somewhat clumsy to configure. There are a number of other aps that do similar but I wasn’t able to find a free one.
I get this question from my customers on a fairly regular basis so there is some demand.
The only controllers we support over any sort of network connection at the moment are DSP controllers like Ruida and Trocen. One of the major distinctions between those controllers and gcode controllers like grbl, however, is that typically when you send a job it still sends the entire job to the controller, where it is stored in flash memory, and run from there. In some cases the job actually starts running before the transfer is complete, but it’s still being run from the controller.
Whereas gcode controllers need to have the job continuously streamed to them which introduces a host of complications. We’ve actually attempted it in the past with Smoothieware and it’s telnet support but the performance was abysmal for anything other than jogging the machine. And, whereas DSP controllers have had network connections for years, gcode controllers have only more recently started to not only support network support but also have enough processing power to actually take advantage of it and not be terrible.
I’m personally very interested in using grblHAL (especially with the Teensy 4.x boards) but have not gotten my hands on one yet to try out. And that’s the other issue at play here - we want to support it now that it’s more common, but we need to get that hardware in hand and take the time to implement those connections/protocols. From what I’ve seen there’s several different implementations of how the connections are handled - there isn’t as much of a standard as there is with the DSP controllers just yet.
Also, until just the past month, we’ve only had 2 developers working on LightBurn - but this week dev #4 has joined the team so hopefully things like this will go faster in the future. I can’t say for sure if or when such support will be added as we’ve got a long list and we need to prioritize. It would greatly help us to do so if you would submit a feature request on fider, which is how we track such things:
There are currently no requests for grblHAL ethernet support on there, but I’m sure that many more will be happy to add their vote once you’ve added that request.