I just installed a new 6445 controller on my laser and getting it configured and operating went smooth I was up and running quickly. Drew a couple of simple shapes in lightburn and was able to use the start button in lightburn to run the files and they turned out great. Then I imported a DXF file, set the fill settings appropriately and hit the start button in lightburn and things started off fine, then within a couple of minutes the laser would jump around and burn a line in here, then move to a different location and burn another line. Then back to near where it left the original engraving and continue the engraving. after a couple of screwups I found that if I hit the send button in lightburn, then hit the play button on the actual laser controller the file would work just fine. I am connected via the USB cable supplied with the Ruida controller.
Any ideas on how I can get it to run properly directly from the software?
Iād recommend connecting to the laser with ethernet. USB seems shoddy, and USB itself has issues with cords longer than 15ft or so. That would eliminate any issue there. If you need to run USB though, try swapping out for a newer one.
I am a little confused by your description. Do you happen to have āFlood Fillā turned ON (green) for that layer that was jumping around? Please post a screen capture of the āCut Settings Editorā window for the layer that is causing this issue.
No, not using flood fill, just the standard fill. When it would screw up, it would move 15 inches away from where it should have been engraving, then move back to the engraving and continue. If I just send the file to the laser controller and hit the start button on the controller itself it would behave as expected, even if I hit send and then tried to use the start button in lightburn. My laptop doesnāt have an ethernet port, just usb.
What OS are you using? Have you tested the USB cable, used a known good one? Have you tried a different USB port on your computer? Are you plugged directly into the controller or are you using a USB hub of some sort?
For Windows, have a look at this:
For Macā¦has port lock solution. (ignore grbl part, not relevant):
What speed / other settings are you using? If itās dense or complex enough, and fast enough, Start wonāt keep up because the controller is doing too much all at once, and Send is more reliable in these cases, but I canāt say thatās happening here without a bit more info.
Would installing one of these solve the no ethernet port problem?
I had assumed that the file would transfer automatically when you hit the start button. So, I would even let the laptop go to sleep while the engraving was going. The USB cable I was using is the one included with the Ruida controller, I havenāt tried a different one yet.
The files I have been engraving are on the larger size, black and whites of military logos and such. Large, but for the most part simple.
Start simply streams the data as with simpler controllers (gcode types).
In my general experience itās always safer to send the file and then start. I know itās an extra step but with the Ruida is just plain safer. Itās what they are designed to do.
That being said, weāve got it on our list to add the option to send a file and immediately start it, as you thought the āStartā button would do. Would that work for you? There would be zero interaction with the Ruida directly. Hopefully we can have that in the next version.
@Blake itās safer because the controller has the entire file and is not reliant on the USB/Ethernet comms to get the data streaming realtime. It takes your computer out of the loop and lets the controller work basically as designed. With complex designsā¦ especially raster engraving, itās possible for LightBurn to be unable to keep up with streaming data if your USB/Ethernet connection is not running at optimal performance. Sending the file and running from the controller completely bypasses this issue. Same reason itās safer to 3D print from an SD card instead of tetheredā¦ Iāve had 3D prints screwed up because Windows decided that downloading updates was higher priority
Ruida doesnāt stream in the same way that GCode controllers do, at least, not exactly.
āStartā sends the job to the controller as a temporary file, and as soon as the controller has buffered a bit of it, it begins running the job. If the job is relatively complex, or the speed is fast, itās possible for the controller to get ahead of the data transmission, and have to pause to wait for more data, or worse, miss data packets because itās busy. If thereās an error in the transmission (pulled cable, dropped packet, out of memory, etc) youāve ruined your material.
āSendā uploads the job to the controller as a named file, and doesnāt run it while itās being received, so the controller isnāt doing two things at once, and if the transmit fails you just retry until it works, and still have your material.
