Baby Stepping.. can it, or can it not be permanent?
-
@arhi said in Baby Stepping.. can it, or can it not be permanent?:
..well the "different filament" - you put your z-offset in per-filament confing and you are golden
Yep. 'Assuming' one is using it. Neither of us know the OP's complete workflow ...
as for different plates, if you are probing a surface (and these days isn't everyone? bltouch, piezo, ir, inductive, capacitive...) the thickness of the plate is irrelevant ... if you don't and have some microswitch Z connector for the holder then again, per-plate config file with offset there.
What you say is mostly true, but I think you missed my point - we sometime are working at the edge of a probe's accuracy, and find that it's not enough and need Baby Steps to get it right.
Remember, this person is running in a production environment with many hands, including KIDS interfacing with the machines. He needs a quick and easy solution, and personally, I think he has a point that it should be baked into the Firmware as an option, defaulted to off.
That's my take on things, of course, not single way is the only way... good thing RRF3 comes with variable code support
It sure is!
We definitely need many paths, something that RRF is much better than it's rivals at providing. Now if only I was a competent programmer ...! -
@PuterPro said in Baby Stepping.. can it, or can it not be permanent?:
Z Baby Steps came about as a fudge factor for us trying to do hyper accurate things with less than hyper accurate machines. We're sometimes trying to do nano scale stuff with micro scale tools.
As a very long time user of RRF firmware and Duet products, I distinctly remember the rationale for baby stepping when it was first introduced. Which was to make small, non persistant adjustments on a "per print" basis if, for whatever reason the first layer wasn't going down as expected. The rationale has always been that if the Z probe needs the same offset correction for every print, then change the offset in the configuration file to make it persistent. On the other hand, if there is variability from print to print and the offset needs to be adjusted often, then use (non persistent) baby stepping.
I'm having a hard time understanding why people want to save the value of something that needs to be changed frequently. If baby stepping is made permanent, how does that help in all the use cases that people are stating? If it needs to be changed per filament, or per build plate or per "whatever", how does making the value permanent help?
-
@deckingman said in Baby Stepping.. can it, or can it not be permanent?:
... how does making the value permanent help?
'Permanent' is a strong word
I would use 'persisted'.Some of us already do it, making small persisted Z adjustments once in a while, except that the current process is tedious, having to go through editing and uploading a config.g file.
Supporting an option for the duet to remember the last babysteps adjustment, as it does with mesh data, will eliminate that hassle for some of us.
As for the people that don't want the Z settings to be persisted, I am sure that this option will not be taken away from you.
-
@zapta said in Baby Stepping.. can it, or can it not be permanent?:
'Permanent' is a strong word
I would use 'persisted'.The thread title says "Permanent" - that's what I was replying to.
As for the people that don't want the Z settings to be persisted, I am sure that this option will not be taken away from you.
Personally I don't really care - I wasn't thinking of myself because I never use baby stepping.
-
@deckingman said in Baby Stepping.. can it, or can it not be permanent?:
If it needs to be changed per filament, or per build plate or per "whatever", how does making the value permanent help?
I agree that Baby Steps came about as per print adjustment, but I have to politely disagree with your conclusion.
Like everything in this 3D world, as times move forward, things must be free to advance. RRF3 is a far cry from those early days with thousands of changes and tweaks from it's introduction.
When Baby Steps were introduced we didn't have things like magnetically held interchangeable tools, print beds held magnetically with PEI textured steel sheets, as well as all the myriad of printer types we have now. I mean, who HAD a laser that could be switched in??!?
As someone who has such a lovingly built and amazingly personally engineered machine, I'm surprised you aren't more receptive to this small change. You've had to have celebrated many times as RRF matured and fixed problems you had with your setup, or added a new easier way to accomplish something, sometimes fixing something you didn't even know you had a problem with!
I see how some setups could benefit from the small addition of a software switch enabling the change to be saved past reboot or shutdown. With it defaulted to not saved, there's no impact for the average setup, but there's another tool in the arsenal for someone who needs it for their setup.
IMHO
-
A side note for persisting data on the Duet, I wish that the duet would store its state, caches, etc in a separate and more 'transient' directory and keep the /sys directory the way the user set it up.
This will make it easier to version the configuration (I am using git) or change or clone a board.
-
@PuterPro said in Baby Stepping.. can it, or can it not be permanent?:
When Baby Steps were introduced we didn't have things like magnetically held interchangeable tools, print beds held magnetically with PEI textured steel sheets, as well as all the myriad of printer types we have now.
Are you saying in the above statement, that there are now more instances where baby stepping might be used? If so, I agree. But I still don't get why baby stepping should persist? If there are more instances where baby stepping has to be changed, then surely that is more reason for it to be non-permanent?
As someone who has such a lovingly built and amazingly personally engineered machine, I'm surprised you aren't more receptive to this small change.
Thank you for the compliment. It's not about being personally receptive or otherwise. As I said in a previous post I never use baby stepping so it's largely irrelevant to me. I don't use automatic bed levelling, mesh compensation, orthogonal axis compensation, non-linear extrusion or very many other features either, but I understand that there are very many machines which do require these features.
I'm just trying to understand why people want something that has to be changed regularly to be made to persist or be permanent.
An analogy might be the extrusion multiplier for example. This is something that might be used on a per filament basis to compensate for varying diameter from one reel to the next. Should that be persistent or permanent? If so, then the extrusion multiplier set for one reel of filament would be used for every reel of filament, in which case it would need to be changed whenever filament is changed. So if it has to be changed per filament, how does making it permanent help? If it is used, then it has to be set or changed every time the filament is changed, regardless of whether it is permanent/persistant or not. The same applies to baby stepping. If it has to be changed per filament, how does making it permanent help? It still has to be changed.
-
@zapta said in Baby Stepping.. can it, or can it not be permanent?:
A side note for persisting data on the Duet, I wish that the duet would store its state, caches, etc in a separate and more 'transient' directory and keep the /sys directory the way the user set it up.
This will make it easier to version the configuration (I am using git) or change or clone a board.
looking to linux and /bin /etc /usr/bin and so on doesn't sound like a bad idea, but it would be a big change, so not for 3.01. could you work around it with .gitignore ?
-
@bearer, .gitignore would not avoid the spam in directory diffing (card vs repository). Same goes for copying a card for another printer or deleting the duet's transient data to get to a known state (which files to delete and which files to keep?).
I am not 100% but IIRC, the www directory is kept clean of transient files.
-
@zapta said in Baby Stepping.. can it, or can it not be permanent?:
.gitignore would not avoid the spam in directory diffing
it would if you used git diff? as for copying goes %#¤ in #"%& out and getting to a known state, nuke from orbit, pull fresh duet stuff from web and clone your git stuff after?
But I do agree, cleaner separation would be nice.
-
@deckingman said in Baby Stepping.. can it, or can it not be permanent?:
The thread title says "Permanent" - that's what I was replying to.
Yes, you are right, it's from the topic.
I believe that 'persisted' captures more accurately the use case of "save and use it in following sessions until I will set a new value".
-
If users of baby stepping wish to have a one-click method to save baby stepping values, here it is:
First, you create a template-config.g This is where your master config.g that you would normally edit and contains your normal settings lives. It has no babystepping command.
Now, you create a real config.g in the sys directory that points to the template-config.g with an M98.
We now create a series of macros. In each of those macros you have something that looks like this:
; filename: +0.02.g M28 config.g M98 template-config.g M290 S0.02 M29; filename: +0.04.g M28 config.g M98 template-config.g M290 S0.04 M29; filename: -0.02.g M28 config.g M98 template-config.g M290 S-0.02 M29etc., and lastly:
; filename: reset.g M28 config.g M98 template-config.g M29Voila! Now you just have to select the amount of babystepping you have currently applied and wish to make permanent! It will be permanent until the next time you run one of these macros, and you can reset it permanently too. To make normal everyday changes to your config, you can simply change the template-config.g.
To be clear, this is a joke. To make this work for real you'd need to use M505 to set a different directory, because calling M98 would write the entire contents of template-config.g to the main config.g, precluding the ability to make easy changes! So instead, we would have to write a new override-override-config.g in a new directory that we then point the firmware to in the main congfig.g with our series of convenient macros.
-
@bot said in Baby Stepping.. can it, or can it not be permanent?:
If users of baby stepping wish to have a one-click method to save baby stepping values, here it is:
Compare with Prusa https://youtu.be/2wh0bKPOI_o?t=43 , it even has the test pattern built in.
(just swapped nozzle to 0.5mm and had to go through the routine of babysteps adjustment, config editing, and config uploading).
-
@zapta Presumably your nozzles are slightly different lengths which is the reason why you need a different probe/nozzle offset for each one. In which case, why go through the process of adjusting baby stepping every time you change nozzle? Why not make a note of the offset once established, and use a macro for each nozzle to set the offset? Then when you change nozzle, instead of playing around with baby stepping, simply run M98 P"05Nozzle" or whatever name you decide to use.
Presumably you use different profiles in your slicer for each nozzle. If so, then you could include a call to the relevant nozzle offset macro in the slicer. So you never (or rarely) have to use baby stepping. -
@deckingman said in Baby Stepping.. can it, or can it not be permanent?:
I'm just trying to understand why people want something that has to be changed regularly to be made to persist or be permanent.
I do see the value of the suggested feature. Especially for values that change regularly. I find myself babystepping down a bit for each print of the roll I am currently using. Yes, I need to compensate for that in the H parameter of G31 command, but call me lazy! (does everyone has to lookup if it needs to be added or subtracted?). What's wrong with a button that sets the default height compensation in config.g based on the currently set babystepping? I would like it for sure!
-
@DeltaCon said in Baby Stepping.. can it, or can it not be permanent?:
I do see the value of the suggested feature. Especially for values that change regularly. I find myself babystepping down a bit for each print of the roll I am currently using.
I'm sorry but I still don't get it. If you have to change baby stepping for each print, how does making it permanent help?
Scenario 1. With baby stepping as is (non permanent), you start a print, then adjust baby stepping. Repeat for the next print.
Scenario 2. With "permanent" baby stepping, you start a print, then adjust baby stepping, then save it. But you still repeat that process for the next print because you say "I find myself babystepping down a bit for each print........"
So all you are doing in scenario 2 is saving the value that you are going to change anyway next time you do a print. Why?
-
@deckingman said in Baby Stepping.. can it, or can it not be permanent?:
So all you are doing in scenario 2 is saving the value that you are going to change anyway next time you do a print. Why?
Because "change it next time" is actually quite often several attempts down the road.
Meaning, print A didn't start right because it took a few moments to get babystep correct, and parts of layer one are already blown. So, I have to stop, and sometimes estop and try again. Maybe for two or three attempts.
And, if I did reset, babystepping is gone, and I guarantee I will not realize that, and there is another blown attempt.
Once I've gotten through a number of starts of print A, and it finally "takes", it will be hours or days before I move on to print B. As part of setting up for print B, I'll check everything, and adjust settings, to get it started. Including zeroing babystepping.
And, just generically, I'm in the camp of "don't lose things across restarts". Babystepping or anything else.
-
@deckingman said in Baby Stepping.. can it, or can it not be permanent?:
... why go through the process of adjusting baby stepping every time you change nozzle?
Deckingman, I think that for two reasons I presume, first, I am not that organized and when I need a nozzle I pick one from an assorted bag of nozzles (last switch was from a microswiss 0.4 to a chinese 0.5), and second, my printer is not that stiff and stable that swapping back to the same nozzle will require the exact same configuration.
Myself and many others, on duet and on other firmwares, use babysteping to compensate for imperfections in our mechanics and processes, just the same as we do with mesh based bed leveling (I now run an automatic one, for the print area only, on every print). It would probably be less necessary in a more perfect world.
-
@zapta said in Baby Stepping.. can it, or can it not be permanent?:
@deckingman said in Baby Stepping.. can it, or can it not be permanent?:
... why go through the process of adjusting baby stepping every time you change nozzle?
Deckingman, I think that for two reasons I presume, first, I am not that organized and when I need a nozzle I pick one from an assorted bag of nozzles (last switch was from a microswiss 0.4 to a chinese 0.5), and second, my printer is not that stiff and stable that swapping back to the same nozzle will require the exact same configuration.
Myself and many others, on duet and on other firmwares, use babysteping to compensate for imperfections in our mechanics and processes, just the same as we do with mesh based bed leveling (I now run an automatic one, for the print area only, on every print). It would probably be less necessary in a more perfect world.
Yes I get all that. I don't have any problem with people who want to use baby stepping and I fully understand how it could be useful.
It's just the logic behind the reasoning that the more frequently something gets changed, the more necessary it is to save the value. In my book, the opposite is true.
-
I wonder how much of the precious memory on the duets are used for features that are catering to people whose printers are so poorly built that they need to calibrate it every single time they print. How much of the development time put into RRF was for such features?
Babystepping works as it does now. Config-override exists for you to save settings, but not babystepping. Figure out a way to save your babystepping values with that you have now!
It's so frustrating that some of us jump through hoops, spend tens of thousands of dollars or euros, build a machine that is rock solid, but yet we have to deal with the onslaught of features and feature requests from people who can't be bothered to edit one line in one file?
We should not cater primarily to the lazy folks who can't be bothered to perform extremely simple actions.
*not actually a robot
