Galvo runs MUCH slower in greyscale

LightBurn Software Questions
,
1

I was trying different settings for 3d relief engraving.

Took me way too long to realize this- when I send as Greyscale, it ends up running MUCH slower. Like 1/10th the speed. Same commanded speed and line interval as Sliced but 10x slower.

I know the power is being modulated down with shading content, but the cut is still much less brilliant than I expected. I think that just means that it’s not firing at the commanded freq anymore, but probably scaling the pulses back and delivering the intended pulses per mm.

What’s up here? It was awhile back, but IIRC when I had the EZCAD drivers installed and ran EZCAD, it didn’t do this.

2

You can do the math, but when you run grayscale, it changes power for every bit or at least could. Before it can lase, it may have to send power data…

3dslice works totally different and is designed for fiber lasers because the way grayscale works you have poor results, as you apparently found out.

Oz posted this when there was confusion over how the 3dslice works. Don’t know if you have access to the beta area, it’s there, but I’ll post it here for those that don’t have access.

With 3D Slice, each pass is thresholded to the current threshold value, and the result is run as a 1-bit image. If you use 256 passes you get exactly one pass per gray-level in the image. Every pixel at or below brightness 255 for the first pass, every pixel at or below 254, then 253, and so on.

If you choose 128 passes, you get every pixel at or below 254 for the first pass, then 252, then …

It “clusters” the layers together into batches if you use fewer than 256 passes, and will duplicate some layers (with even spacing) if you use more than 256. 384 passes would duplicate every 2nd layer. 512 passes would duplicate every layer.

Make sense?

He also stated in a post about 3dslice for diodes.

Diodes have extremely good power linearity, and you’re generally just engraving wood or plastic, so use ‘Grayscale’ mode - that’s what it’s for.

Grayscale mode does not work well for deep, consistent metal removal for galvos, so 3D slice was added for those machines. It was not “removed” for diodes and CO2 systems, as they already have the grayscale mode to accomplish this.

:smiley_cat:

3

I’m familiar why 3Dslice was created and how it works.

Actually, the BEST 3D relief sample I’ve made was under EZCAD before I got LB’s driver installed correctly. That would be using grayscale. I don’t recall how fast it actually ran.

I think I’m going to change back to EZCAD for a bit to compare.

I’m not sure how the system works. I’m often pulsing at 4MHz and running the head at 5000mm/s. I don’t think Lightburn tells the BJJCZ controller the power for every single pulse.

The other two options would be to communicate a new power target when the scan crosses a pixel boundary in the image, or a pixel boundary in the galvo controller’s coordinate space.

Hmm, how does that work? I think I read the BJJCZ has a 16 bit coordinate system, so 65536 across on the 100mm field of my lens, assuming the coords are for cartesian values on the focal plane rather than angular. That would be a 0.0015mm resolution. So that’s 3.2768 million pixels per second. I also note I asked for 4MHz repetition so it’s generating a pulse every 1.22 pixels in BJJCZ coord space.

But I don’t think it’s communicating like that. I think LB is updating whenever the scan crosses a pixel boundary. I think I gave it a 2048x2048 image, physically on a 20mm square. That would be 0.0097656mm per pixel. At 5000mm/s scan speed, that’s 512k pixels per second. And every pixel in the image gets 7.8 pulses.

I see that the data rate could be challenging. Or not? A data payload of 512k 8-bit data values per second would be 512kbaud=64 MBit, but how bits are packed makes a far larger number. But then USB3 is 5Gbit/sec so in theory there’s a whole lot of room for packing before the USB3 bandwidth becomes the limiting factor.

I’ll need to learn more about how the BJJCZ gets data to understand this and if this is a problem on LB’s size.

Well, just trying the “same thing” on EZCAD would be a useful reference, but I was very confused at what line interval it was actually using.

4

That may be the case, as @LightBurn pointed out near the end of a rather long-running thread:

Apparently the data rate runs right up against the hardware limitations, which may be much lower than the USB spec, and LightBurn was optimizing to the point where the hardware couldn’t keep up with the command rate.

Maybe I misunderstand the internals, but it sure seemed like the obvious symptoms did not match the actual problem.

5

Not optimizing, just that we don’t hand-hold in the same ways that EZCad does (or we didn’t).

I’ve matched the output of the commands sent by EZCad to control power, per pixel if necessary, and in the case posted by DialStudio above, he had sections of his images that contained long runs of exactly the same pixel value with a gradient on either side.

The gradient parts required a per-pixel update to the output power, and the long run of the same value did not. If there is a command throughput limit, or timing delays are being applied to the galvos during power changes, the gradient part is much more likely to hit those. In 2.0, the power commands are sent for every pixel in grayscale mode, whether the pixel changed or not, to keep the throughput consistent across the entire image. I haven’t checked, but it’s possible that setting some or all of the timing delays to zero could improve that.

3D Sliced mode is a single power value, and it’s mostly doing long runs, so it’s going to go faster if delays or throughput are a source of throttling.

6

Hello Oz-

One thing to note is I’ve got the JPT YDFLP-E-300-M7-M-R (110mm x 110mm lens)

This one has a 2, 4 , 6, and 9ns q-pulse that doesn’t cut-off (perform power limiting) below the full 4MHz bandwidth. In fact, to get full power out of the beam at these pulse types, you need to use 4MHz.

This sounds like it needs to resample a line, and differently than the line interval.

I’m seeing that, with my lens at least, I need to use 0.02 line interval to get good results. This is irrespective of what resolution the image has, or what “matters”.

I don’t know for sure what “matters” means yet. Well, I know that I could have a 2048x2048 image on a 20mm dia coin blank which would be a 0.009765625 horizontal resolution on the piece. Let’s call that “0.01” for brevity. It probably wouldn’t give a noticeable difference to only change grayscale values every other pixel, or even by 0.05? Or 0.1? I wouldn’t know.

But- my testing has shown that, for the same q-pulse and power, and when below the cut-off freq, if you lower the freq by 10x and slow the speed by 10x, I expected to get basically the same cut, since the pulses are supposed to be the same energy, and the net pulse count per mm should be the same. But that didn’t happen. Very little engraving happens. I’m not quite sure why, I have theories.

But, barring a gross misunderstanding on my part (and that only happens like every couple of days), this would mean that burning at variable speeds due to data rate limitations is not going to work right. Even if I can get a constant scan rate, I am losing the ability to cut when not running as fast as possible so I need to know what that max.

So, basically, if I tell LB to scan at 1000mm/s, it really needs to be able to consider what the link is capable of and issue power changes as fast as possible while still maintaining the target 1000mm/s data rate. That might mean only one power change- basically a pixel- every 5x image pixels=0.05mm on the coin.

It does look like this is really the only way it can work. Like I say, this is assuming my testing was correct, if you change speeds then even if it automatically scales back the rate of pulses to result in the same net pulses-per-mm, it won’t give a useful result at all. The consistency would be shot, so no image quality.

Or, is this even the right way for grayscale to work? It’s varying power right now, right? I know I just said that changing the pulses-per-mm is highly nonlinear, but I’d need to compare side-by-side if we keep the power constant and instead vary the *pulse frequency" via grayscale value.

Or, even, go another way and keep the freq and power the same and vary the galvo speed with the reciprocal of the grayscale value? That might work a better too.

I know I may be the odd “power user” here right now with a 300W machine that can pulse 2-9 ns at 4MHz without cut-off, and it’d be easy to dismiss an coding effort that might only apply to a few users. But I suspect this could make any machine work better/faster, and also the MOPA laser source field is rapidly evolving, and these are going to become more common and probably even the 20w-100w ones may trend upwards to handle higher freq and be more like this.

7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.