Suggestion for change to implementation of baby-steps

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.

Phaedrux

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

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.

I can't say I'm a fan of that. I want my z probe to be accurate not secretly corrected.

gnydick

@phaedrux So, it's not totally hidden. For example, when you do it on a prusa, you see the value changing as you turn the dial. After that, I just trust Z0 is Z0. Even though on a perfect system Z0 isn't actually Z0. Right?....

What's the manual method for leveling? Using a sheet of paper between the nozzle and the bed and sliding it around while adjusting Z until the paper just moves freely. That's about 0.05mm, so you're Z0 is actually Z0.05.

I hope that didn't blow your mind about your probe being accurate. All kidding aside, in order to get a well dialed in machine, you have to lie to yourself 100% of the time. The probe doesn't measure Z0, it measures Z0.05. So who cares if you dial that in with a literal dial, or click a button up/down? Either way, you'd be setting it and forgetting it even existed until it came time to calibrate again. Not everybody uses a probe either. So that's a different way of thinking about the implementation of accuracy. People with mechanical endstops or who have probes that are effected by temperature, like the prusa, use this z-offset functionality because it's necessary because their endstops or probes are just not going to be that precise.

Ultimately, why would we want any setting or calibration knob to be something that is not 100% determinate? No matter what, the current implementation does not work the same 100% of the time. I'm merely proposing a solution that will work the same for everyone on every machine, regardless.

P.S.
I look at it like the dials under the bed for manually adjusted beds. I turn them, they have no graduated scale on them or even any numbers, but who cares?

deckingman

I think this thread is another good illustration of why it's best to build a printer that "just works" rather than having to rely on firmware to compensate for all the craziness. However, I am of course aware that many people start with a bad kit so they are maybe stuck with it.
Getting back on topic, there isn't an answer that works for everyone. In my case, for 99.9 % of the time, I never have a need to use baby stepping. But around 0.1% of the time,for whatever reason, the first layer doesn't start well. That's when I use baby stepping. Admittedly I don't care what the actual amount is but equally, I only want to use it for this 1 in a thousand print.
That's how it used to be when it was first introduced. Now (at the request of other users) it is maintained across prints and I have to remember to cancel it.
But I'm in the minority so I put up with it. There is no point in demanding that the firmware should be changed when there is no universally acceptable solution. Personally, I'd like it put back to how it was when it was first introduced, but that isn't going to happen because it doesn't suit everyone else.

dc42

Does anyone know exactly how baby stepping does behave under Marlin? Is it the same in Prusa's version of Marlin as the standard one?

The only time I use baby stepping is when I start a print and I notice that the first layer is being laid down too thick or too thin. This mostly happens on my SCARA printer, because it prints on the desk in front of it, so if I move the printer a little then the height map is no longer accurate.

deckingman

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

Does anyone know exactly how baby stepping does behave under Marlin? Is it the same in Prusa's version of Marlin as the standard one?

I don't know the answer but that would lead to a more pertinent question which would be "are all users of Marlin happy with the way it works for them?" In any case, should RRF adopt a way of doing things just because that's the way that Marlin does it?

A Former User

IMO babystepping is a runtime live adjustment, and unless explicitly stored should be cancelled when the machine is homed and the machine coordinates are set.

If anyone needs a permanent or semi-permanent adjustment this should be adressed through G10 and tool or work specific offsets to account for lasting changes in tool or bed surface (the latter would be akin to a fixture in the cnc world, and a fixture should have a known work offset.

It would be convenient if you could store the baby stepping offset to a tool or work offset by means of M500 or equivalent.

burtoogle

For me, the current behaviour is exactly right. On any given day, I may need to adjust the z height a little but once I have done that it, generally, does not need to change for subsequent prints so I like that the baby steps persist across homes and do not return to zero unless the Duet is restarted.

A Former User

I think we might have to distinguish between convenient and right, you're essentially advocating undocumented configuration.

If my printer has Z height of 200 in the config and its suddenly only 199 that should be reflected in the configuration. If I put glass on top of the bed, my Z height is still 199 but my work will be offset by 3mm.

Having it convenient may well work for one guy with one machine, but on any other scale there needs to be structure.