Interesting.. bug? Increasing lines per inch breaks settings

[TeamADW (B Spiegel)]

So I was running a file, and something always bugged me about our Nova35. Never could get a great engraving out of it, just “ok” ones. One of my products this would show up on, and I decided to play around and see what we could do to fix it.

See that hood line? Its a solid outline in the file, but showed up segmented. Today, I started playing with settings to see what was going on. Eventyually, I got it to get better by increasing “lines per inch” and “line interval”. They typically go up together, but I found if you take interval down manually too far, LPI does not change.

But, try increasing the LPI to 600 or so… and bam.

The laser would shake like it was having a seizure, then start cutting out part of the vector data. Or just engrave parts of the raster layer. It was trying to engrave at 1060mm/s, which the servos just about died thinking of doing. After this, no matter of resetting the PC<,laser, or setting in Lightburn would fix it. Could not engrave, until I uninstalled, ran CCleaner, re-booted again, reinstalled, and then we got it running.

I decided that 500 LPI was the sweetspot for this design after, and just adjusting this setting kept it all happening fine. Not sure why, but it did this on 2 computers (my printer PC used to be the everything-in-the-shop PC, so installed on there still as backup) and happened on both.

Oh, @LightBurn, can I request a feature? Can we get a time estimate front and center, or is there a way to turn this on? I would love to see the estimate without the preview as I adjust settings. Helps with estimating job costs.

[LightBurn (Oz)]

@TeamADW

I would love to see the estimate without the preview as I adjust settings. Helps with estimating job costs.

Unfortunately computing the job time is really expensive because it requires doing all the work of generating the file to send to the laser, then simulating the execution of that job through a software based motion planner that’s attempting to mimic the logic in the controller.

Doing it continually as you made changes to the design would pretty much nuke the interactivity of the software if you were doing anything more than a simple job. You expect the preview to take 1/2 a second to pop up - you don’t expect moving the end point of one of your nodes to require the same 1/2 second.

Regarding your interval settings and the transfer error:

The line interval value is the one that the software uses internally. Changing the DPI setting will recompute an appropriate line interval, or vice versa - they’re the same number internally.

That buffer error you’re seeing is a result of overloading the CPU in your controller, because it can’t run your file at the speed requested and still have time left to receive the data, so it chokes. In this case, using ‘Send’ instead of ‘Start’ would have worked, because the controller only has to do one thing at a time.

[TeamADW (B Spiegel)]

Good to know on the send button solution, thanks. I’ll show my team that too (been having laser class!).

I was used to the calculation time on my old software, so I think Im used to the slight wait. Some of these new computers are spoiling me, after upgrading a few machines to 6 core Ryzen 3700s.

Which, I gotta ask, would it be beneficial for these operations where there is a complex file to utilize the GPU instead of the CPU? Or does it already. I didnt notice, but never timed anything on machines with better gpus or multiples (print ripping works better with a Quadro card, at least with roland) .

[TeamADW (B Spiegel)]

And yes, I know Im a strange case, because breaking software with large files tends to happen around here. Hit render, go have lunch

(I have the cad files for Washington DC’s street planning around here, nothing makes that open fast in cad… )

[LightBurn (Oz)]

So far LightBurn is almost entirely single-threaded, CPU only, with very few exceptions. There are a few things that could benefit from multi-core use, but not much that would be easy to move to the GPU.

I have a couple nasty vector files I use for speed testing, like this:

[raykholo (Ray Kholodovsky)]

@TeamADW

And yes, I know Im a strange case, because breaking software with large files tends to happen around here. Hit render, go have lunch

I was thinking about our map of Florida as I read this reply from you. Oz just replied with it. With other software packages it might be a hit render and leave for the weekend situation

I remember when it got sent in to us with “LightBurn is being slow with this file” - and yeah, there’s millions of segments, give it a moment. And then Oz made it even faster

[LightBurn (Oz)]

In LightBurn, that Florida file previews in just over a second if you’re only filling it. If you do ‘Line’ mode, with inner/outer sorting and travel moves reduced, it takes quite a bit longer - almost a minute to do the inner/outer sort, and another 6 mins to optimize the cut plan (7 mins, 5 sec total). At some point I’m going to try multi-threading the path planning code to see if I can cut that down some, but I still have a few other tricks to try.

If you break the file into groups of shapes, and set the system to order by groups, the cut planner goes a lot faster because it has fewer things to consider planning the cutting order.

Even just filling the file in RDWorks takes longer than I’ve ever been patient enough to wait.

This is from before the last round of optimizations - it’s actually a bit faster now:

Change a tire?

[TeamADW (B Spiegel)]

Im going to have to play with some things once I gt my main station back up and running. 1 month in, it blew up, literally while I was running nesting software. (Ive been playing with deepnest (dot) io )

A lot of what I do here is batches of parts, trying to get the most out of material, or get laser time down. In this case, I was trying to get that quality back, especially as we started to run out of back stock and have some popularity rising with these keychains.