Lightburn 1.7.04 trial version. Chinese laser with Ruida RDC6445G(EC) controller that is running firmware RDC-V15.01.34. It is connected to my network via TP-Link nano router TL-WR802N. Router is running in client mode and laser has it’s own IP assigned. There is no space issue on the controller since I already tried formatting the storage to resolve this issue.
From Lightburn I’m able to connect to the laser and everything used to work perfectly fine. But today when I try to send a file it started throwing an error “There was a problem sending data to the laser. The machine may be busy or paused”. I’ve done some testing and here’s the weird part - this error only happens if I send a line command to the laser. If I create a shape and choose fill then it sends without any issues. Also if I use “Start” command from Lightburn it sends it to the controller memory and starts the cut job without any issues. Oh and I’ve tried connecting to the controller with a USB cable directly and the issue is not there either.
The bug is only present when I connect via the network and the file contains line commands.
If so, the router may be assigning the same IP address to another device, in which case both the laser controller and the other device will respond. Hilarity rarely ensues.
If there’s any response when the laser is off, something else is using that address.
Because the DHCP addresses will vary, that test may work today and fail tomorrow. If you can test immediately after a failure, you may find the culprit.
I set up my router to assign the laser’s IP address to that specific MAC identifier, even though the Ruida controller does not make DHCP requests. That way, the router won’t assign that IP address to any other device.
My network is set up with a subnet 10.10.10.0 and mask of 255.255.254.0. DHCP range is 10.10.11.1-250. And I use static mapping by MAC address in the range of 10.10.10.1-250 for all of my known devices. On Ruida controller I set the address to 10.10.10.254 (because I’ve read that other thread from couple years ago saying that Ruida uses 255.255.255.0 as default mask) and I know nothing else on the network is using it.
During my setup I could not find a MAC address for the controller so I don’t actually have the mapping set up for it in the router.
Lightburn is able to talk to the laser on that IP. I can jog the head with move controls from Lighburn. I’m able to read the list of files that are already uploaded to the controller as well. I am able to “Run” the file from Lightburn and it starts the laser and does everything correctly. Only thing that is not working is “Sending” a compiled file that includes “Line” instructions.
It’s not what you know, but what the router knows, so let’s make sure everybody know the same facts. Run the ping test, just to be sure.
In a Windows command line: arp -a
In Linux: arp-scan -l
Then find the laser’s IP address in the list.
I need those so infrequently I gotta look 'em up every time.
A long discussion of how Ruida controllers do not conform to normal networking expectations, particularly with respect to subnet masking, may provide some insight:
AFAICT, the controller can’t handle anything more complex than a simple /24 subnet.
Since the problem only occurs with line commands over the network, it might be related to how those commands are being transmitted. Have you tried resetting your router or checking for firmware updates for both the router and the laser controller? Sometimes, network interruptions can cause issues with specific command types.
Router knows that Laser’s IP address is only used by the laser. Ping goes through when laser is on and doesn’t work when laser is off.
Excellent suggestion. No idea why I didn’t think to look in arp table before now. Looked through the arp tables and found the correct MAC address for the controller. Set up static mapping for the controller.
All of my static IPs are in 10.10.10.1-255 range. IPs that can be assigned by DHCP are in 10.10.11.1-255. Currently controller is assigned 10.10.10.254 IP and has static mapping with correct MAC address in place.
I have tried resetting the router and checked for new firmware. Router is running on the latest firmware. And as far as I know RDC-V15.01.34 is the highest firmware I’ve seen for RDC6445G controller.
AIUI, the data sent to the controller is essentially a binary rd file, with the Start function prefixing the stream with whatever command kicks off the job. One consequence is having the laser begin running while the rest of the file arrives and is buffered in a temporary area, which can sometimes cause problems with mysterious causes. Using Send stores the stream in a named file in the flash filesystem for later use, so there’s no contention.
That seems to be exactly the reverse of the situation you describe: Send stores the data correctly (and can be started from the machine panel), but Start simply refuses to send anything.
The network topology you describe has plenty of moving parts, so perhaps the whole mess has trouble with the handshake required to let LightBurn know the controller is still out there.
That would be data dependent, as relatively short jobs like your “line command” might fit into a single UDP packet, while longer “shapes” might require more packets with more opportunity for trouble.
Ruida controllers simply don’t employ a proper subnet for many networks. If you have a Class C network they will work fine. But for a Class A (Like 10.0.0.0), or Class B, or if you truly have a subnetted network, only a select few machines on the network will be able to communicate with the Ruida controller.
Basically, a Class C network (like 192.?.?.x) uses the first three octets to determine the network ID and the last octet to identify the host. Ruida is fine with this as it ALWAYS assumes a 255.255.255.0 subnet mask (which is STUPID BAD).
If you are running your Ruida controller on a Class A network with an address of 10.10.10.254 (for example), then the Ruida controller will always assume that the network ID is 10.10.10.0 (first three octets). This means that only hosts on your Class A network which share the same first three octets as 10.10.10 will be able to talk with the Ruida controller.
This is a Ruida problem which I was told (years ago) they know about. It is simply lazy programming on their part. I’m sure they are using some library-based TCP stack (they didn’t write their own from the ground up) and all they would need to do is allow the user to specify the appropriate subnet mask (instead of always assuming/applying 255.255.255.0 (/24).
I simply bought a little palm-sized, 2-port, $50 router, set up a single port-forward and NAT rule, and attached it to my laser so that all the clients on my Class-B network could talk to my laser. Now I just specify the IP address of my little router and everything works as it SHOULD. In effect I had to create a dummy Class-C network underneath my Class-B network just to work around the subnet FAIL with my Ruida controller. …and there is only a single host on that dummy Class-C network (My laser): https://forum.lightburnsoftware.com/t/anyone-know-has-the-ruida-firmware-ever-been-updated-to-fix-their-network-limitation/151129/9?u=evanevery
I can’t say for sure but I believe you will need to use the 24 bit ranges for your laser network. Set your subset mask to 255.255.255.0 for all devices in the network connected to the machine.
As I mentioned earlier, all of my known devices have static mapping in 10.10.10.1-255 range. When a new device joins the network it gets a 10.10.11.x IP assigned until I create a new static mapping. Ruida cntroller is set to 10.10.10.254 and computer with Lightburn is 10.10.10.64. So it’s not an issue with Ruida’s assumption of 255.255.255.0 mask.
A bunch more troubleshooting and testing yet I’m not any closer to a resolution. I think the issue is with the controller itself receiving data via the network. Both wired and wireless connections are exhibiting this issue while direct USB connection does not.
So in the end I decided to stop wasting my time on it, bought an active 10m USB cable, and now everything is working.
