Suggestion for change to implementation of baby-steps
-
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.
-
@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.
-
@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.
-
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.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
-
@dc42 Sounds good to me.
-
Elegant solution offered.
-
That'd work.
-
@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.
-
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.
-
@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?
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@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.
-
How about you just fix your printer, calibrate it once and forget about babystepping?
-
@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.
-
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!)
-
@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?
-
@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?
-
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.
*not actually a robot
-
@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.
-
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.
-
@bot Please don't act like a troll. My ultimate goal is to vastly simplify it and save him trouble.
