Suggestion for change to implementation of baby-steps

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.

mudcruzr

That'd work.

gnydick

@dc42 that's no better. It doesn't solve any of the problems I mentioned about having to remember things, having to add code to the stop script is no different than having to remember to add it to the home script. All this change is doing is moving the pain from one place to another with no reduction in complexity.

Please, think about my proposal and give it some time. Go look at Prusa and play with the Live-Z.

additive mode - persist baby-steps, do not change the Z position on screen

subtractive mode - never persist baby-steps, do change the Z position on the screen

That, I believe will work for everyone. Yes, it's a paradigm change, so it takes some effort and will to really give it a fair chance, but I think it's worth exploring. This way, there is no guesswork. No custom script entries. It just works.

A Former User

I'm sure it could be added to the online RRF configurator with a proper explanation as well, so the majority will be able to make an informed decision, and choose between clarity or convenience.

dc42

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

@dc42 that's no better. It doesn't solve any of the problems I mentioned about having to remember things, having to add code to the stop script is no different than having to remember to add it to the home script. All this change is doing is moving the pain from one place to another with no reduction in complexity.

Please, think about my proposal and give it some time. Go look at Prusa and play with the Live-Z.

additive mode - persist baby-steps, do not change the Z position on screen

subtractive mode - never persist baby-steps, do change the Z position on the screen

That, I believe will work for everyone. Yes, it's a paradigm change, so it takes some effort and will to really give it a fair chance, but I think it's worth exploring. This way, there is no guesswork. No custom script entries. It just works.

@gnydick, you have rejected my proposal even though it would require you to change only two files (stop.g and cancel.g). Instead you are asking for me to change the behaviour to something that multiple users have said in this thread that they do not want, with no possibility of overriding it. Don't you think that is a little unreasonable?

gnydick

@dc42 no, i don't think it is, but I don't think they shouldn't be able to override it if they want that ability. I think the reason why people have said they don't want it this way is because they're used to thinking about bs-ing in a certain way. That's why it deserves serious analysis, not whimsical forum threads.

IMHO, no mater which way you implement baby-stepping, if it's not fool-proof and consistent it's not right.

If I think of every g-code I know and how black-and-white it's behavior is, then think about how bs-ing is treated, bs-ing is the odd one out. It shouldn't take a flow chart to figure out how to configuring a z-offset.

Rather than thinking about bs-ing being a probe offset or end stop adjustment or a +/- on a widget, just treat it as what it is -- a Z correction.

I guarantee you, GUARANTEE, the way I'm suggesting will simplify things greatly. But you don't have to take my word for it. Do the analysis by use case and personas. Every single interaction will be much easier to understand, not require flow chart logic to configure, and will have predictable behavior. That is exactly what is missing from all of the other implementation ideas.

Like I said before. I'm happy to do that analysis and present it to the thread.

And, if I'm wrong, we at least potentially have a common framework for how to analyze features.

A Former User

How about you just fix your printer, calibrate it once and forget about babystepping?

gnydick

@bearer that's exactly what I'm talking about... That's not always how it works. What about a printer that is in development and not everything is perfect? And, if the controller is being used in a CNC machine, that's REALLY not how it works.

A Former User

Didn't you just say to default persistent babystepping to OFF for non additive manufacturing, which is what I presume you mean by CNC machine, although ambiguous as it may be?

Whatever, good luck with your endeavors - the only thing we agree on here is the current implementations is not ideal; proposed solution will cover all use cases as opposed to forcing everyone to conform to your adaptation of non ideal machines.

edit: free tip; if you want to be taken seriously for any analysis, don't guarantee the outcome beforehand.. (lol!)

deckingman

@gnydick What about my usage case and many more like me? 99% of the time I don't need baby stepping and I'm not by any means alone in this. In my case, I use the nozzle as a probe and for that, I heat it to 140 deg C to soften any plastic that might have "oozed". This works well 99% of the time if not more. But occasionally, more plastic than usual might have oozed or for some other reason, the first layer isn't quite right. Baby stepping allows me to adjust it as a one off for this print. The alternative would be simply to abort, re-home and start again and it would likely print fine without having made any adjustment whatsoever.

But your proposal is just going to screw up every subsequent print that I do after that because that one-off adjustment would persist. So I'd have to go into some file or other and edit out that temporary "one off" change that I had to make because what you want you do is make that one off change persist.

So by having baby stepping that persists, I'd have to remember that I used it for a particular print, then before I start the next print, I'd have to go into some file or other and edit that change in order to restore my printer to a condition that will work. How the hell is that useful or beneficial?

A Former User

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

But your proposal is just going to screw up every subsequent print that I do after that because that one-off adjustment would persist. So I'd have to go into some file or other and edit out that temporary "one off" change that I had to make because what you want you do is make that one off change persist.

except its not pressently stored in any file is it?

bot

David has proposed a good solution.

I’m actually amazed that he has the patience for this.

This thread is not important. This feature is trivial. I have never once in my 7 years of 3d printing needed baby stepping — I’m sure many others are the same.

This “deep analysis” of a trivial feature is downright ridiculous. Drop it. Whatever David implements, accept it or learn to code and do whatever you want.

David has limited time, and forcing him to sort through this thread and parse any meaning is illogical.

deckingman

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

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

But your proposal is just going to screw up every subsequent print that I do after that because that one-off adjustment would persist. So I'd have to go into some file or other and edit out that temporary "one off" change that I had to make because what you want you do is make that one off change persist.

except its not pressently stored in any file is it?

Why the "except"? You either haven't read what I wrote or you've completely misunderstood.

For sure it isn't presently stored in any file and that's fine - I never said it was stored. But it will be stored somewhere if @gnydick gets his own way, and baby stepping is made to persist for all users who use additive processes like printing- that's what I'm concerned about.

David has proposed a solution for @gnydick's particular usage case but that's not good enough for him - he wants us all to adopt his idea of how it should be. I'm making the point that if that happens, it'll screw things up for many of us.

gnydick

Nobody has demonstrated that they've done the one thing I'm asking, and that's suspending your current opinions for a minute and just hearing me and trying to play out my scenarios.

https://docs.google.com/spreadsheets/d/1aHz4Rch9mFkyqQinQea1o6emhJyhnPzIrRoUygGais4/edit?usp=sharing

Take a look at the FFM scenarios. Feel free to reply here with your scenarios and I will try to capture them in the spreadsheet. Ignore the CNC tab for now as it is extremely incomplete.

Somebody point out to me what is undesirable about any of the scenarios where baby-steps are automatically persisted AND no g-code is needed to be added to any scripts.

I have no desire to argue with opinions that are not quantifiable or qualifiable.

gnydick

@bot Please don't act like a troll. My ultimate goal is to vastly simplify it and save him trouble.

deckingman

I really don't want to play this silly game any more so this is my last shot.

Scenario - printer works fine. No difference in first layer height requirement based on filament type. So no change required between PLA and PET-G. No difference in Z offset based on the time since the printer was last used. So no change required to Z offset based on printer "idle time". One time in a hundred or more, homing isn't quite right and the first layer needs a slight adjustment for this one off print. The choice is either to abort the print and re-home without any adjustment, or apply baby stepping to this one off print. Note that this baby stepping must be removed after this one off adjustment otherwise the first layer height will be incorrect for the next 99+ prints.

I don't suppose any of this will make any difference because this has all been stated multiple times, by multiple users but you don't take any notice. Is your name Theresa May by any chance?

gnydick

@deckingman that totally helps, thank you.

Do you not home as part of your starting gcode? I don't expect everyone to, as I don't, but that's because I use a probe mounted on my carriage to home. I plan on adding a servo to deploy/undeploy it.

deckingman

@gnydick Yes I do home. My start gcode essentially just calls a macro. This macro heats the bed to 40 Deg C. Once that temperature is reached, the macro starts heating the bed to the print temperature but does not wait. The macro then runs homeall which in itself, heats the nozzle to 140 Deg C. Finally, the macro sets the tool temperature, moves the head over the purge "bucket" and waits for all the temperatures to reach their set point.
Essentially, homing is completed before every print and happens during the period when the bed is being heated.
But I don't see how any of that is relevant to your request for persistent baby stepping.