@jkwilborn @berainlb @ednisley, the Lightburn staff and anyone else for that matter that has taken the time to help me in the past. I originally found the beginner’s guide for LightBurn not realizing (or just being ignorant) that there is a much more comprehensive Users Guide. When I burned my first images with my new laser I knew I needed to find a new resource for settings because (obviously) CO2 is nothing like Diode. I found the full manual and I’ve taken it upon myself to read the thing in it’s entirety. I’m now realizing just how patient and helpful everyone has been when much of the info was there in the first place. I’d like to apologize and thank everyone for the help regardless. I wish I could tell people just how important it is to read this document beforehand which will make you much more well informed. I will say, it is nice to have the experience of over a year or so behind me because I can understand a lot more I believe when reading. Regardless, thanks again.
I’ve been a big advocate of the documentation for some time so glad it’s not just me. It’s very densely written. You’ll find that rereading sections after familiarity will bring additional insights.
I am using an M1 Mac on my Omtech CO2 with Ruida controller and have never been able to connect via USB as well. My solution was as follows:
Buy a cheap wifi repeater with an ether net port. Configure that repeater into bridge mode, and then move it out to the shop as close to the laser as possible. Connect to the laser’s ethernet port with a short cable. Configure the Ruida controller with a static IP address and appropriate subnet mask.
So, this is basically the same configuration as a lightburn bridge, but you’re not at the mercy of whether they’re in stock. I haven’t had any hiccups in communication in almost a year.
Hope this helps a little.
This is a perfectly viable solution but just for clarity, the architecture for the Bridge solution and this solution is quite a bit different. This solution is done purely at the network layer. The Bridge solution also includes an application component to this. There are pros and cons to each approach but the Bridge model is explicitly meant to address shortcomings of potential packet loss which is a weakness inherent in how Ruida controllers communicate.
I ran that configuration for quite a while … using a $12 router/bridge from Amazon. It had it problems with Ruida, no different than any Ethernet connection.
The stock issue was COVID related I’m sure… Not only less PI’s, but more expensive.
@berainlb is correct…
I had a couple of PI’s laying around. Lightburn makes the the PI image available at no cost. I burnt an sd card and I’m up on the Lightburn Bridge. It is more dependable than Ethernet.
I moved my Ethernet connection to the back left of the machine for the first bridge and it’s, were the PI’s Ethernet cable is attached currently… It doesn’t have to be short IMHO…
The internal goes through the cable routes in the electronics cabinet… at least twice the distance of the original just to the back connector.
Pre-bridge days…
Pick up a PI when they become available…
Good luck
Jack, what is the Pi doing, then, that the router/extender is not? Is it doing some buffering or the like?
I thought the basic goal was to wirelessly get Lightburn connected to the laser. The extender does that. If the bridge has extra functionality than that one thing, I would love to know what it is. Maybe I will also be waiting for them to come in stock 
I seem to have a problem seeing all of the responses before I go off and respond as well.
I just read @berainlb response. It seems that there is in fact extra functionality to the bridge. I’m not yet sure exactly what it is though.
How does packet loss express itself on the Ruida controller, or in the actual output of the laser? Are there missing elements of the engraving, or does everything just error out at the controller?
I’m not sure if extra functionality is the right way to describe it, at least not from a user perspective. You’re right that the end solutions function similarly from a user perspective. Both offer a wireless means of providing network capability on the Ruida. It’s the means by which that occurs which is different. The only meaningful difference at this time is that the Bridge will do so in a more robust way, with higher reliability.
In your case since you seem to be having a very reliable experience you’re not likely to gain much additional value just from that.
From a longer term perspective the LightBurn folks are planning to add camera capability to the Bridge which would allow for wireless cameras. But that’s a future function, not there today.
The Ruida doesn’t use TCP/IP to talk it uses UDP which is a low level communications protocol. Universal Datagram Packet (UDP) has none of the attributes that we expect from a tcp/ip connection.
UDP has no error handling, no error protocol. UDP does have crc check for it’s data, but no way to tell the user it failed.
It also has no re-ordering of the packet. If two packets take different paths (unlikely) over your network, the 2nd packet might arrive before the first and UDP handles them in the order they are received … Probably why it’s a static ip only device.
How/what Lightburns layer in the code does in actuality, I’m clueless, but it appears to make it more stable. I have less transfer failures with the Lightburn bridge than I did with the regular bridge.
Good luck
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.