There are some transmission problems between LB and my Laser. It seems to be getting more frequent with the error messages. Typically I can just repeat “start” and the file is sent but other times it takes several times before it works.
My KT332N is almost empty in memory, (there is only the original test file from OMT in memory.)
I run mixed LAN/WLAN and it seems like there is no difference in it.
Anyone who has experience with KT332N and knows a trick?
That error never happened on my machine until the advent of the LB 2.0 rewrite, which apparently changed something in the network communications stack.
It is now an occasional, but rare, occurrance, so I have no way to create a credible error report.
That’s a good question and I haven’t tried it at all.
During the day I will test if a USB connection behaves differently.
I will also test if it is an OS specific problem and if a wired connection from PC to laser (on Win PC) behaves differently.
On my MBP’s I only have Wifi to router/Kt332N connection, but because it has not been a problem in the past and the rest of my network/LAN connection in the entire building works flawlessly, I assume that the problem is either the controller or the software.
I will test and report back.
PS. at first it happened once or twice on a production day, now it is approx. 20-35% of all jobs (not documented but felt) and rarely I have to turn off and start the laser down to be able to start a job without problems for a short time.
I had 3 hours of production this morning, started up with LAN connection and got the error message after about 30 minutes. Then I switched to USB connection and for the remaining 2 and a half hours there were no transmission errors - messages/stops.
The rest of the day I will use the USB connection and see if there are any error messages here or not.
The Windows experiment will have to wait a bit, I am (fortunately) a bit busy with orders.
Are you using a Bridge to connect to the Kt322N? Otherwise your connection will be UDP and that can have losses. Using a Bridge prevents this sort of issue.
I use “Ethernet or Wifi/UDP”, the laser is connected to a switch and connected directly to the laser with static IP.
MBP uses standard Wifi LAN connection.
The problem is not something I’ve always had, but I can’t say from which LB version it started causing problems. I’m not claiming that LB is to blame, just that it’s a “new” problem I’m having.
I don’t understand how a bridge could help in the manor you describe. The bridge shouldn’t be adding anything to the packet only translating one side of the bridge to the other for an address.
Here on the left is a TCP packet structure, on the right a UDP packet structure.
There is substantial difference, so the router/bridge couldn’t know some of this information with only a UDP packet.
Ignoring that, the UDP Packet must be created by Lightburn and the destination also expects UDP, there is not any error control.
UDP is a
Connectionless protocol, meaning it sends packets without establishing a connection.
Great for applications where speed makes a difference because there is much less overhead.
Does not guarantee delivery, ordering, or error correction.
Subset of TCP/IP communications.
There should be no difference, with the exception of the Lightburn Raspberry PI bridge. I has a layer that’s supposed to help with getting data to the Ruida. I’ve questioned what it does, but I haven’t heard an explanation of what this layer does.
I’ve run my thought two PI’s and when they fail I drag out the $12 TP-Link bridge and use that. Pi’s got too expensive. Can’t really say I can tell a difference.
You must have an N model, the G model is USB only. I looked in the manual and it doesn’t specify speeds for Ethernet, but it states it uses USB2.0 which limits to about 40mb/s compared to Ethernet at about 100mb/s (from my 6442g manual).
Maybe I have the protocol screwed up and @Colin can clarify.
First of all, thanks for providing some qualified input.
It is the N model of a “Ruida” and its LAN connection is significantly faster than its USB connection. However, it is only noticeable when sending the Start signal, here with USB there is a (felt) 3 sec. delay which becomes longer when sending larger jobs.
I can certainly live with the fact that after 5 years of LAN connection use without problems, I now suddenly have to switch to USB to be able to use the machine and the program normally, but that is definitely not OK.
If I were alone with the problem then I would not have even written about it, but others experience the same thing…
In contrast to @bernd.dk’s topology, my laser has a wired Ethernet connection: a Win 11 Mini-PC and KT332N controller to a TP-Link 8-port gigabit switch with the shortest possible cables. It’s an unmanaged switch, so all it does is send packets to the port with the appropriate IP address.
Given the recent uptick in kvetches starting “My laser is always busy …” and “There was a problem sending data …”, whatever changed for the worse seems to live above the basic network / USB layer.
As far as I know a switch sends the data to all ports. When the device can select a port, that’s usually a router that tracks where the data goes and does not send any data out a port if there is no device there.
A router, routes the signal, an unmanaged switch just allows more connections to the same Ethernet line.
Unmanaged switches are just dumb devices as far as I know. Do you know differently?