There was a problem sending data to the laser

It’s just that I never had to use UDP for anything. I guess it’s still good for low latency or something.

You use UDP thousands of times a day. Hundreds of thousands or millions if you use VoIP. :wink:

UDP doesn’t have any sort of handshaking or acknowledgement {…} There’s a higher chance you’ll lose packets or ‘not get’ them.

There’s the same odds you’ll get (or not get) TCP or UDP. TCP just knows there is a problem and tries again (which has the same odds, …). And, the retries aren’t the same packet. They are new packets with the same payload. :wink:


I wish they didn’t use UDP, seems like a bad match for this kind of use case.

There is nothing inherently wrong with UDP. The application could use its own error detection/recovery. TCP just does the work automatically for you.

UDP is considerably lighter to implement, which is my guess as to why they’ve done it, but their implementation is really minimal - No sequence numbers, so they have to ACK each single packet, and that means ping time per packet, instead of using a tracking queue and re-sequencing on the target if necessary. It’d be slightly messy to write, but not terrible, and they’d get double the speed easily. Even a basic retry mechanism would’ve been simple enough, so I’m not sure why they didn’t do it. Most people are happy with the USB connection, I guess.

1 Like

Did anyone ever find a solution to this problem? I am connected through USB and I am running the same file every 15 minutes and I keep getting this problem. When I try to get Lightburn to find my laser again it just shuts Lightburn down. Running macOS Catalins version 10.15.2

You only ever have to have LightBurn find your laser once. Doing that again doesn’t work because you’re already connected to it. (It’s like trying to call yourself on the phone)

USB connection on a Mac is a totally different issue - Ruida uses an FTDI device for the serial/USB connection, and the serial port driver that Apple ships with MacOS interferes with the FTDI driver. You can watch how to fix the USB / Mac port thing here:

I will watch it. Just to clarify I have a ruidia controller on a Boss Laser, this fix will take care of this for me?

Yes. You could also just switch to using a wired network connection instead of USB - that would also work.

Trying to find a video on how to do that but no luck so far. I did the first thing and that didn’t fix it. Any ideas on where I can find instructions on how to connect by ethernet? Thanks

So what could cause an issue like this to start happening having previously used WiFi with the same files without issue for months and months?

Update to router or WiFi mesh devices? Os update? Interference?

Using a cable isn’t an issue for me as I’m right next to the laser but it was just easier for me to use WiFi.

I’m certainly no expert in any of this stuff but when I see an issue I always look for a solution.

WiFi is shared bandwidth, so unless you’re in the middle of nowhere, someone else installing a new router or extender, a wireless phone, or even a kid’s remote controlled airplane can all share the same bandwidth and cause interference.

So that’s what is causing this issue with the lost packets?

Possibly, yes. WiFi is not a stable transmission medium, and Ruida aren’t really meant to work that way.

It’s kind of funny that our laser was marketed as having “wifi control” and a large wifi logo on it:

But I guess we get what we pay for. At least a lot of laser for the money. :slight_smile:

It works well enough if the environment isn’t noisy (WiFi noisy, I mean). I run my MacBook with WiFi to my router, and have the laser wired to the router, and I almost never have an issue, but if you’re in an dense urban environment with a lot of other signals, or concrete / steel walls, you’ll have more trouble. If you use ‘Send’ instead of ‘Start’, if it does fail, it’ll do so before the job actually begins and you’ll be able to try again without ruining material.

I’ve improved the handling of this slightly - The laser will now continue to respond properly after the transfer fails. There was a missing command to tell the controller that the file transfer is complete. I send that as part of the file itself, but if the file doesn’t finish, the controller will sit & wait for the rest of the data, and it never arrives. This fixes the issue with subsequent failures - you don’t have to reconnect any more.

Having said that, it is a WiFi issue. I reproduced the problem with RDWorks as well as LightBurn, with and without my traffic analyzer in the mix, and it’s just dropped packets. The moment I plugged my PC into the network with a wire everything works. I’ll double check the implementation details for Trocen controllers too - I suspect they work the same.


I have a similar problem, but I only use USB connection and I have a win10.
When a laser finishes the project I cant repeat it from a software level. a ruida controller (644xs) responds correctly but a software is disconnected.I noticed that is less common if I wait a long time… for example, if I must change engraving material.
When I disconnecting a usb cable and reconnecting a lightburn works properly.

Check these:

Packet/USB - this solution doesn’t work in my case, a machine is disconnected with a lightburn.
However, I think it was similar in rd works, I do not remember exactly. Maybe this is problem with a Ruida controller… :confused: