Baby Steps z offset
-
I think the difference is in Marlin for example the babystep function sends extra step pulses to the z motor to shift it by x amount in real time, where as I believe what David has implemented shifts the coordinate system to achieve the same thing, but "jumps the queue" somewhat in the planner rather than waiting for its turn, which we were achieving previously with the workaround using G92 Z0.325 or G92 Z0.275 to shift a 0.3mm first layer up or down by 0.025mm.
That's exactly right. I looked at sending steps directly to the motors, but that has a number of potential issues that could result in lost steps, especially on delta printers, or when using external drivers, or when using a very high steps/mm on a Cartesian or CoreXY printer.
-
This is exactly what i was looking for , i was looking to create a stl for the ft5 to dial this in , using a simular print like my mk2 really didnt work well. Knowing now how it works i beleive i can make a better "z calibration" print . If i understand you correctly all i have to do is break the squarewave into short segments . That way you should see results quicker.
Would something like this work?
–-----------------------------
II
I
Thanks for all the help i am truly loving my setup!
-
Yes, that should work. Also, if you use mesh bed compensation, that will break long moves into segments about as long as the grid spacing, even if the height map is completely flat.
-
Yes, that should work. Also, if you use mesh bed compensation, that will break long moves into segments about as long as the grid spacing, even if the height map is completely flat.
Fantastic !
Thanks -
Is there anything that needs to be done prior to using babysteps or just simply send G92 Z___ anytime during the first layer?
-
No use the webcontrol babystep buttons or paneldue babystep buttons, or use M290 https://duet3d.com/wiki/G-code#M290:_Baby_stepping
G92 during a print was the workaround before proper babystepping was implemented, and it would only work after several moves and even then only when you had the correct amount set i.e. g92 z0.325 or g92 z0.275 for a 0.3mm first layer up or down 0.025.
-
Thanks for the info. Hmmm…thought I updated the DWC when I updated the firmware but a quick look shows I did not. I'll have to figure out how to to that as I'm on ver 1.14a.
-
Upgraded to firmware 1.18 and DWC 1.15a and it works great!!!
-
@DjDemonD and all:
If you babystep up two clicks to 0.1mm higher nozzle position,
then you should add 0.1mm z offset in your slicer, or subtract 0.1mm z offset in the config.g so it might be G31 Z-0.1 for a nozzle contact sensor, or G31 Z2.7mm (if it was G31 Z2.8mm previously).I highly recommend that folks do not use their slicer to compensate for mechanical or calibration issues. It will come back to haunt you later. For instance if you do recalibrate and try to re-run that older g-code. You will have, in this case, an error in Z which will potentially take you down the path of using baby steps to fix.
-
Hi Michael,
Sound general advice but I don't use old gcodes I see them as single use, I reslice each time I produce something as I'm changing the machine so often I'd never keep track of what settings I used in an old gcode so it would be quite unlikely to print successfully.
However if I were to begin producing a lot of the same item in a short production run as I am about to with Piezo probe modules, I would use the same working gcode over and over so fair point.
-
Thanks for stating your reason for doing this. The communication issue is that someone comes along and reads this without understanding the consequences. This happens all the time and I spend a lot of time helping people unlearn things they've read and they take for best practice. Using the slicer to compensate for calibration issues is not a best practice, That's all!
-
undefined alankilian referenced this topic
