I’ve started having issues with Lightburn communicating with our Bodor laser, with a Ruida controller.
I believe they’re firewall related, as bypassing the firewall resolves the issue, but I have also applied specific rules for lightburn.exe and SendUDP.exe to be allowed.
When sending a file to the laser, it starts the process, asks for a filename, will check and notify if it needs to be overwritten, and then fails the upload after a short time. If I bypass the firewall, this process completes without issue.
Interestingly, if I ‘start’ the exact same file instead of sending it to the machine, it starts immediately and completes the cut without issue.
Is there any other background processes, ports or helper applications that need access through the firewall for Lightburn to be happy?
There are two ports for Ruida controllers: The outgoing one, to the laser, is port 50200, and the incoming one, from the laser, is 40200. SendUDP only uses local host, and it’s only for triggering import of files from the Corel Macro or things like that - it’s not involved in talking to the laser, and there are no other ports that need access.
Ruida controllers use UDP, which isn’t guaranteed delivery, and packets can drop, so if the firewall is software, not hardware, and is at all sluggish, it’s possible that having it on means more dropped packets. Is the connection wired or wireless?
I’ll add exceptions for those ports and see if the situation improves. I’ve also found a post detailing the network timeout setting, so I’ve increased that a little to see if that assists as well.
Machine is on a wireless connection, and the firewall is a software firewall that has been very reliable in the past. I’ve used the machine successfully for the last 6 months or so, and this is a recent issue so I’m sure something has updated itself to break things, as is a long standing Windows tradition.
Do you have any guidance on why ‘start’ works immediately and without question, vs. ‘send’ failing? Is the ‘start’ method not requiring any talk back from the machine?
The packets are smaller with ‘Start’ - limited to 1000 bytes + checksum, and never break a command boundary. ‘Send’ sends 1472 bytes per packet and doesn’t worry about command splitting. It’s usually more robust to use Send than Start because the controller is only doing one thing - receiving the data, instead of that + running the job.
I honestly don’t know - your guess is as good as mine. The MTU for UDP is larger than for TCP, because it doesn’t have the 20 byte TCP frame header. I can’t imagine a firewall being dumb enough to mess that up.
Changing the MTU on the Wi-Fi connection to 1500 (up from 1492) seems to have immediately resolved it.
I think success after disabling the firewall might have been coincidence, because adjusting the MTU back and forth reliably reproduces/fixes the problem.
Thanks for your answers to guide me down the right path!