I ended up not using the software I bought because of lack of support. Installed fine, connected fine, but there is no arc support, no spline support, no way to disable the G0 commands, and no way to have feed rates on G0 commands. Basically, there’s no Marlin support unless you modify the G code file…and even then the lack of G2/G3/G5 means that the serial buffer runs dry from all the tiny G1 moves.
To the OP…you can install Win10 in a virtual machine and forward the USB device to it. If the VM software you use won’t forward a USB port then I think you can still generate a G-code file and then use something like Pronterface to send it to the machine. Certainly not as good as native support but at least it works and you don’t have to worry that your next update will break everything.
So it did’n meet your requirements. Did you not find that out during the 90 day trial period? I would love 3 months free trial on a car before I bought it.
I’m guessing you didn’t ask. Marlin foolishly requires a feed rate for G0 moves, unlike any other GCode controller on the planet, so you need to supply a value for the G0 speed in the ‘Fast Whitespace’ field in the device settings. That’s the speed used for G0 moves.
You are correct that LightBurn doesn’t support G2/G3/G5 moves, but nothing else has issues with this, and most controllers internally convert those into piecewise linear segments anyway.
I posted a FR that got no reply, then found others having the same issue including a guy that wrote a script to fix the output file. The note about marlin isn’t in the program description of fast whitespace scan. But even if it was, it wouldn’t fix the problem since it uses the same speed for x&y as for z, so I’d still need to modify the g-code to stop it trying to move the bed at the same speed as the head.
Internally converting doesn’t help with the serial buffer running out. Probably works fine with a 5w diode laser running at amazingly low speeds but with a CO2 laser it needs to move fast and the EMI means running at 250K is simply not stable. Some commands get corrupted and do nothing, others get corrupted and do things you don’t want them to. 115200 is the minimum but even then you get occasional issues so I had to drop down to 57600. Meatpack might help but I could not find a setting to turn that on either. I tried using an SD card plugged right into the controller board (not a great solution since I had to disable the display to do that) and it still wasn’t fast enough on rounded corners (it was a lot better but they were still deeper); I am not sure of the speed of this but I believe it’s faster than 250k. 57600 serial was fast enough when I wrote a test cut using G3.
i made these today on an S9 on Ubuntu installed on a old desktop (approching 25 years!) ). The same machine also runs my Sainsmart 3018 Prover at the same time. It was indeed tricky to set up but I had limited memory (my desktop has the same issue) and my screen isn’t totally compatible. But hey it works!
Keep trying… ask questions…
If you set the Z axis rate limits in the firmware the software would not be allowed to exceed them, no matter what speed we request.
What speed are you running the machine? I could pretty quickly tell you if you’re exceeding the bandwidth rate of the connection, or something else is happening.
57600 is about 5 kilobytes of data per second which is quite a bit. I generated a 120 x 90mm rectangle with 32mm radius corners, and set the system to an output tolerance of 0.03mm (which is much higher than necessary). The total file was 5.4kb, and at 100mm/sec that will take just under 4 seconds to run.
Dropping the output curve tolerance to 0.05mm (the recommended setting), the file size drops to 4.2kb, so I’d be surprised if data rate was the issue.
I’ve taken the liberty of moving this content into it’s own thread in the Marlin section as it’s drifted pretty far from the original license hurdle and Linux woes that the OP was experiencing.
