There was a problem sending data to the laser

As reported via PM, I recently ran a bunch of work through for some Christmas ornaments (from a MAC with various layers turned off and also a few runs with “Cut Selected”) and experienced zero issues. This is a pretty darn funny (not funny ha ha) problem. Again, if I see it rear it’s ugly head again, I will at least try to capture some of the Ethernet traffic to the controller and forward it on to you. I installed WireShark on my MAC just in case.

I’m not so sure in my case.

I used the cut selected graphics feature all the time and have done for a while without this issue.

For example on a design where I want to maximise material usage but the customers order may change the design slightly I can drop the item into position on a piece of stock that’s been used exclusively for this design (it’s a massively useful feature). This is what I did last Xmas hundreds of times without the issue I’ve had recently (all over wifi).

I think I might try downloading the file each time I cut a selected graphic to see what happens and also try an Ethernet connection to my Mac.

I’ll have a play about.

If I can work out how to use wireshark I’ll do the same as it’s fairly consistent for me.

There are some pretty good into videos on YT that can get you started with WireShark. You just don’t want to keep it running (capturing) for too long because it captures a LOT of data.

Hello I have had this problem a few times in the past and today I also did a rather large file and my last function was to cut out. When I clicked on the start job I also got the message and there seems to be nothing that will make it accept the job??? I am using a Ruida controller. I could go into more detail but I am wondering if there has been anything found with this problem? I don’t want to move anything or change my laser position in an attempt to save the work?

I am not sure I understand what you are saying here as you have used a bunch of question marks to end your wording. I don’t know if you are really asking a question or making a statement but added the question mark for…well I don’t know. :slight_smile:

What is the exact message you are referencing? Are you saying you sent the job to the controller and got an error message? If so, how? In LightBurn, did you use the ‘Send’ or ‘Start’ button, or did you use the ‘Save RD file’? All are available ways to get your job to the laser.

Your controller may be full, no more internal storage available and needs to have some files deleted to provide room for this new job. Could this be what you are inquiring about?

Are you saying that the job was running and stopped? Are you asking if you can re-start a stopped job?

I had finished engraving and was doing my cut next. So I changed heights on the table and of course the cut was on a different colour and thus different layer. Then when I tried cutting got the message of “problem sending data to the laser”

Don

You can right-click the ‘Device’ button in the lower-left of the ‘Laser’ window to re-establish communication with the controller.

image

Sorry for the confusion. I send the job from my computer via usb cable by pressing the start button, I do not use the 'Save RD file. Probably good advice to check and delete the files in the controller. I did wait about 30 minutes and it sent the file and finished the cut.

Thanks Rick
I will try that next time it happens. I had read the thread and could not find the device button. A picture is worth the 1000 words. Thanks for the help

1 Like

I get a similar error (about 1/5 tries) while sending files to Ruida controller over wifi: “File transfer failed” and then:

image

It does not take 5 seconds to fail so I don’t believe it is timing out really.

Anyway, I had a look in Wireshark. For every packet the computer sends to the laser, the laser sends back two. First a packet with one byte: 0xc6, and then a packet with a number of bytes. When it fails it seems that the laser only sends the 0xc6 packet and not the second one.

Not sure how to proceed, but maybe someone gets an idea.

It’s not super important for my workflow, but a bit annoying. I have the same issue when using RDWorks, which tells me that the problem is on the laser machine side.

Not that I would know what I am looking at, but a screen shot of the screen showing the packets flowing both from your computer and from the controller would likely provide a wealth of information to the developers.

You’re using WiFi, and the controller uses UDP, so that’s not a great combination. UDP does not guarantee packet delivery, and packet drops are much more likely over WiFi compared to a wired connection. TCP has built in, protocol level retries and error detection, UDP does not, so if a packet drops, that’s it - it’s gone, transfer failed.

I’m not sure why they chose this over TCP, but I suspect they’ve kludged their own network protocol into the system instead of using an off-the-shelf solution, which would also explain the lack of DHCP, and the fixed return port instead of using the same one as the sender.

1 Like

All things being equal, a simple test would be to run both devices off a common switch (the one on the router would suffice). Then, at least you could narrow it down to your wireless connection. I have a pretty complex wifi set up at home (wifi router, 2 switches and 2 wifi repeaters) and when I was having these issues, the first thing I tried was to directly connect my laptop to the switch the Ruida was connected to. DIdn’t help any but at least I was sure wifi wasn’t the problem. In any event, I haven’t seen this since I first reported the problem so …

I was thinking that a trace of the filtered data would at least enable the developers to see what is going back and forth not necessarily what might be lost in transmission.

It seems that my problem is wifi related. The machine I use is shared, so it is used by different computers. So depending on computer it could work pretty reliable or not at all. Connecting the worst computer to the network via cable eliminates the problem. The machine is now also connected with wire to the network.

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

I could tell you more about the issues with UDP, but I’m not sure you’d get it.

I’m pretty sure I would get it. I do develop electronics and software, both firmware and desktop as a trade. It’s just that I never had to use UDP for anything. I guess it’s still good for low latency or something. :grinning:

You didn’t get it.

Okay, probably a joke then. Please tell. :slight_smile: