Suggestion for change to implementation of baby-steps

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.

gnydick

@dc42 I think that will be confusing as well.

Let's take a step back and look at it again...

Baby-stepping, in it's current implementation

Causes an inconsistent representation of the coordinates
- Sometimes it effects the displayed coordinate and sometimes it doesn't.
Regardless of the representation, if the bed is against the nozzle and there was positive baby stepping applied, a baby-step reset will cause a crash and some sort of damage, especially in the case of build surface coatings like PEI and a hot nozzle.
- The M564 setting will not influence whether or not the bed/nozzle will crash.

Goals

We don't want to confuse the user
We don't want to cause bed crashing
We don't want to cause movement beyond the maximum of the Z axis
This is a machine, not software, it should be dumb and just do what we tell it to do predictably.

Objective of Baby-Stepping

Be able to adjust the z height so that the bed-nozzle distance is correct for the foreseeable future
- that could be until it needs recalibration some days, weeks, or months away
- it could be the next print
  - common scenario when you're trying to work the kinks out of an in development machine, like I've been doing since last June.
  - could be because your filament is particularly difficult to print and you need to keep an eye on it
  - could be bad slicer settings
  - etc.

How do these goals and objectives mesh together?

The representation should always inform the user correctly. That doesn't mean the Z value is the same as the physical position or the adjusted position. There are two paths for that
1. The representation changes as you baby-step, and if you apply baby-stepping positive, e.g., you're Z will never be zero until baby-stepping is reset. To me, honestly, that wouldn't be confusing; I'd home the machine, bring the nozzle to the bed and see Z: 0.20, especially if the baby-stepping is represented next to it. That would be cake. And if it's negative, the same.

The representation never changes and the firmware obfuscates everything under the covers. Which is a lot of cases to handle. Here are just some of them.
- If you baby-step positive and you home to the low end and you're now at nozzle-meets-bed position, then the screen will read Z: 0.00 and resetting baby-steps will not go past the configured past 0 config as it knows that this should be treated like Z:0 and modifies all movements accordingly.
- If you baby-step negative and you home to the high end, the same thing has to happen, but in reverse. It should know that you're at your axis maximum and not move the bed.
- You've just finished a print, and have baby-stepped, and you're not happy and want to probe the mesh, but, you forget to reset the baby-steps. How should it be implemented in firmware? Do you consider the baby-steps to be part of the probe offset, or not?

There's no way to know how to implement all of the scenarios because each machine is different, and each person's thoughts on how things should work are different. There should be no room for interpretation.

You see how option #2 starts you down a rabbit hole? We are currently in that rabbit hole, which I don't think is tenable. I think there're too many scenarios that conflict with each other that can't be reconciled with heuristics or state machines.

My vote would be for #1. Nothing is obfuscated from the user. When they're calibrating, tuning, building, tweaking, printing, etc., if they know how the printer works, which is a requirement at this point, then with the display in front of them, they'll know if they need to reset baby-steps, or move the bed||nozzle away from the other before resetting to avoid damage, because it's in front of their face.

An ounce of added complexity to the display will save tons of frustration. The absolutely correct value for Z is a vector of sorts. [ position, offset ]. If that's what was represented, there would be no confusion what-so-ever.

This obviously becomes less important if there is a permanently deployed Z height sensor, because then you can avoid problems, but we don't all have that. That's how Prusa can get away with NOT showing the physical position and/or offset amount. All Prusa's have a probe and re-home before every print and the Z-offset value is just applied for all moves.

gnydick

@dc42 I still think this is worth talking about.

The current implementation only works well if your printer is very well behaved and calibrated, and you add baby step maintenance commands to your homing scripts.

Also consider the following scenario.

I start a print and notice it's not pressing the filament down and I baby step down. The printer thinks it's at 0.2 but it's obviously not, it's at 0.5 or 0.6 in actuality.

This simple scenario completely breaks your vision of wanting the printer to go to the position you tell it, not a physically different position.

Baby stepping should be a permanent adjustment. Look at it this way. Let's say I have a shitty printer that doesn't always home well. Maybe it's temperature fluctuations and expanding material moving the sensor, who knows.

It would be incredibly useful to be able to baby step to fix the offset, and then just be able to forget it until the barometer moves again.

Don't even display it. It's an adjustment that's no different from moving the sensor.

This is how the Marlin firmware does it and it's SO much simpler. I never, ever have to think about it other than when I need to adjust. For example, switching from PLA to PETG, I like dialing back the squish a little bit.

dc42

I don't think making babystepping permanent would suit all users, but we could make it optional. One way would be to have M500 P290 write config-override.g including the current babystepping value (just like M500 P31 writes config-override.g including the current G31 parameters). Would that help you? You could put the M500 P290 command in stop.g if you wanted.

fma

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

Don't even display it. It's an adjustment that's no different from moving the sensor.

I also see it this way.

deckingman

Personally, I would not be happy if baby stepping was permanent. In a perfect world, you set the offset between the point where the probe triggers and the point where the nozzle is just touching the bed. Then when you set the first layer height to be say 0.3mm, that is what you get. But we don't live in a perfect world and sometimes (but not always) people found that they needed to occasionally adjust the first layer height but didn't want to keep re-setting the probe offset. That is the reason why baby stepping was introduced in the first place - to enable people to occasionally adjust the first layer on a per print basis.

So if you make baby stepping permanent (or even carry it over to the next print), then it becomes just another way to set the probe offset, and you lose the ability to make small adjustments on a per-print basis (because whatever change you make will be carried over to the next print and no longer be applied solely to the current print). Which is the whole reason for having baby-stepping. Worse than that, to see what the probe offset really is set to, users will have to look first at their configuration file to find the offset value, than look elsewhere to find the (permanent) baby stepping value and add or subtract one from the other.

A printer that doesn't home reliably or consistently surely needs the ability to be able to make adjustments on a per-print basis. So I really don't see why such a printer is being held up as an example of why baby-stepping needs to be permanent. If the Z height needs to be adjusted by the same amount across multiple prints, then change the probe offset. That's what it's for and we don't need another mechanism to change it - especially when we would have to look in two different places for two different values.

gnydick

@deckingman yes, exactly. I would be fine if that's what it did, update the probe Z delta. That's a good way to think about it.

gnydick

@dc42 it still doesn't solve the fact that the end user has to remember if baby-stepping is in effect. As I've described, sometimes it offsets the Z value, sometimes it doesn't. There just isn't a single behavior to it. And the bed crashing problem.

bs+, bs+,........, bs+, then you home to Z0 and say to yourself, OH, i fixed my probe Z-height, I can reset baby-steps -- CRASH. It's just not a good setting to expose to people as a runtime setting.

Like @deckingman said, it's the same thing as just fixing your z height offset. That's how Marlin does it.

If implemented as an internal offset...

For good, stable printers, you'll rarely, if ever need bs, except maybe switching between filament types
For a printer in development that isn't always reliable, it lets you tweak something in a completely safe way, because you'll never "reset" baby-steps, you'll just "jog the dial".

Think of bs'ing as a relative thing, rather than something that changes the Z value, it's just an internal compensation. I'll give you an example of another real world system like this.

Older cars with distributor caps. They have a firing order, and amount of delay that you can calibrate. An 8 cylinder engine has the leads at 45 degrees apart. If you dial up the delay, or advance it, you're still firing 45 degrees apart, you're still firing in the correct firing order, the cap just needed calibrating.

fma

On my previous printer, I had no endstop/probe at all. I just moved the Z axis down to the bed, and use G92 Z0.

Sometimes, it was not perfect, and during the first layer print, I moved up/down the Z axis by turning the Z screws, by hand. For me, baby stepping should do the same: just shift the entire Z worspace.

As it is a manual process, with visual feedback, we don't care about the absolute value. Maybe we need to have a feedback to know if the click is taken into account, but that's all.

And this shift should remain as long as we don't home/probe the Z axis again (I don't understand why slicers re-home all axis at each print: it can be usefull for X/Y, as on cartesian geometry the bed moves as soon as you touch it while removing the print, but not Z. On my CoreXY, I home it once, and can print all the day without problem).

deckingman

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

.................................. (I don't understand why slicers re-home all axis at each print: it can be usefull for X/Y, as on cartesian geometry the bed moves as soon as you touch it while removing the print, but not Z. On my CoreXY, I home it once, and can print all the day without problem).

Well slicers will only home all if that is what you tell them you want to happen.

I understand that you and I need only home once but many other users have printers that are less than perfect, with parts that may flex, bend, or otherwise misbehave between prints.

Personally, all my codes have a call to one of my "pre-print" macros which do include home all commands. This macro call is all that I have in my slicer start gcode . The reason for that is so that I can just turn on my printer, select a file, hit "print" and walk away. The fact that it will re-home for subsequent prints is largely irrelevant because it does no harm and the homing happens while the heaters are coming up to temperature so it takes no more time either.

dc42

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

And this shift should remain as long as we don't home/probe the Z axis again...

RRF used to clear baby stepping when you homed Z. A number of users complained about that, so now baby stepping is only cleared when the board is powered up or reset. Looks like I can't please everyone.

fma

Well, not everyone uses it for the same purpose...

@dc42, what was you first goal for this feature?

deckingman

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

Looks like I can't please everyone.

.........some of the people all of the time, all of the people some of the time, but not all of the people all of the time (Abraham Lincoln).

tommyb

With a little more complexity but more consistent implementation with machine control best practice, here might be an improved solution:

Live baby steps (no change from today)
Persistent over ride indicator (any delta from Z offset =0)
Override Save button; indicator turns off, permanent change to Config.g
Reset or power off = lost baby-step values if not Saved

This would also greatly simplified setting up Z offset as well.

Another useful change in a related yet completely different request would be a "set max home offset from last save home positions" This would help with conditions such as slipped/bent or otherwise unexpected change to home switch or flag resulting a safer condition when a sensor does not toggle when expected. This scenario took me a while to figure out for why I was randomly crashing (and finally cracked some glass) during homing Z due to hardened blob of PLA in nozzle. The blob pushed the glass away from the sensor trigger point until either something broke or axis ran out of travel. Yes the inductive sensor range is at it's margin for good use and I could always wait for the HE to be at temp before homing....

gnydick

@tommyb That's more complicated. What is wrong with just doing it like Marlin?

Print is happening, you notice it's off, you jog the dial, and done. Period, no having to "understand" or "remember" anything. No checking or unchecking an override button.

Hide the whole damn value from visibility except for if someone wants to see it, because it's just a fine tuning. Z0 will still be Z0 even if it's 100um from where the home sensor says Z0 is.

It's sooo much more simple that way.