Baby Stepping.. can it, or can it not be permanent?

[Danal]

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

[zapta]

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

[deckingman]

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

[bot]

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.

[DeltaCon]

@deckingman said in Baby Stepping.. can it, or can it not be permanent?:

Scenario 1. With baby stepping as is (non permanent), you start a print, then adjust baby stepping. Repeat for the next print.

Only if you are homing again you will have to readjust. Making it permanent you do NOT have to readjust.

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........"

I find myself babystepping down for each print, because I cannot make it permanent. You have it the wrong way.

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?

No, I do NOT need to change anyway if my value gets permanent.
I think you need to look at it not as permanent babystepping, but as an easy way to dial in the H value in config.g. Nothing is easier then looking at a result, adjusting, looking again, and when it is spot on, press the button and it is set. After pressing the button, babystepping is at 0 and no need for adjustment until you change material, adjust flowrate or esteps, or do something else that requires evaluation of your nozzle offset.

[DeltaCon]

@bot said in Baby Stepping.. can it, or can it not be permanent?:

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.

A little respect please... Not anyone uses their machinery the exact same way you do so yes, other people have to be catered too. The suggested option is a nice one, even if you do not understand that. RepRap is supposed to be the most userfriendly firmware, no?

[Danal]

@bot said in Baby Stepping.. can it, or can it not be permanent?:

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?

Did you know? DC42 himself calibrates his Delta for every print.

[bot]

@Danal dc42 also prints with a polar(scara?) printer onto a desk and barely has to adjust the calibration of it. Pretty sure he basically does whatever he pleases, and that's fine. He manages to get by without babystepping permanence!

[bot]

@DeltaCon but you're being offered, for basically free, a firmware/software platform that is perfectly adequate to achieve what you want. You refuse to make one simple change to one file, and are demanding that the creator spend his time creating an amendment to the system that works fine?

Please, have some respect for the work you've been given. You bought electronics, and were given an amazing set of software for free.

[deckingman]

Let's go the whole hog. Why stop with having a button to make baby stepping permanent instead of editing one value in config.g? Let's have another button that will set the steps per mm for extruders after we've calibrated them - one button for each extruder ideally. Then another button when we tune firmware retraction to save us editing config.g for that. The same for pressure advance and all the other things we have to tune. With enough buttons, we need never open config.g at all.

I'm sure many people would be delighted if DC, Chris Ham and all the others spent their time implementing that. Personally, I'd rather they spent their time on implementing basic functionality such as heater tuning and end stop/motor combinations on expansion boards, and perhaps restoring the step pulse frequency limit to what it was some versions of firmware ago. But maybe I just have my sense of priorities all wrong............

[Danal]

I always try to debate ideas, not people. This discussion turned a corner, and I regret my one post down the path of commenting directly on a person.

Back to the idea of persistence of babystepping: I am OK with it, and in fact, find it mildly desirable.

At the same time, it is not so important to me, either way, to stay in a high-friction discussion.

[zapta]

@Danal said in Baby Stepping.. can it, or can it not be permanent?:

... a high-friction discussion.

The Corona lockdown did it to us.

[PuterPro]

@zapta said in Baby Stepping.. can it, or can it not be permanent?:

The Corona lockdown did it to us.

Indeed! LOL!

Sheeze, I go away for one day from a polite discussion someone posted about a request for a feature change (WOW SHOCKING!) and I come back to a barroom brawl.

Everyone needs to step back here and relax. This isn't the WWF, remember to be polite when you make your points, I'm talking to the new people AND the regulars as well, who should bloody well know better and should set the tone.

NOW, about this recommended change.

My two cents. Rather than pick apart and quote all the various points that have been made, I feel this is close to the right answer:

@zapta said in Baby Stepping.. can it, or can it not be permanent?:

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".

For example, one real "Use Scenario" that I think addresses the main sticking point for those in the "leave it be" camp.

There are often times (particularly in a small production environment like the OP posted) when a machine will be setup a certain way that's a bit different than it's normal config, where baby stepping is used to quickly get it right. This config might persist through 5 or more prints, or even days, but THEN be changed back to normal.

Having the ability to make a SEMI-permanent change that survives reboot and/or power downs makes sense. Especially if easily reversed to revert to original, or a new setup.

This is only one example, I'm sure people will find more. If the setting is defaulted to off, it's no big deal for everyone else.

A couple other thoughts ...

@deckingman said in Baby Stepping.. can it, or can it not be permanent?:

I'm sure many people would be delighted if DC, Chris Ham and all the others spent their time implementing that.

I get your point, but I would point out that is exactly what their job entails, deciding what's a valuable feature and what isn't, as well as it's priority.
You listed several things you'd like implemented, does that mean the OP doesn't have the right to request his? Someone elses' needs and wants should be honored too, eh? It's OK for people to request a feature change that you don't use or need. I don't have a CNC or laser but I'm open to changes they need that make no sense for my setup. Who knows a multi-tool setup might be in my future, LOL.

And to address a point I felt was a bit of the same subject,

@bot said

I wonder how much of the precious memory on the duets are used for features .... How much of the development time put into RRF was for such features?

"Software ALWAYS expands to fill whatever amount of memory is available."

You might as well complain about being stuck at home, or the weather! LOL! Software grows.
I feel you were a bit overaggressive here. You've made more than a couple requests for new features, some of then quite involved for the team to implement but you went off on a simple request for the addition of one switch on an existing feature.

How much memory space do you anticipate that would take compared to some of your requests?
The amount of money and time you've spent has ZERO bearing on this thread or the priority of this request vs your request(s), and frankly was rather elitist.

I don't mean to "call you out" here, your contributions to this Forum are great, in fact you've helped me in the past, and you're someone I admire, but you really should chill a bit, eh?

[bot]

@PuterPro I could chill out, sure. I don't usually make actual requests, I just make observations, discussion, and perhaps suggestions. If I make a direct request, it's usually followed by a sum of money, because otherwise I'm personally not owed anything.

And usually if I'm requesting something, it's something that has zero possible way of achieving currently, and may benefit other people. This request, beaten to death, is already achievable with the current behaviour.

You change your print surface, and find that babystepping of +0.08 mm is good? Add that single line to the end of your config.g file. Done. How is this so difficult? Why must it be its own dedicated gcode? If you want an easier way than editing config.g, add a line at the end of your config.g that runs a macro with M98. Every time you want to permanently change the baby stepping, perform this series of commands:

M28 mybabysteppingmacro.g
; do your babystepping
M29

Done. It will save your magic sequence of babystepping settings to load every time you boot.

[Topher]

I don't know if it been mentioned above but what I find really annoying with the Baby Stepping feature is when I have printers on the bench for repair for testing. Just quickly fixing something and now your Z is out, use baby stepping to temporally correct it, then run a test print. Come back to run another one and completely losing track of the Baby Stepping. Also, when you've got 10 different things on the go around the print farm like I usually do, you tend to forget if you reapplied the baby-stepping after running a print, you look at the value listed within that setting and the values are piling up if you've run a few prints so you really have no way of knowing unless you're better at keeping track than I've been and I'm horrible at multitasking lol

[zapta]

Clearly, the schism between the two schools of thoughts is too deep and we have only one option moving forward. That is, forking the RepRap firmware into two code lines: RRF Persisted BS, and RRF Volatile BS.

I don't see any other viable option.

[bot]

@zapta Hahaha. I concur.

In all seriousness, the issue LeckieTech mentions is because dc42 changed the behaviour for people who complained that the babystepping was reset on homing.

Now, the babystepping value is retained through homing, but the babystepping amount is also added to the M208 homing location for the Z axis. So, the offset indeed does add up if you don't manually cancel the babystepping offset before homing.

So, the current behaviour is problematic, but the way to fix it is to revert it to the previous behaviour, where it is completely reset after homing, and all set offsets and M208 values are respected exactly as they are in the configuration.

[OwenD]

Based on further reading of this thread I have revised my code to suit all sides of the argument

;save_babystep.g
if move.axes[2].babystep !=0
      while(true)
            M291 P"Save baby stepping?"  S2
            echo "Shouldn't you edit config G instead?"
            echo "no, I want the firmware re-written"
            echo "but why?, just use a macro"
            echo "because I want it!"
            echo "fine... go ahead"
       

[bot]

@OwenD omg I totally missed that before! Great! hahah. I guess mine is the RRF2 version.

[deckingman]

@PuterPro 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?:

You listed several things you'd like implemented, does that mean the OP doesn't have the right to request his? Someone elses' needs and wants should be honored too, eh? It's OK for people to request a feature change that you don't use or need.

Woah, hold on my friend. There is a world of difference between adding something that makes life slightly easier than editing one line of gcode, and restoring basic printer functionality to the firmware, which are the things that I'd like to see implemented.

The current state of firmware is that nobody who has a heater connected to expansion board can PID tune that heater. That's what I call basic functionality. Nobody who uses a mixing hot end with Duet 3 can utilise it fully because the step pulse frequency has been reduced, which limits the extruder micro-stepping. Again, that's not a case of making something a little more convenient, it's basic functionality which used to exist but now does not.

I changed over to Duet 3 last August to help the Duet guys by having my machine in their stand at the TCT show and I spent hundreds of hours testing pre-beta firmware for them. But I haven't been able to PID a hot end heater connected to an expansion board since then. It will be 3.02 at some time in the future before I ever will be able to do it. But I'm not whining about it. It's the price one has to pay (although if I'd known the full price, it's fair to say that I would not have made the conversion but it's too late now to go back to Duet 2).

I'm working on new hot end and I've had to tune heaters dozens of times. To do so, I have to disconnect the heater and thermistor from the expansion board, connect it to the main board, edit my configuration, run the heater tune, put my configuration back to what it was, disconnect the heater and thermistor from the main board and re-connect them to the expansion. And people think that editing one line of gcode is inconvenient!

The point I tried to make is that the more time the developers spend making life a little more convenient than editing one line of gcode, is time that could be spent restoring existing features that used to work but now don't. But I guess this will all fall on deaf ears and it'll be another year before I can get my printer working as it used to with Duet 2 because the developers are busy implementing "feature" to make life a little easier than editing one line of gcode now and then.