Suggestion for change to implementation of baby-steps

[deckingman]

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.

[gnydick]

@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.

[Phaedrux]

@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.

[dc42]

@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.

[gnydick]

@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***

[dc42]

@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?

[deckingman]

@dc42

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.

[dc42]

@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.

[deckingman]

@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.4

Edit. Ohh and M558 P1 X0 Y0 Z1 F180 T6000 I0 (so yes, a P1 type probe).

[gnydick]

@dc42

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.

[deckingman]

Just trying to get my head around this but wondering if you home to Z max, then do M290 S5, the bed would be constrained by the axis limit as defined in M208 which would prevent it from actually moving any further? But the baby-stepping offset might behave as if the bed had moved?

So maybe the problem exists only if you home to Z max?

[dc42]

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

@dc42

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.

Please share your homing files.

[gnydick]

@dc42

homex

; homex.g
; called to home the X axis
;
; generated by RepRapFirmware Configuration Tool v2 on Fri Feb 08 2019 11:10:07 GMT-0800 (Pacific Standard Time)
G91              ; relative positioning
G1 Y50 S1 ; avoid pulley in corner
;G1 Z-5 F6000 S2   ; lift Z relative to current position
G1 S1 X293 F1800 ; move quickly to X axis endstop and stop there (first pass)
G1 X-5 F6000     ; go back a few mm
G1 S1 X293 F360  ; move slowly to X axis endstop once more (second pass)
;G1 Z5 F6000 S2  ; lower Z again
G90              ; absolute positioning
G92 X275

homey

M913 X40 Y40 ; reduce current
; generated by RepRapFirmware Configuration Tool v2 on Fri Feb 08 2019 11:05:47 GMT-0800 (Pacific Standard Time)
G91              ; relative positioning
;G1 Z-5 F6000 S2   ; lift Z relative to current position
G1 S1 Y365 F1800 ; move quickly to Y axis endstop and stop there (first pass)
G1 Y-5 F6000     ; go back a few mm
G1 S1 Y365 F360  ; move slowly to Y axis endstop once more (second pass)
;G1 Z5 F6000 S2  ; lower Z again
G90              ; absolute positioning
M913 X100 Y100 ; restore current

homez

G91
G1 Z400  S1 F1500
G1 Z-5 
G1 Z10 S1 F100
G90

[dc42]

@gnydick, thanks. I've just tested homing to max Z with 5mm of baby stepping applied. Specifically, I did this (from bottom to top):

20/03/2019, 15:36:50 M114
X:0.000 Y:0.000 Z:195.000 E0:0.0 E1:0.0 E2:0.0 E3:0.0 E4:0.0 E5:0.0 E6:0.0 Count 0 0 40000 Machine 0.000 0.000 200.000
20/03/2019, 15:35:28 G1 S1 Z400
20/03/2019, 15:35:13 G91
20/03/2019, 15:35:05 M208 Z200
20/03/2019, 15:34:34 M574 Z2 S1
20/03/2019, 15:34:14 M290
Baby stepping offset is 5.000mm
20/03/2019, 15:34:12 M290 Z1
20/03/2019, 15:34:12 M290 Z1
20/03/2019, 15:34:11 M290 Z1
20/03/2019, 15:34:10 M290 Z1
20/03/2019, 15:34:07 M290 Z1
20/03/2019, 15:33:51 G92 X0 Y0

So I applied +5mm of baby stepping, then I homed to max Z, which I had set to 200 in M208. After this the Z coordinate reported by both DWC and M114 was 195, as expected (i.e. user position +195, plus 5mm baby stepping, gives a machine position of +200).

All this is exactly as expected. When I originally implemented baby stepping, I reset it to zero when you homed Z. but at the request of several users, I changed it to persist across homing. It is still reset to zero at power up.

If you want to reset baby stepping during homing, or at the end of each print, you can do that by adding command M290 R0 Z0 in one or more of homez.g, homeall.g, stop.g and cancel.g.

You might with to do a similar test to mine, i.e. apply +5mm bay stepping, then home Z to max. You said that you have Z max set to 300mm, so you should find the that displayed Z coordinate after homing Z is 295. If you then command the nozzle to Z0, it should be 5mm above the bed.

[gnydick]

@dc42 i see what you're saying. I just did that little experiment right now, but in practice it hasn't worked that way. I don't know if having printed changes the internal flow somehow.

[dc42]

Having printed should not change anything, assuming that the print file didn't have any M290 commands in it.

[gnydick]

@dc42 I did some experimenting, and it looks like it depends on whether you baby step + or -. If you baby step - then the homing routine breaks like I explained.

[gnydick]

I also just reconfigured my machine. It now Z homes at zero. I had positive baby-stepping of .2. Then I homed the machine, which includes a final move to Z75. The display read Z74.80. I reset baby-steps and the bed moved, but the DWC still showed Z74.80.

So, this is all getting confusing, which is what leads me back to my original suggestion. NONE of this behavioral heuristics would be necessary if the Z value was always where it physically is and never a virtual coordinate.

[dc42]

I've just found a bug in the current baby stepping code. When using relative babystepping (the default), sometimes it will babystep more than the amount you asked for. I wonder whether this might explain your earlier observations?

[dc42]

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

So, this is all getting confusing, which is what leads me back to my original suggestion. NONE of this behavioral heuristics would be necessary if the Z value was always where it physically is and never a virtual coordinate.

I'm not going to change it, because it would be very confusing if you send a G1 command to send the head to one set of coordinates and it goes to different coordinates, and because the physical coordinates also include the effects of workplace coordinate offsets, tool offsets, bed compensation, axis skew compensation, and firmware-controlled retraction Z-hop. But I think there is a case to be made for DWC showing both user coordinates and machine coordinates.

Btw the next 2.03beta will have the option to do instant (live) babystepping on the most common machine architectures.