Stucki images burn skewed

I’ve wasted 3 pieces of media because when burning the image - 2 different ones - the burn comes out skewed. It looks as if someone moved the horizontal adjustment on a TV, in the 70s. The preview looks fine. I tried at different dpi thinking that might have something to do with it, but I guess not.

Is the skew consistent, or does it change? What firmware do you use in your controller?

GRBL 1.1g - it’s an open builds blackbox. I’ve not let the skewing go more than hundred passes so I can’t tell if it’s consistent. I can let it go for the entire image if that will help diagnose.

Text that I’ve done is not skewed, it’s normal.

It’s possible that you’re asking it to go too fast, which can cause it to skip.

OpenBuilds uses an 8-bit GRBL controller, which has a maximum gcode throughput of about 250 commands per second, easily overwhelmed when cutting grayscale or dithered images. If the controller can’t keep up, it may stutter, and that can cause lost steps. What settings are you using?

I think you’re probably right. I recently changed my acceleration settings, and the speed to help speed things up. Right now my acceleration is at 150 mm/sec and my burn was 450mm/sec. I’ll try cutting those back, and let you know how it looks.

Thanks again!
Awesome software - I’ll be getting the non-GRBL version soon, our CO2 laser is on it’s way!

The acceleration likely isn’t a problem, but 8-bit GRBL is never going to go anywhere near 450mm/sec when engraving an image, unless it’s solid black or solid white nearly everywhere.

changed it to 300mm/sec and it seems to be doing much better - thanks again!

I was wrong.
300mm/min = fail
200mm/min = fail
now trying 125mm/min
also changed acceleration to 100mm/sec
I’ll let you know.

Doesn’t matter what speed, went down to 100 - which I know I’ve done much faster than that successfully in the past. Seems like the x axis is adding a very small number to where the starting point is for each pass. I’m testing a 90 degree scan angle now, for creating the stucki image. My settings are now 300mm/min and acceleration is 30mm/sec. One interesting side effect - when I would notice it was skewed and stop the burn, then return to the home position, the x position was many millimeters off - depending on how long I let it go.

Short version: 8-bit GRBL is fine for some things, but it is not fast.

Longer version: It’s not the speed, as I said before, it’s the gcode processing throughput rate of the controller.

Making the motors draw a straight line at 300 mm/sec, for example, requires processing a single gcode command, and then just toggling the pin to make the stepper move the right distance. It’s trivial.

Making the controller run at 100 mm/sec while processing the pixels from an image at 254 DPI (0.1mm per dot) requires chewing through about 1000 gcode instructions per second, about 4x the rate that 8-bit GRBL can handle.

Drop to 50mm/sec, and drop the DPI down to 120 DPI, and you’ll be roughly in line with what 8-bit GRBL can actually deliver. This is why people push the Cohesion3D and Gerbil boards - they both use 32 bit processors running many, many times faster than the 8-bit / 16MHz chip in your controller.

For normal CNC work, feed rates are much lower and the number of gcode instructions per mm of travel is relatively low as well. A laser usually moves faster, and image processing requires hundreds to even thousands of gcode instructions per second.

Your original speed was 450 mm/sec. If you were trying to engrave a dithered or grayscale image at 254 DPI, that would mean processing 4,500 gcode instructions per second. G1 X0.1 S10 is 10 characters, plus the newline. If each instruction took 10 characters of text to encode, that would be 45000 characters of data per second, or 45kb. Your controller is probably set to 115,200 baud, meaning you can only send 11.5kb per second to the controller. That’s just the receiving speed, nothing to do with processing yet.

1 Like

That does make sense. Couple of questions.
I mistakenly said mm/sec - and it’s mm/min (except for acceleration) - does that make a difference?

Do you have a handy little snippet of math so I could calculate how fast I should go?

Ahh, yes, mm/min is 60x slower, so divide all the numbers I gave by 60.

450 mm/minute is only 7.5 mm/sec, so that’s easily within GRBL’s ability, if you’re doing 254 DPI - it would be about 75 gcode instructions per second.

The math is just mm/sec divided by the interval in mm - that becomes the number of dots to process in one second.

Is the skew consistent? Like, is it just a nice, straight, perfect slant, or does it wobble and weave?

I think it’s mechanical - it seems there is a slight bit of slop in the x axis. I made a 10mm square and just burned it 12 times or so. It ‘walks’ along the X+

I appreciate your help - I think I fixed the issue without finding specific problem. It’s a bummer, but that happens. Maybe one of the pinion screws was loose, maybe the belt was loose - didn’t seem like it, but I tightened them anyway. I also changed the direction of the x axis (it was backwards for some reason). I can start using the limit switches now. Will just have to learn that now.

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