Suggestion for change to implementation of baby-steps
-
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?
-
@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.
-
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.
-
@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.
-
@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
-
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".
-
@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.
-
@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.
-
@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.
-
@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.
-
Might have got that wrong. As I said, I don't normally use baby stepping. I thought I was lowering the bed when in fact the buttons relate to the tool head so the downward pointing icon actually moves the bed up. Therefore I was applying a negative offset hence 10.50 mm. And after homing with the offset, jogging the axis will only allow me to go to Z=0.5mm and no lower which I guess is to be expected.
Personally, I find it confusing that the displayed Z value changes depending on whether baby stepping is applied before or after homing but if that's the way it is, then fine. I don't use it so I don't really care.
-
@dc42 He is correct that the Z indicator doesn't show the actual position. If I baby step 100mm from position 5, it will always display 5.
I've said this before, but it doesn't seem to have weight with you, there are MANY more workflows than: click, print, finish.
Follow this...
I expect you to say to add baby step reset to the stop.gcode or to the slicer, but then that would defeat the ability to re-use the value.
And, since baby-steps impact, but not stored value, are transient between homings, as they are just a value applied, with no impact on the actual z height measure, you have to also reapply them between prints if even you don't reset them.
If we see a pattern and that we always need -.15 baby-step, you'll say to apply that offset in the config, but that can be filament specific. So you say, that's fine, keep it global, but when you use a differing filament, adjust the baby-step for that print. That only works for one print if you home between prints. So you say remove re-homing between prints. Well, I have a printer in development that may not be reliable, so I need to re-home between prints.
You see the cycle here? It's like the Three Stooges file cabinet. It's a never ending cycle of work arounds. if the baby-step was part of the z-height register AND remembered to be applied to the offset of the beginning position of a print, all of these situations would be handled without workarounds. Sure, if it seems to be a permanent need, put it in the config. But I don't want to stop what I'm doing, update the config, reset the printer, lose my heat, and start over. Maybe baby-stepping can store to its own file so it persists between reboots.
Like I said, the Live-Z Marlin feature just never fails, it never complicates things. Homing will always trigger at the same height, but the live-z offset both gets applied to the gcode for printing as well as effects the z-height register.
-
@gnydick said in Suggestion for change to implementation of baby-steps:
reset the printer, lose my heat, and start over.
You're gonna hate me saying this, but you don't have to reset the printer. You can send the updated G31 through the gcode console and it will take effect immediately.
-
@gnydick said in Suggestion for change to implementation of baby-steps:
@dc42 He is correct that the Z indicator doesn't show the actual position. If I baby step 100mm from position 5, it will always display 5.
I've said this before, but it doesn't seem to have weight with you, there are MANY more workflows than: click, print, finish.
Follow this...
I expect you to say to add baby step reset to the stop.gcode or to the slicer, but then that would defeat the ability to re-use the value.
And, since baby-steps impact, but not stored value, are transient between homings, as they are just a value applied, with no impact on the actual z height measure, you have to also reapply them between prints if even you don't reset them.
If we see a pattern and that we always need -.15 baby-step, you'll say to apply that offset in the config, but that can be filament specific. So you say, that's fine, keep it global, but when you use a differing filament, adjust the baby-step for that print. That only works for one print if you home between prints. So you say remove re-homing between prints. Well, I have a printer in development that may not be reliable, so I need to re-home between prints.
You see the cycle here? It's like the Three Stooges file cabinet. It's a never ending cycle of work arounds. if the baby-step was part of the z-height register AND remembered to be applied to the offset of the beginning position of a print, all of these situations would be handled without workarounds. Sure, if it seems to be a permanent need, put it in the config. But I don't want to stop what I'm doing, update the config, reset the printer, lose my heat, and start over. Maybe baby-stepping can store to its own file so it persists between reboots.
Like I said, the Live-Z Marlin feature just never fails, it never complicates things. Homing will always trigger at the same height, but the live-z offset both gets applied to the gcode for printing as well as effects the z-height register.
You seem to be saying that the baby stepping offset is somehow remembered over homing but not actually applied. I don't believe that is the case; but I'm willing to be persuaded if you can provide a sequence of GCode commands (+ manual checking of nozzle height if needed) to demonstrate it. The other possibility that occurs to me is that you are homing to max Z and your printer is gradually getting hotter and expanding, so that you need increasing amounts of negative babystepping to counter the expansion.
-
@dc42 Baby-stepping is remembered after homing. Here's the simple sequence...
G28 ; home G1 X150 Y150 Z0 ; roughly middle of the bed with nozzle touching M290 S5 G28 Z ; re-home Z G1 Z0 ; bring back the bed to the nozzle M290 R0 S0 ; ***ENJOY THE CRASH***
-
@gnydick said in Suggestion for change to implementation of baby-steps:
@dc42 Baby-stepping is remembered after homing. Here's the simple sequence...
G28 ; home G1 X150 Y150 Z0 ; roughly middle of the bed with nozzle touching M290 S5 G28 Z ; re-home Z G1 Z0 ; bring back the bed to the nozzle M290 R0 S0 ; ***ENJOY THE CRASH***What should happen is that the G1 Z0 command should leave the head at 0 + 5mm = 5mm above the bed. Then M290 R0 S0 should lower the head to the bed. Is that not what happens? How are you homing Z?
-
For info, I just tried this out on my machine. It seems to work as you say with one exception. When I input M290 S5, I only get an offset of 1mm. I'm guessing that there is a 1mm limit on baby stepping? If not, then something is amiss.
Anyway, here is what I got......
G28; home all - after which....
Measured nozzle height =10.00mm (as expected with the commands I use)
DWC shows Z= 10.00
Baby stepping offset shows 0 mm.G1 Z0 - after which......
Measured nozzle height =0mm
DWC shows Z= 0.00
Baby stepping offset shows 0 mm.M290 S5 - after which....
Measured nozzle height =1.0mm
DWC shows Z= 0.00
Baby stepping offset shows 1 mm.G28 Z - after which
Measured nozzle height =10.0mm
DWC shows Z= 9.00
Baby stepping offset shows 1 mm.G1 Z0 - after which
Measured nozzle height =1.0mm
DWC shows Z= 0.00
Baby stepping offset shows 1 mm.M290 R0 S0 - after which
Measured nozzle height =0.0mm
DWC shows Z= 0.00
Baby stepping offset shows 0 mm.HTH
Edit. This is just for your info - I don't use baby stepping myself but I had a few minutes to spare so ran those tests.
-
@deckingman said in Suggestion for change to implementation of baby-steps:
For info, I just tried this out on my machine. It seems to work as you say with one exception. When I input M290 S5, I only get an offset of 1mm. I'm guessing that there is a 1mm limit on baby stepping?
Thanks for running this test. There is indeed a limit of 1mm in any babystepping command, unless you use the R0 parameter to specify an absolute babystepping offset.
Do you home Z using a homing switch or a Z probe? It might make a difference.
-
@dc42 said in Suggestion for change to implementation of baby-steps:
Do you home Z using a homing switch or a Z probe? It might make a difference.
That depends on your definition. Essentially it's a switch connected to the nozzle mount which can move in Z, so the nozzle is the probe. But because the switch has an LED in series, I have to use it as an analogue switch. I get a reading of about 524 when it isn't triggered and 1000 when it is.
Here is relevant line from my config.g
G31 P700 X0 Y0 Z-0.4Edit. Ohh and M558 P1 X0 Y0 Z1 F180 T6000 I0 (so yes, a P1 type probe).
-
conditions here are that this is a moving bed with a switch at Z-max.
That's not happening at all. When you home, the firmware automatically sets the Z position to the max. If baby-stepping is still on, your bed will indeed be at the correct max position. If you then G1 Z0, you will indeed position the bed at Z0. Then you reset baby-steps, and the bed tries to move opposite to the baby-steps. If it was positive baby-steps, the bed will crash into the nozzle. If it was negative baby-steps, the bed will move away from the nozzle.
