There was a problem sending data to the laser

UDP doesn’t have any sort of handshaking or acknowledgement that packets were sent or received. It just spits the info out, and hopefully it gets where it needs to get. There’s a higher chance you’ll lose packets or ‘not get’ them.

2 Likes

Haha, probably would have needed a wink to get it… :stuck_out_tongue:

I wrote that at something like 1:30 am just as I was about to pass out. The wink was an afterthought.

I’m glad you got it… maybe?

UDP packet bar walks a into.

There are a lot of these. (UDP packets are not guaranteed to arrive in order, or even arrive at all)

Google UDP joke or TCP joke and you’ll find lots. Some of them are even funny. :slight_smile:

And because we always have to make it meta:

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:

//pedant

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.