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

fcwilt

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

bot

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.

Kolbi

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

jens55

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

jens55

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

Kolbi

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

jens55

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

Kolbi

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

jens55

No, it was done with the original script with babystep resetting enabled in the script as well babystep reset after homing z.

jens55

I have escalated this issue to DC42. Hopefully he can chime in on what is happening.

https://forum.duet3d.com/topic/18100/dc42-please-read