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.
-
@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.
-
@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?
-
@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...
-
@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.
-
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?
-
@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.
-
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.
