Improving file transfer?

Is there a good way of starting up to increases the changes of file transfer ?

ruida 644 m windows pro 10x64, ethernet connection, lightworks 9.20

turning on laser, waiting for it to init +30 seconds
run light burn (no other copy of lightburn running in the background, no rdworks install )
hit transfer, it shows the transfer progress then a few seconds after the progress bar/window disappears it’ll show a failure. sometimes if i retry it a few times it’ll work, other times it’s shut everything down and restart and it’ll work 2 out of 3 times most of the time, then others it takes a half dozen times
doesn’t matter if its a large or small file.
i’ve checked and rechecked the ethernet connection, sub 1ms, no packet loss
i’ve tried deleting any files on the controller first, making sure nothing is loaded into the controller, different file loaded into the controller but nothing seems to be consistent anymore.
tried a fresh win 10 install

You haven’t said if it’s wired or wireless. If it’s wireless, that’s most likely your issue.

You can try increasing the network timeout value in Edit > Device Settings. I think I default it to 5 seconds, but you can try 7 to 10 seconds to see if it improves.

it’s wired. pc and laser connected to same switch. no packet loss and sub 1ms round trip transport times.

i’ll try the timeout .

increasing the timeout just makes it take longer to fail :slight_smile:

added fw info if that is helpfile

Controller Status Info

Total ‘on’ time (HH:MM:SS): 58:59:00
Total job processing time (HH:MM:SS): 19:42:12
Previous job processing time (HH:MM:SS.msec): 0:09:07.136
Total 'job ‘laser on’ time (HH:MM:SS): 13:06:11
Total job count: 320
X Total travel (M): 6088
Y Total travel (M): 535
Mainboard firmware version: RDLC-V8.00.65


I’m having the same issue. I’m lucky if I hit 50% success rate on printing directly to controller. I have a 60w Chinese laser with Ruida controller. It doesn’t matter the size of the file. Small or big it’s still doing the same thing. I’m on a win 8.1 machine with LB 9.2. I’m sending files over ethernet connection. Same scenario (it shows the transfer progress then a few seconds after the progress bar/window disappears it’ll show a failure. sometimes if i retry it a few times it’ll work…it’s random) If I reboot Lightburn it seems to cooperate for a couple file transfers and then the same thing happens again. I’ve deleted files from controller and rechecked the ethernet connection. If I refresh the devices button I get a good connection to the machine but the file transfer still fails. I’ve also increased the timeout value to no avail (this just delays the failure prompt)


Try bypassing the short extension that connects the Ruida controller to the exterior plug on the case, and just plug the cable into the Ruida box itself. Those occasionally fail, and they’re usually not great quality parts anyway. Connecting straight to the controller itself will at least eliminate that as a cause.

happy to do that , but if that was the case i would see likely see failures testing the controller , i don’t get any packet loss no matter what i throw at it.

would it be helpful to try rdworks as a baseline? i 've always used lightburn with this laser.

What do you mean by “don’t get any packet loss” - how are you testing that? If you’re just using ping that’s not really a valid test because the packets will be sparse, and there’s not much payload. You can try RDWorks - there’s no harm in running some tests with that.

You could also try bypassing the switch itself and just running the cable direct to the laser.

what i mean is that you can set the (payload)packet size of a ping so even though the data is sent at larger intervals and default is a smaller chunk, you can override it and its a verified packet of data, so if i had a hardware fault it’s very likely i’d see an error after 10+ minutes of doing that.

i also used psping which has a fast ping mode, and sends data much faster, neither fast ping, larger packet sizes or length of time showed any loss.

PsPing test has now been running for about 30 minutes with zero loss.

I tried RDWorks V8 was able to send a RLD file that was 725K 10 times in a row with no failures, tried powering up and down the laser while RD was still running, no issues transferring, started RDWorks before switching on the laser and was still able to transfer, I’ve almost always had to boot up the laser first before using lightburn or it’d always fail first transfer

I’m more than happy to try reconfiguring the ethernet to a direct link if its a useful test for you.

An RLD file has next to no relationship with the size of the data sent to the laser. Click ‘Save as UFile’ to see the size of the data that will be sent to the machine.

The reason you have to connect the way you do with LightBurn is that it leaves the channel to the machine open, and only does the initial connection when you start, or when you right-click the ‘Devices’ button. You can power cycle the laser then right-click the Devices button and you’ll see ‘Found RDC 644xG’ or similar in the status window at the bottom.

The next release of LightBurn is going to change that, and use temporary connections instead, so that won’t be an issue in the future.

I made sure to use an RLD with more data in it than any of the files I’d been using, though amount of doesn’t seem to matter. it’ll fail with a single rectangle

I used this RLD seems to be around 61KB using the Ufile which saved as an .rd file.

Can you double check the model number of the controller? You said 644M, but as far as I can tell that doesn’t exist.

apologies, RDC6442G-B (EC) is the model number of the internal interface.

HMI V4.50.02

I also used windows inbuilt packet capture to grab a trace of a failed transfer, if that’s helpful etl/pcapng available.

Email them to with a link to this thread and I can have a look. It would be good to do the same for one of the successful transfers from RDWorks so I can look for differences.

will do, i’ll send over the LB ones, it worked once, then failed.

then i’ll do RDWorks again as i already i removed it.


i’ve sent over three traces one failed from LB, one passed, and one pass from RDWorks. also the files i used for rd and lb software.