Suggestion for change to implementation of baby-steps

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!

deckingman

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

I view it as an "operator override" for that one job, that should not persist.

gnydick

@bot what's in your mind is not all of the cases because that's how it best fits your needs, and because of the way it's implemented it fits that way of thinking about it.

We can't really debate how something should work from the single use-case POV.

@dc42 The trigger height is not fixed. There is a probe that is captured by two nuts that you slide up or down. Every machine is it's own individual and the height of perfect calibration can vary. In fact, the latest design of their probe includes a built in thermistor so it can try to adapt for temperature variances' impact on sensing.

I don't think it really matters what type of sensing is used to home. If we really want to discuss this seriously, lets draw out some proper logic diagrams that cover all of the cases. I'd be happy to start the process considering I started thread.

I don't intend to be rude to anyone, but we need to really approach this with an engineering/project management mindset, so saying things like "it works for me, therefor we should leave it" or "the words baby-steps just implies a certain functionality" are not helpful or valid. I would appreciate it if those kind of replies were no longer posted so we can seriously collaborate on this, otherwise, if we can't keep the noise down, I would propose that @dc42 and I, and select other members who can treat it as a design discussion take it to a private place to discuss.

burtoogle

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

so saying things like "it works for me, therefor we should leave it" or "the words baby-steps just implies a certain functionality" are not helpful or valid.

Well, I said "it works for me" and that is helpful and valid because it makes it clear that there are people who like how it works right now. I'm probably not the only Duet user who is happy with the existing behaviour. Why should that opinion not form part of the discussion and be taken into consideration when deciding if/what should be changed?

A Former User

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

M291 Z0 R0

M290 Z0 R0? (https://duet3d.dozuki.com/Wiki/Gcode#Section_M290_Baby_stepping)

Yeah - my autism rules (just kidding: wanted to put it in my g-code and looked it up before )

I have put this now in my home-all & home-z because I want it to be cleared every time z axis get´s rehomed...

gnydick

@burtoogle because we (I) want it to work for everyone. Also, because we already know it works for many people, otherwise this conversation would have been started long ago.

It IS useful to know that that it works for you in the sense that it's a data point that is needed, but that sentiment has been posted many, many times, and it's just noise at this point. A forum is not the best place to have this kind of discussion.

I'm sorry if I made you feel anything other than positive, that wasn't my intention. I'm just trying to keep focus.

Phaedrux

Can you maybe describe how the procedure for calibrating your z probe offset in Marlin works and how the live z adjust plays into that.

From what I gather the live z adjust would be the same thing as if baby stepping in rrf altered the g31 trigger height directly.

One thing to keep in mind is that the duet does not have an eeprom like the 8bit boards. It's all config files and gcode commands. So if you want to save a variable for use across power cycles it would need to be written to config-override.

Basically what I'm hearing is that you find editing config.g to alter the g31 command too tedious and just want to use baby stepping to do that for you?

gnydick

@phaedrux that is one aspect, and if that's all it was, i could probably live with it. But there's more to it.

The fact that bs'ing doesn't have the same behavior all of the time depending on circumstance, is really the big driver for me. You can read the plethora of accounts I've written about homing, bed crashing, etc., all because the bs value is not really a first class configuration. It's a work-around that isn't fully baked.

I fully endorse @Danal 's way of thinking about this, except for one thing. This is additive manufacturing, not subtractive. An offset-per-job IS the way of doing things when you're replacing the bar stock or billet, etc. for each job and they may be slightly different. It is ABSOLUTELY necessary to reset any offsets/baby-stepping etc., otherwise you get a tool-head crash, and that's PAINFUL.

In additive manufacturing, your coordinate space is treated inversely. The machine is your starting point, not the material. This is why it does make sense to persist the offset, live-z, baby-steps. It should be correct the next time. The only time it's not that I can think of is a) switching from PETG to PLA and you need more squish, but still, I'd persist the value. and b) your machine gets out of whack. and in that case, I'd still persist the value. If it's correct, great, less work for next time, if not, well then I'm turning the dial anyway. But no matter what, I'm never going to crash the bed because I forgot to clear baby-steps after homing or forgot to put it in the scripts, etc. because the firmware doesn't know where Z0 actually is.

So, it seems like there should be 2 modes. For subtractive manufacturing modes, bs gets reset as aggressively as possible/reasonable. And for additive manufacturing modes, should be persisted.

A Former User

I would really encourage not differentiating between modes for the sake of convenience.

How is it any different that you should have to save your settings than having to tighten up the double nut on your z-limit adjustment screw? Sure you can adjust and tweak it without locking it down, but when you have it dialed in you tighten down your screws, nuts and bolts and save your settings to avoid surprises down the road.

deckingman

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

So, it seems like there should be 2 modes. For subtractive manufacturing modes, bs gets reset as aggressively as possible/reasonable. And for additive manufacturing modes, should be persisted.

I disagree. I and many others have expressed their opinion that they would prefer it if baby stepping did not persist and was a one off "operator override" (as @Danal so aptly put it), on my additive printer. That's how it was when it was first introduced. I also prefer to have it displayed but you want it to be hidden. But this thread seems to be all about what you want and I'm conscious that by expressing my opinion, I will be accused of "adding noise" because my opinion isn't the same as yours. Your suggestion that you and David go away and discuss this privately, so that dissenting opinions cannot even be put forward is both selfish and disrespectful if you don't mind my saying so - even if you do mind, I'll still stay it.

mudcruzr

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

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

I view it as an "operator override" for that one job, that should not persist.

+1 for this from me too.

dc42

Would the following satisfy most people?

Change it back so that homing Z or bed probing (i.e. any G30 or G1 S1 Z command) cancels the current babystepping.
Add a new command to add the current babystepping into the Z probe trigger height, save the new trigger height to config-override.g if it has changed, and cancel babystepping.

Then for users who don't want babystepping to persist past the current job, it won't. Users who do want it to persist can add the new command into their stop.g and cancel.g files.

deckingman

@dc42 Sounds good to me.

A Former User

Elegant solution offered.