Can you elaborate on this? I don’t see this behavior myself - if you could record a video and post it somewhere, or just post some screen caps to show what you mean? LightBurn’s window layout is recorded per-laser, stored when you quit and restored when you restart.
Regarding the material test not respecting the fill settings, which version of LightBurn are you using? The current release (1.3.01) works exactly as it should for me. The material test wizard was originally for galvo lasers, and ported to work with all others, so there were a few settings that were “held over” for a version or two, one of those being the individual lettering, but that’s been fixed for a while. (the code change was made on Sept 30th of last year)
Because it took about 4 months of reverse engineering to figure out the command set and reproduce it reliably, compared to GRBL / Smoothieware which are open source and fully documented.
It isn’t - it was coded from scratch, by me until about two years ago, because I wanted the functionality of RDWorks with better usability. I imitated the layout of RDWorks, and anything I felt they did decently.
If you’re only using it as a receiver for Corel data you won’t notice a massive amount of difference, but if you start actually using LightBurn for anything else, you’ll see it pretty quickly. Things like automatic welding of text, ability to use sub-layers, a far better image trace tool, hotkeys for everything, unlimited undo / redo, drag & drop support, etc, etc. RDWorks has improved a decent amount since LightBurn started, partly as a result of pressure from LightBurn’s existence.
LightBurn’s preview gives more accurate times, and the generated cut files typically run in less time (if you’re doing more than just simple engraving, at least) because our path planning is smarter. It also takes a LOT less time to generate those paths - sometimes a few seconds compared to minutes, if your files are complex enough.
It’s not just for cross platform compatibility - it also provides a decent amount of infrastructure for graphics rendering, controls and window layout, container objects, language translation (localization), network and serial port access helpers, and tons more.
Your guess would be wrong by about a factor of 5. Just shy of 16% of our users are on MacOS, and the number has been slowly increasing.
This is a shortcoming of the Ruida hardware, and not something we can do anything about unfortunately. The Ruida controller assumes perfect transfers, doesn’t even use checksums over USB, and uses UDP transfers for network, with a very simple checksum and no mechanism for retry. They’re made to be hard-wired, and I have no control over the protocol itself. This is why it also happens with RDWorks.
See above. Since the Ruida uses UDP, any interference or packet loss will result in a transfer failure. We created the LightBurn Bridge to address this exact problem - it uses TCP to communicate from the PC to the bridge, then a wired network connection from the bridge to the controller, so the connection is much more stable. If you have a compatible Pi laying around, the image files to make your own are free to download from our site.