Suggestion for change to implementation of baby-steps

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.

fma

The word baby stepping speaks to itself: this is a relative adjustement (a step). So, each homing should cancel it. As it has been said, there are many other ways to have permanent adjustements. No need to have redundant features.

gnydick

This is really getting into the weeds with different interpretations and ideas of how things are defined and spaghetti semantics....

Let me please try to create a single jumping off point by addressing the recent comments...

@deckingman - I totally agree about the "just works". Your example of rarely needing it is the perfect contrast to where I was up until recently when I needed it for every print.

@dc42 I don't know, I only have the Prusa as a reference.

@deckingman I'm not suggesting adopting the Marlin (Prusa Marlin) way because it's the way they do it. That would just be nonsensical.

@bearer yes, it is a live, runtime adjustment.

So, here's my quantification of the variables...

Set and forget vs. must be aware.
Frequently needed vs. rarely needed.

I don't think "frequently needed" necessarily means "must be aware" and "rarely needed" necessarily means "set and forget". They are orthogonal, so let's not conflate them.

I think we should start by acknowledging that the ultimate desire is to have a machine that is calibrated and just works. To me, that means, "set and forget".

Scenarios...

Great machine, never needs bs except... barometric anomaly, humidity In this case,
a) Switching filament, shitty filament - I'm aware that I will need to most likely undo these changes. Ideally, I undo them the same way I did them, rather than assuming the machine is going to do it for me. These changes are temporary
b) Humidity, barometric pressure, heat, parts expand or contract slightly - Again, I'm aware of this but, these are potentially long lasting conditions that can be thought of as permanent
Crappy machine, needs frequent bs. - In this case, I'm always aware of it and depending on my workflow, I may want it to be permanent or temporary. We all know the feeling of a machine that will work great 20 times in a row, then 100 prints in a row will for some reason need some tweaking. These are times when it's permanent until it's not.

For me, reconciling all of these scenarios in my head means thinking about bs'ing in this way...

It's a feature you need, when you need it. It may be permanent, it may be temporary. You may need to be aware that it has happened or not. By keeping it presently in front of people by putting it in the UI, it complicates how we think about it.

I propose that it is really much less complicated than collectively we think it is.

If there was no bs'ing, then I would be moving my sensor or end stop. Frankly, that's how I'd like to think of this and nothing more. It just lets you "move the sensor or end stop" without having to take out any tools. How that's implemented in the UI and firmware, well, I think the value should be removed from the main table in the UI and presented in the machine properties screen, and whether or not it's a separate setting from the probe offset or not, I don't care, I would just say to make it permanent. The end-user will know when they need to change it or if they need to change it.

dc42

Based on feedback so far, I am inclined to leave baby stepping in RRF as it is. This allows you to have baby stepping persist across homing (the default), or if you prefer to have it cleared by homing (by including ~~M291~~ M290 Z0 R0 in homez.g and homeall.g).

I think it could be very confusing if baby stepping persisted across power cycles. For example, suppose you decide to measure the trigger height of the Z probe. If any baby stepping is active (because you used some last time you printed), then you would measure an incorrect height.

gnydick

@dc42 You're thinking of it as a setting as opposed to a calibration. I will put it like this.

If you're concerned about measuring the triggering height and whether or not you remembered to reset bs'ing, that's exactly what I'm trying to avoid.

On my Prusa, I don't care what the triggering height is as long as it works. Why? Because I don't have to enter numbers into a config. It's entirely empirically driven. You dial until you like what you see and you're done.

I've NEVER caused my Prusa to crash because I forgot to reset live Z. Because it's not something that is context sensitive. It is purely setting a permanent offset because the hardware got it wrong somehow, like environmental factors, pinda probe is too high or too low, etc. It's the fine adjustment part of calibration, 100% predictable.

The logic to persist across homing vs. persist across power cycling is arbitrary. Why would those necessarily be different? I power cycle my printer plenty of times while using it because I'm constantly developing it. If I have a Z offset issue and I'm working on an extruder motor: a) I don't want to tinker with my Z endstop or probe when I'm focusing on something else b) since I am focused on the extruder issue, I can forget about the Z offset issue and I either start a print and it fails because I forgot to bs- or I crash the bed because I forgot to bs+.

If you can make bs 100% predictable without requiring people to remember to add gcode or remove gcode in any part of the workflow pipeline, then I'll be satisfied. That is how it should be. Again, I think the fact that it's in your face on the UI is part of the problem. I can guarantee people look at that number with disdain, thinking to themselves, "shit, my printer isn't calibrated correctly, I gotta fix this" and that causes very many of the perceptions in this thread. So many times people mention "wanting the xyz value to be correct" when it doesn't matter.

deckingman

@gnydick With respect, there are a lot of "I", I'll", "I've" in all of your posts on this subject yet you seem to be ignoring all other usage cases that everyone else puts forward.

Personally, I'd like baby stepping to be as it was when it was first introduced. That is to say, something that I can use on a rare, one off, per print, basis that doesn't and cannot persist in any way to the next print. But that's not the way it is because a large number of people have asked for it to be different. So I accept it and put up with it.

I also like having it there on the UI so that I can see at a glance that a) I have used it for this particular print and b) as a reminder that I'll need to take it out again before the next print because this was a rare one-off case.

David is in the unenviable position of having to decide what is best for the majority of users, so this isn't just about what you want. There are a few other users too.

dc42

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

I've NEVER caused my Prusa to crash because I forgot to reset live Z. Because it's not something that is context sensitive. It is purely setting a permanent offset because the hardware got it wrong somehow, like environmental factors, pinda probe is too high or too low, etc. It's the fine adjustment part of calibration, 100% predictable.

It sounds to me that either the trigger height on a Prusa printer is fixed as far as the user is concerned (i.e. no easy way to change it) so that baby stepping also serves as a substitute for adjusting the trigger height; or that on the Prusa, adjusting baby stepping adds a temporary Z offset and also makes a permanent adjustment to the Z probe trigger height. So when you re-home Z, it clears the baby stepping, but the change in trigger height causes the effect of baby stepping to be carried over.

On machines that use the Z probe to home Z, I can see some logic in converting baby stepping to a change in Z probe trigger height. On machines that home Z using an endstop switch or switches but also have a Z probe, this could get very confusing. Prusa has the luxury of only having to support one type of 3D printer in his firmware.

bot

FWIW, I agree that baby stepping should either be left alone as is, or reverted to the previous behaviour as deckingman suggests.

Baby stepping is for one thing only, in my mind: adjusting z height on a per-print basis to correct for ambient temperature changes.

I also think we should waste less of david’s time arguing about trivial functionality.

Danal

Long thread... may I chime in with some opinions? For those who don't know me, I do a lot of "Home" 3D Print, "Home" CNC, and "Professional" CNC, and I have a lot of strong opinions.

The NIST standard for G-Code is VERY VERY clear about "work space coordinate" vs. "machine space coordinate". In actual use, they are almost always different.
Many "Home" users never realize this because they "Zero" a machine based on a Display of Work coordinates... and they never do anything that causes them to care about the differences.
Duet/RepRap, on the other hand, must cover both home and professional use cases, and where incompatible, must allow the professional case to work properly.

Work coordinates, which are ALWAYS displayed on HMIs, (Human Machine Interface) are NOT the "position of the machine" (or very rarely) due to offsets. Example: On CNC, Z zero is often radically different than the "bed"; Z zero is normally the "upper corner" of the stock being machined. There are numerous offsets, tool length being an obvious one, in addition to the stock.

This philosophy and detail behind "Work Zero is..." was developed through thousands of man years of effort, to cover ALL scenarios, like tool changes, etc, etc.

Same on a 3D Printer, for a slightly different reason. Z zero is not "nozzle gently touching bed". It is "the position of the nozzle that, combined with the layer zero Z specification in the slicer results in a perfect first layer. (Example of 'Layer zero spec': Most slicers default to making layer zero about half again the layer height setting.) One "proof" of this is the traditional "paper" method of Z zero. The nozzle-bed gap is the thickness of the paper.

Given all above, there are extremely well proven reasons to show Z0 on the display such that all offsets are applied between what is displayed and actual machine position.

Persist babystep until the user changes it?

My writeup above referenced the NIST standard and real-world shop-floor practices. This is just my opinion: I would fully expect "end of print" and/or "home" to reset baby step. I view it as an "operator override" for that one job, that should not persist.

Thanks!