Suggestion for change to implementation of baby-steps
-
@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.
-
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?
-
@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.
-
@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. -
@deckingman it's relevant because it helps understand your workflow.
If you needed baby stepping once and was to print again immediately after, you'd expect the subsequent homing to deliver a different Z position (accurate, rather than needing bs'ing) than the homing that happened as part of the previous print?
-
Alright, here's my workflow.
Bltouch is calibrated and usually the first layer is perfect. Occasionally it might be a little too close or a little too far away. Not sure why, it could be temperature differences, or even extrusion factor for each spool. I use a skirt around the part as a judge of what the first layer looks like and use a few baby steps either way to tune it in.
I don't want them to persist, because the next time the printer homes before a print it could be slightly different trigger height again and I'd just have to baby step it anyway.
This is what I don't understand about your proposal, you argue that when a printer is under development you are constantly adjusting it so you want the baby steps to be permanent adjustments, but if it's constantly changing, don't you have to constantly adjust the baby steps anyway?
For me, 9 times out of 10 the first layer is fine with no adjustment, so why would I want to make that 1 out 10 time adjustment permanent? It would just throw off the other 9 times.
I get the live Z adjust appeal for tuning your trigger height once, but isn't it just as easy to do the one time trigger height calibration?
-
To add to Phaedrux how much of a printers life is spent in heavy development for the average user? It simply doesn't make sense to default to persisting a feature to make development convenient when the proposed solution will work just fine. I suspect the actual implementation may not use z-probe offset, but what we call it doesn't really matter as long as there is a simple method for saving it to config-overide.g and it can be automated by simple means if needed.
-
@phaedrux I see how my proposal seems self contradictory. When my printer is under active development, the z offset does change often, but not every print. It'd work fine for a little while, I'd change the printer, and stuff could move, so I'd adjust again. I would often not permanently affix certain parts and overnight something could shift or sag.
This approach allowed me to iterate very, very quickly. I'd use vhb tape to hold many things because of its incredible strength, but it is not perfect, things can settle over time. I'd definitely not trade that practice for having to design things that need screw holes or mounts and them having to be designed with enough strength AND clearance, etc. The mechanical design is much harder then creating something with flat surfaces that can just be slapped together.
-
@gnydick said in Suggestion for change to implementation of baby-steps:
@deckingman it's relevant because it helps understand your workflow.
If you needed baby stepping once and was to print again immediately after, you'd expect the subsequent homing to deliver a different Z position (accurate, rather than needing bs'ing) than the homing that happened as part of the previous print?
I'm not sure that I fully understand your question so to clarify..... If, for whatever reason the first layer of a print wasn't going well, I have 2 options. Option 1 is to abort the print and start again. This will re-home the printer using the same Z offset that is in my configuration file and it will work. I never need to change the Z offset unless I change hot ends which of necessity means re-positioning the switch that is indirectly attached to the nozzle. Option 2 is to continue with the print but to use baby stepping to adjust that first layer as a one off adjustment for this print.
When baby stepping was first introduced, it did not persist in any way so I could start another print straight away and it would start by homing to the original Z offset as defined in my configuration file. Bear with me on this because I use baby stepping very rarely so I might be wrong, but I believe that now, once it has been applied baby stepping will persist until the power has been cycled. If that is the case (I'm fairly sure it is) then if I had used baby stepping and then if I want to do another print, I have to remember to remove the baby stepping that was used as a one-off change for the previous print, before I home the printer again and start another print. This is why it is so important to me to see what baby stepping (if any) has been applied and to have it visible on the UI. So that I can apply the opposite baby stepping to cancel it out before I start another print. Then I can get back to simply homing with the Z offset that is in my configuration file and which works for more than 99% of the time.
So my preferred option would be to have baby stepping reset at the end of every print and not persist in any way, but I accept that I seem too be in the minority so I'll live with it as it is.
However, I would not be at all happy if baby stepping was hidden or if it persisted by making permanent (or even temporary) changes to my configuration files, as you seem to be proposing. The only reason why the configured offset should ever need adjusting is if I physically disturb the switch and thus change the trigger height. I have developed a very good method for setting the offset in that eventuality, which works extremely well on my machine.
-
@dc42 said in Suggestion for change to implementation of baby-steps:
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.
For me all works fine, just read this to understand better, and in my head after using duet/RRF2.03 for ca. 3 months, my vote would be:
-> 1) -> Isn´t everybody able to do this by putting "M290 Z0 R0" in home-z & home-all (& maybe calibrate-z & so), or am I getting it still wrong?
If I got it right, maybe just highlight that big and fat in the g-code-wiki? And/or include it in the config.g-generator as standard? That way it stays optional? Come on people, it is one line of code... Just a suggestion for avoiding the wave that might come back here if it is changed...
So +-0 from me here-> 2) -> remembering how much I struggeled the first weeks to get going with duet/RRF/hardware-issues etc. I assume it can help (even if I have the slight feeling this could be done with a macro?)!
So +1 here -
