Suggestion for change to implementation of baby-steps

gnydick

So, I've a long and storied history with my Promega and the unreliability of it lead me to use baby-steps often. @dc42, you and I have chatted about that before WRT baby-steps vs. Marlin's Live-Z.

One problem with baby-steps is that it doesn't change the Z-height register. I think it's important that it does. Here's why.

givens

Z max = 300mm
layer height/first layer height = 0.2mm

Let's say I'm printing, then I need to baby-step, print finishes, and I want to print something else. In the mean time, I re-home my printer and have forgotten that baby-steps were applied. Since the firmware just applies steps and keeps a baby-step counter, when my bed goes all the way back down, the controller thinks the bed is at 300mm and it is, because the limit switch is triggered or whatever routine it is, makes sure that the bed is now 300mm away from the nozzle. Now, I remembered that I had baby-steps applied. I (through a macro I've created) reset the baby-steps and then the bed moves to accommodate the change. So, if I had a negative baby-step, the bed now moves down and instead of 300mm away from the nozzle, it's 300.4mm away. The controller still thinks it's 300mm though. So now, when I start my next print, I'm automatically .4mm further from the nozzle than I should be. You may say that, well, if the baby steps were needed the first time, they'll be needed again, but that just isn't always the case. Sometimes it's after switching filaments where you want a lot of squish with PLA, but not so much with PETG.

So, what really happened was this...

Printer homes, and starts print at first layer, according to the controller, the nozzle is at 0.2mm. I wasn't getting the squish I needed so I baby-stepped down to 0.0mm. Print went well, maybe I'm not calibrated that well, but it's working for me, so I don't care.

Print finishes and I go about my day. Come back later, and manually home my printer to move the bed out of the way to switch filaments from PLA to PETG. Baby steps are still applied and my bed moves all the way down to the actual 300mm.

I remember that baby-steps were applied and decided to reset them because PETG works differently and I want less squish. So, I reset baby-steps and the bed moves down 0.2mm, so it is physically at 300.2mm. The control board still thinks it's at 300mm.

I start my next print, and the bed comes up 299.8mm to place the nozzle at 0.2mm. However, since the bed actually started at 300.2mm, the nozzle is actually at 0.4mm.

You may say, well, the homing script should reset baby-steps, or the starting g-code should reset baby-steps, but I don't think that's the correct way of handling it.

It shouldn't be up to the end-user to make sure that a baby-step reset is configured somewhere and everywhere it needs to be based on their particular workflow. Many people may be still building/tweaking their machine and need to use baby-steps and homing moves frequently while debugging, this just makes it really impossible to manage.

I think the only sensible implementation is that the controller should know that it's at a different physical location and that when applying gcode, it applies the appropriate offset to the move. Meaning, if the print head is at 0.2mm and you need to offset it, the z-height will actually be 0.0mm not some invisible value that the end-user doesn't know.

This solves a couple problems...

It takes care of the scenario I was describing because if I tweak the z-offset for one print, I know that it will be the same for the next print, not potentially doubled, since the offset is a fixed addendum to the gcode.
You can apply baby-steps to your execution pipeline without worrying about missing steps because instead of applying it in the stepper code, you apply it in the higher level code that parses and sends the g-code to the lower level stepper code. No missed steps, ever.

I'm going to also guess that the fact that the z-height actually changes, instead of just manipulating the stepper pipeline alleviates many problems and simplifies many other bits of code.

It just makes sense. You move the bed down, it's down. why should the printer think the bed is at a different height when it's not?

wilriker

@gnydick said in Suggestion for change to implementation of baby-steps:

why should the printer think the bed is at a different height when it's not?

This prevents the effort of checking and possibly editing every single GCode command.

But that does not mean that you not have a point in all of this. Though my idea on this would be: whenever you home baby-stepping is reset. Possibly it will also be reapplied after homing. Though I am too tired now to think through all of the side-effects.

dc42

When I first implemented baby stepping, the baby stepping offset was reset to zero when Z homing, which is what i think you are asking for. This led to many complaints. So now the baby stepping offset is preserved always, until you power off or reset the printer.

I think you are in a small minority in wanting to clear baby stepping when you home the printer.

This solves a couple problems...

It takes care of the scenario I was describing because if I tweak the z-offset for one print, I know that it will be the same for the next print, not potentially doubled, since the offset is a fixed addendum to the gcode.

The offset is already a fixed (until you change it) addition to the GCode. The only way I can see that you would double the baby stepping is if you apply the same relative baby stepping twice, once for each print. If you know what baby stepping you need, you can provide an absolute baby stepping offset instead.

You can apply baby-steps to your execution pipeline without worrying about missing steps because instead of applying it in the stepper code, you apply it in the higher level code that parses and sends the g-code to the lower level stepper code. No missed steps, ever.

That's already how it works. Except that to improve the responsiveness of baby stepping, the firmware attempts to apply the baby stepping to moves already in the pipeline as well as to new moves.

gnydick

@dc42 it's funny. The last time we spoke about baby-stepping, you said it was supposed to be reset at the end of a print.

I don't think I am in a minority. If you swap filament materials, you're going to want to change your squish factor.

I think you are missing the point I'm trying to make. I don't necessarily want it to reset baby-steps when you home, I want the position indicator to always be the physical position AND that the system doesn't store a magical offset, as far is it knows, there is just a delta to be applied to whatever commands come in. There really is a nuanced different there. The fact that it's a hidden value when you're not on the Job Status screen is bad. You can forget that it's applied. There are all sorts of things that you're not envisioning that people go through when they're iterating on a machine design, many unorthodox workflows happen. When my Z isn't stable and I have to frequently calibrate where zero is, I go through all sorts of gyrations, macros, etc. trying to make my life easier. If I zero the bed, record a value, then reboot the machine, my value is wrong because the position indicator didn't read the actual physical position. You'll say, "well, you have to remember to bring the nozzle to the bed, then reset the position with G92 Z0, then you can get an accurate delta." That's not acceptable. I build infrastructure for other engineers for a living. The tools I provide to them are unopinionated because they don't assume any specific workflow, nor do they require having to remember to do certain things in order to work correctly. When that happens, it's considered a bug. Imagine if you were coding and you dereferenced a pointer, but you had to determine if you needed to apply an offset to the memory address based on some condition. That wouldn't make much sense. This is the same thing. I want to read a register and it be correct.

I think you really have to put yourself in you end-users' head and realize, it's not a single workflow device. That and this implementation is opinionated on that assumed workflow.

It will be much simpler to just treat baby steps as a jog dial for the Z position.

I'm curious if you've spent much time with a Prusa, tuning it up, calibrating, etc? The experience is much more intuitive.

If my printer worked perfectly, it wouldn't really matter how baby-steps were implemented, because I'd practically never need to use them, though again, switching filament types does warrant it.

But as a tinkerer, the logic behind this feature, and others, actually gets in the way because it is opinionated as I described. This is a controller for an industrial machine. What industrial machines do you know that don't show you the actual physical position? A CNC machine like a mill or router, etc., will all show you exactly where the tool is and if you need to calibrate it on the fly, that indicator changes. What we have here is just an antipattern.

I've rambled a bit, but the overall point I'm trying to make is, you have to make things for people to use how THEY want to use them. I hope that came through clearly.

deckingman

@dc42 I was having a little difficulty understanding what the issue is here but now I think I do. If I understand correctly and cut through all the personal stuff, in simple terms, it looks more like a DWC issue than a firmware issue and I'd say it's nothing to do with the implementation of baby-stepping as such.

So if one homes the printer, then go into the job status section of DWC and hit baby stepping a number of times, the bed will move (on a moving bed system) but the machine status section does not report the new position of Z. In my case, after homing, the bed is at 10mm. So hitting baby stepping say 10 times will give an offset of 0.5mm, the bed itself does indeed move 0.5mm but the displayed head position for Z does not change. In my case, it still shows Z being at 10mm. If one then re-homes the printer, with that 0.5mm offset still applied, then after homing the machine status section shows the Z height to be 10.5 mm which is the correct position.

I think the only change that's needed is that DWC should show the Z position with whatever offset is applied as soon as that offset is applied (i.e. whenever the baby stepping button is hit). I think the physical position is correct - it's just not always being displayed correctly.

HTH

Edit - can't speak for the OP but I'm using the following firmware

Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics: Duet Ethernet 1.0 or 1.01 + DueX5
Firmware Version: 2.02(RTOS) (2018-12-24b1)
Web Interface Version: 1.22.6

dc42

There are essentially two positions: the user position and the machine position. The user position is what the user asked for in GCode. The machine position is what the firmware moves the head reference point to after applying the tool offset, workplace coordinate offset, bed compensation, axis skew compensation, and babystepping.

For most purposes, it's the user position that the user is interested in. If a user commands the head to X10 Y20 Z5 then it would appear odd if the reported position is something different. So it's the user position that DWC displays.

However, RRF provides both the user position and the machine position to DWC. So it would be possible to change DWC to show the machine position instead, or to show both positions. I expect this will be an option in DWC2 in future. If you want to patch DWC to display machine position instead of user position, search the .js file for references to field ".xyz" of the status response and replace them by ".machine".

deckingman

@dc42 said in Suggestion for change to implementation of baby-steps:
.........................

For most purposes, it's the user position that the user is interested in. If a user commands the head to X10 Y20 Z5 then it would appear odd if the reported position is something different. So it's the user position that DWC displays....................

Personally, I don't give a damn as I don't have a need to use baby stepping. But, I think this is what the OP is complaining about. That is to say, if the user presses the baby stepping buttons to essentially command the head to move from say Z5 to Z4.5 then DWC still displays the position as being Z5.0 even though it is actually 4.5. I guess it depends on whether baby stepping is defined as a move command.

So we have the situation where DWC shows the Z height without the offset (5.0) and also displays the offset (0.5). But then if the printer is homed still with this 0.5 offset applied, then after homing DWC will show the Z position as being 5.5 (i.e the Z position plus the offset) and also still shows the offset as being 0.5.

So there is an inconsistency in how DWC displays the Z height depending on whether the printer is homed before or after baby stepping is applied. Maybe that's how it is but
I can see how this would get confusing. i.e. prior to homing DWC displays the Z position without the offset, but then if the printer is re-homed, it shows the Z position including the offset. The offset value itself does not change when homing happens.

So how can an end user know where the print head is in relation to the bed if the displayed value changes depending on whether the printer was homed prior or after the baby stepping buttons were pressed?

As I said, personally I don't give a damn as I don't use baby stepping so I'll leave any further debate to others.

dc42

@deckingman said in Suggestion for change to implementation of baby-steps:

So how can an end user know where the print head is in relation to the bed if the displayed value changes depending on whether the printer was homed prior or after the baby stepping buttons were pressed?

You make it sounds as though the displayed value for a given actual position depends on whether you home before or after babystepping; but that's not the case. Suppose your Z probe or Z endstop triggers at 5mm. If you home and then apply 1mm babystepping, the head will initially be at 5mm but after you apply the babystepping it will have been raised to 6mm. If you then home Z again, the head will be at 5mm above the bed (not 6mm) but 4mm will be displayed.

All this ignores the fact that if you have a tool offset applied, or bed compensation applied, the height will be further adjusted.

Perhaps one option would be for DWC to display the baby stepping offset alongside the Z coordinate.

deckingman

@dc42 said in Suggestion for change to implementation of baby-steps:

@deckingman said in Suggestion for change to implementation of baby-steps:

So how can an end user know where the print head is in relation to the bed if the displayed value changes depending on whether the printer was homed prior or after the baby stepping buttons were pressed?

You make it sounds as though the displayed value for a given actual position depends on whether you home before or after babystepping; but that's not the case. Suppose your Z probe or Z endstop triggers at 5mm. If you home and then apply 1mm babystepping, the head will initially be at 5mm but after you apply the babystepping it will have been raised to 6mm. If you then home Z again, the head will be at 5mm above the bed (not 6mm) but 4mm will be displayed.

All this ignores the fact that if you have a tool offset applied, or bed compensation applied, the height will be further adjusted.

Perhaps one option would be for DWC to display the baby stepping offset alongside the Z coordinate.

Sorry David but it is the case that the displayed value for Z depends on whether you home before or after baby stepping is applied. At least on my machine that's what happens.

So in your example and in my actual usage case, I home Z at the end of which the head is at 10.00mm above the bed - actual real distance and that's what DWC shows. The trigger height is actually 0.4mm but that's irrelevant.

Then I apply baby stepping repeatedly - actually 10 times - moving the bed downwards away from the nozzle. The bed moves each time, the current offset increments each time, but the head position for Z does not change. It stays at Z = 10.00mm. After 10 presses of the baby stepping button, the bed has moved 0.5mm further away from the nozzle, the current offset shows this 0.5mm but DWC still shows Z =10.00. At this point, the head position is actually 10.50 mm from the bed.

So at this point, the displayed value for the actual head position is 10.00mm but the actual head position is 10.50 mm from the bed.

Now, if I home Z again, without doing anything else - leaving the baby stepping offset at 0.5mm, after the homing sequence finishes, the displayed value of head position is Z=10.50mm.

So the displayed value of actual head position in Z was 10.00 mm prior to homing, but it changed to 10.50 mm after homing.

dc42

@deckingman said in Suggestion for change to implementation of baby-steps:

Then I apply baby stepping repeatedly - actually 10 times - moving the bed downwards away from the nozzle. The bed moves each time, the current offset increments each time, but the head position for Z does not change. It stays at Z = 10.00mm. After 10 presses of the baby stepping button, the bed has moved 0.5mm further away from the nozzle, the current offset shows this 0.5mm but DWC still shows Z =10.00. At this point, the head position is actually 10.50 mm from the bed.
So at this point, the displayed value for the actual head position is 10.00mm but the actual head position is 10.50 mm from the bed.

So far, this is as I expect. The user Z coordinate is 10mm and you have applied +0.5mm babystepping.

Now, if I home Z again, without doing anything else - leaving the baby stepping offset at 0.5mm, after the homing sequence finishes, the displayed value of head position is Z=10.50mm.
So the displayed value of actual head position in Z was 10.00 mm prior to homing, but it changed to 10.50 mm after homing.

Are you sure? That sounds the wrong way round to me. If you apply positive baby stappering, and then you home Z using a Z probe and optionally perform a relative Z move afterwards, then the displayed height after homing should be reduced by the babystepping amount. Which is what happens on my delta. The displayed Z coordinate after homing the second time in your example should be 9.5mm.