Baby Stepping.. can it, or can it not be permanent?
-
Cross post wrong me
-
M290 R0 S0 does not work with your save script, because the script changed G31.
-
@yufanyufan said in Baby Stepping.. can it, or can it not be permanent?:
M290 R0 S0 does not work with your save script, because the script changed G31.
Define "does not work"
M290 R0 S0 will set baby steps to zero.
This will stop it being added again if the macro is run again before a restart, but won't restore your original G31 value.
If you want your old values back, don't run the macro.
I can't see a reason for running it twice in any print session either. If you have that much variation then I'd suggest fixing it rather than embarking on endless adjustments to offsets.
If your usage requirements are different to what the code does, then change the macro to suit yourself. -
@OwenD said in Baby Stepping.. can it, or can it not be permanent?:
@yufanyufan said in Baby Stepping.. can it, or can it not be permanent?:
M290 R0 S0 does not work with your save script, because the script changed G31.
Define "does not work"
Not the original poster but I can confirm that weird shit happens
LOL ... how is that for a definition?M290 R0 S0 will set baby steps to zero.
Yes
This will stop it being added again if the macro is run again before a restart, but won't restore your original G31 value.
If you want your old values back, don't run the macro.
I can't see a reason for running it twice in any print session either.This can (and did) happen to me because my printer stays on 24/7 and sometimes you forget that the script was run or you hit it twice by accident or a myriad of other things that can go wrong.
The updated macro I am now using is
; 0:/macros/Save-Z ; This macro adds the current babystep offset to the Z trigger height and saves it to config-overide.g ; ! M501 needs to be in config.g to automatically be recalled on reset. If using multiple filament settings, ; and this is for a specific filament type, recommend placing this yielded information in the filament's config.g. if move.axes[2].babystep !=0 ; If no babysteps are currently adjusted - exit routine echo {"OLD: " ^ sensors.probes[0].triggerHeight ^ " NEW: " ^ sensors.probes[0].triggerHeight + (move.axes[2].babystep * -1)} G31 Z{sensors.probes[0].triggerHeight - move.axes[2].babystep} echo {"Place either M501 -or- G31 Z" ^ sensors.probes[0].triggerHeight^ " in your config.g"} M500 P10:31 ; save settings to config-overide.g - G31 P31 saves trigger height, ; trigger value, and X and Y offsets for each possible Z probe type ; P10 parameter saves the G10 tool offsets. M290 R0 S0 ; clear babystepping else echo "Baby stepping is not currently employed, exiting."Which has the babystep clearing at the end and also fixed an error in line 9
Note that have NOT fixed the 'weird shit' yet because I haven't quite wrapped my mind around it yet. It likely happens because of the change in G31 and the z position that the Duet printer thinks it is at (or something in that neighborhood). I believe that a reboot of the Duet after saving the new Z offset will get everything in sync and prevent the 'weird shit' (no guarantees though)
-
This is an example of the weirdness encountered:
Note that I did a save.z (the above macro) and it did it just fine.
I did not reboot as far as I remember.
Later on I tweaked baby steps some more and the system reported the old and new Z settings just fine but then it somehow screwed up the Z offset by a huge amount. The Z offset saved to config-override.g is the crazy high amount.If I did a 'home z' now by accident, the nozzle would probably bury itself in the build plate. Tried that earlier, was not a happy camper ... but thankfully nothing broke!
Edit:
Could it be that it is not safe to run the macro while the printer is doing it's thing ? I was running a print job, adjusted the babystep value as the printer was printing and then executed the save z macro. This may be what causes the bad Z offset value (not thoroughly tested yet)
I do not know the object model well enough to figure out why the crazy Z value would show up. Is there a possibility that the given parameters are not valid in the middle of a print ?
-
@jens55
I was able to replicate your experience by running the macro multiple times.
i.e. I put the whole thing in a loop by puttingwhile iterations < 9
M290 S-0.1
at the start and indenting accordingly.The problem seems to be that if there is any mesh compensation active it is added when you do the G31.
In fact it seems to be a compounding error.I don't see why you would want to run it more than once (and I definitely can't see a case for doing it during a print), but in the interests of preventing accidental errors, I suggest you try this.
Add
G29 S2;save_babystep.g ; Add babystep to Z offset and make "persistant" ; If the printer hasn't been homed, home it if !move.axes[0].homed || !move.axes[1].homed || !move.axes[2].homed G28 if move.axes[2].babystep !=0 G29 S2 ; clear bed mesh compensation echo {"Z trigger height altered by " ^ move.axes[2].babystep ^ "mm"} echo {"Old: " ^ sensors.probes[0].triggerHeight ^ " New: " ^ sensors.probes[0].triggerHeight - move.axes[2].babystep} G31 Z{(sensors.probes[0].triggerHeight) - (move.axes[2].babystep)} M500 P31:10 M290 R0 S0 ; clear baby-stepping else echo "No baby-stepping set. Nothing to save"Without clearing the mesh, this was the result of the loop with -0.1mm baby step being set each iteration.
After clearing the mesh, the result was as expected.
-
Interesting .... this appears to be another , different , problem though.
Note that in my example the Z compensation jumped from 4.150 mm to 162.85 mm which has likely nothing to do with the bed mesh compensation (way too large). Also, in your example it seems to happen consistently and in my example it does not.
Does G29 S2 disable (as in temporarily) the mesh compensation or does it toss the bed mesh map (that takes me around 3 hours to run) completely?
In your modified macro, is mesh bed compensation turned back on anywhere else as it doesn't appear to be turned on in the macro?I will not have time to dig into this today ... possibly tomorrow.
As for doing it multiple times - in my case I adjusted Z offset, saved it and later determined that I needed to tweak it a bit and saved it again.
Saving during a print comes naturally just as you tweak the babysteps during a print (well for me it does) -
-
Thanks !
-
So another possible issue .... the babystep offset shown by DWC is not correct if you did a re-home while there was an offset already set. I do not know if the macro grabs the same value as the offset that is displayed in the DWC panel or if it grabs the 'true' machine value. For that matter I do not know what the 'true' machine value would be ... all I know is that it is a moving target and under certain circumstances it can be well out of whack.
I need to explore this a bit further .... but not today. -
Hi,
Homing and bed probing used to reset baby stepping. From the docs:
In RepRapFirmware 1.19 and earlier, the babystepping offset is reset to zero when the printer is homed or the bed is probed. In RepRapFirmware 1.21 and later, homing and bed probing don't reset babystepping, but you can reset it explicitly using M290 R0 S0.
Just to be safe I cancel baby stepping and mesh compensation before homing and probing.
Frederick
Printers: A FT-5 with the 713 upgrade bits, a custom MarkForged style, a small Utilmaker style, a small CoreXY from kit and a E3D MS/TC setup. Various hotends. Using Duets (2 and 3) running 3.4.6
-
Just a reminder: when there is babystepping active and you home the z axis, the babystepping value will be added to the z axis position -- and the babystepping won't be cancelled! It's a double trouble scenario.
-
During a long run this morning, I thought about this macro...
What I think was happen is that after M290 R0 S0 was issued - that fixed refiguring an additional Z-offset, but because M290 R0 S0 actually moves the nozzle back - unless it is homed directly after, the change is not evident and then it because a death roll because the user sees it as still needing adjustment because the the new G31 has not been used yet (homed).Cheers,
Kolbi; 0:/macros/Save-Z ; This macro subtracts the current babystep offset to the Z trigger height and lets the user ; know what to change the G31 command in 0:/sys/config.g to. If you are using multiple filament settings, ; and this is for a specific filament type, recommend placing this yielded information in the filament's config.g. if state.status != "processing" ; Printer is not currently printing! if move.axes[2].babystep !=0 ; If no babysteps are currently adjusted - exit routine echo {"OLD: " ^ sensors.probes[0].triggerHeight ^ " NEW: " ^ sensors.probes[0].triggerHeight - move.axes[2].babystep} echo {"Edit the G31 command in your config.g to the new Z offset as: G31 Z" ^ sensors.probes[0].triggerHeight - move.axes[2].babystep} M291 P{"Set probe offset to " ^ sensors.probes[0].triggerHeight - move.axes[2].babystep ^ ", clear babysteps, and REHOME Z?"} R"!WARNING! Do not proceed if printing!" S3 G31 Z{sensors.probes[0].triggerHeight - move.axes[2].babystep} ; set G31 Z offset to corrected M500 P10:31 ; save settings to config-overide.g - G31 P31 saves trigger height M290 R0 S0 ; set babystep to 0mm absolute G28 ; home all M291 P"Ensure M501 exists in 0:/sys/config, or manually edit the G31 Z setting, to make this change permanent." R"Note on making change permanent." S3 else echo "Baby stepping is not currently active, nothing to do." else M291 P"This would be detrimental to ongoing print, aborting." S3 -
@fcwilt said in Baby Stepping.. can it, or can it not be permanent?:
In RepRapFirmware 1.19 and earlier, the babystepping offset is reset to zero when the printer is homed or the bed is probed. In RepRapFirmware 1.21 and later, homing and bed probing don't reset babystepping, but you can reset it explicitly using M290 R0 S0.
Yes, I came to that conclusion as well and the M290 command will go into my homez.g file.
-
@Kolbi said in Baby Stepping.. can it, or can it not be permanent?:
During a long run this morning, I thought about this macro...
What I think was happen is that after M290 R0 S0 was issued - that fixed refiguring an additional Z-offset, but because M290 R0 S0 actually moves the nozzle back - unless it is homed directly after, the change is not evident and then it because a death roll because the user sees it as still needing adjustment because the the new G31 has not been used yet (homed).I don't quite understand that yet but it sounds like a plausible explanation if it were not for the increase from a z offset of 4.5 to about 165 (see earlier in this thread) in one jump. That large jump is still unexplained in my mind.
-
@jens55 This is what I believe was happening with the previous version.
-User adjusts babysteps
-User uses script/macro to 'save' babystep
-Macro takes current offset - babystep and executes G31
-Macro then resets babystep to 0, this also physically moves Z
-Macro saves this to config-override.g
-User now understands some stuff happened, but sees that Z still has to be adjusted (because it is right back to where it was before this evolution started)
-User starts this process again, from the beginning step, which compounds the offset - this is because after each run, G31 is recalculated from the last saved, but the user sees no effect so keeps the spiral going.The new version makes you re-home, so the change is evident and stops the spiral down.
-
@Kolbi , I respectfully disagree.
I don't think that resetting the babystep value to 0 physically moves Z ..... but it wouldn't totally surprise me.
The main reason I disagree though is based on the fact that about 30 minutes ago I started a print job, re-homed z (which now also sets babysteps to zero), started the print job, adjusted babysteps to the right amount as the print job was running, executed save z, got a proper response for the new offset value but the printer now thinks that the z offset is something like 450 mm. The babystep value was around -0.40 and the offset in config.g is around 3.8 or so. There is no way that anything I heard so far can explain this short of a bug in the new conditional code / object model.
This also happened on the very first save cycle (first time it did that on the first save)!!!!!
I have a gut feeling that it is related to doing the save while a print is in progress. -
@jens55 That does sound odd.
This morning before leaving my house, I homed my printer and then babystepped .2mm up. Then in console I issued 'M290 R0 S0' and it did move the Z axis.
Was the above scenario done with the latest script I just posted or a previous version? -
No, it was done with the original script with babystep resetting enabled in the script as well babystep reset after homing z.
-
I have escalated this issue to DC42. Hopefully he can chime in on what is happening.
