Need to lower the nozzle
-
@jens55 Ok, so the only change was the M290 R0 Z0?
-
No, I also changed line 9 as it resulted in an incorrect echo output for setting the Z offset in config.g.
-
@jens55 Ah yes, since it got changed in the line above....
Good catch! -
Exactly ... and thank you
-
@jens55, Maybe until it is sorted - the macro should just state what to change in the config.g to be safe:
; 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."
This way it just tells the person what it should be changed to, without inadvertently going to China - but I'm in Japan so maybe it would work for me
Sorry about that btw - never thought of running it twice. -
Hopefully it will be sorted out quickly but I did indicate that the Duet should be reset after saving Z offset and saving should not happen while the printer is busy printing until things are sorted.
I love the concept of saving the corrected offset value though!
The rest is up to the user. Instead of 'buyer beware' it's 'user beware' -
@Kolbi said in Need to lower the nozzle:
without inadvertently going to China - but I'm in Japan so maybe it would work for me
No, you guys are hanging upside down on the world so your nozzle would end up going to North America (Hopefully missing the USA)
.... end just like that I managed to politicize the thread
-
@jens55 I do miss the USA - born there but I've been overseas for ~18 years, someday I'll go back
-
@jens55, @Baenwort, @Elvis0z, @fcwilt - I believe this is the best solution until multiple tests can be done and confirmed. This macro just lets the user know what changes to make - still pertinent as it avoids the whole adding or subtracting confusion.
; 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 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} echo "After editing config.g, remember to reset machine to load new settings." else echo "Baby stepping is not currently employed, exiting."
-
Ok, that went off track faster than I thought .... I was implying that your nozzle hopefully would not end up in the USA as it is an unbelievable nasty mess at the moment !
-
@jens55 Ha - that is true, and I take no offense to such stuff
-
@jens55 Some more thoughts about this baby step macro, multiple run case
@dc42, can you give any advice on this please?-When insitu babystepping - if you issue 'M290 R0 S0', does your in the moment babystep go away? It seems that M290 R0 S0 should only be done once user is done with the print? Else will it jack it up?
-It also seems that the script should only be allowed to run once, until a fresh home of Z? Does homing Z reset babystep, or would script need to issue G31 to set new probe offset, then M290 R0 S0, and then home Z?
I'm printing now so I can't test any of this out...
Cheers,
Kolbi -
@jens55 I just tried the following code; I cycled babystep up and executed, I cycled babystep down and executed, and cycled babystep down again and executed - seemed to all work fine for me. Let me know if you guys have any problems with it, or have something better.
After 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 - 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) and M290 R0 S0 moved then nozzle back.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
-
Hi,
M290 moves the nozzle up or down according to the parameters, seemingly as soon as the command is executed.
What it DOESN'T do is change the Z position. If the DWC shows Z=5 then that is what it shows after one or more M290 commands.
And while this discussion is very interesting it seems to me that you are attempting to solve a problem that doesn't really exist.
M290 is fine for temporary changes that occur as the printer heats up/cools down, etc.
G31 is the place to enter any changes you want to persist after a reset or power cycle.
Both commands affect the same thing - nozzle to bed spacing - but one is short term the other is long term.
That said I'm enjoying your efforts and hope they continue.
Frederick
-
I have escalated this issue to DC42. Hopefully he can chime in on what is happening.
-
@fcwilt / Kolbi and anybody else that chimed in - I now have recreated the issue that happens when babysteps are saved and the babystep value is zeroed.
The new offset ends up in config-overwrite.g but unless config.g is run it is never set and resetting the babysteps to zero brings the print nozzle to the same position that it started out as before the attempt was made to correct with babystepping.I will wait and see what DC42 has to say re the invalid G31 Z values before worrying about other things.
-
@jens55 AH, agree. This is way I said without homing Z afterwards, it is never realized. Thats why the latest version stops the user from doing such until the print is done.
-
Yes. my apologies and I edited my post to credit everybody.
I have lost track of who said what and with two threads going, I didn't want to look through everything, compare time stamps and figure out what the order of credits should be. -
@jens55 Yeah, its a bit confusing but fun.
But I do think my last revision is stable and safe. -
I just noticed that you put in a test for an active print job - good show!
If the issue that I am seeing is in the bowels of the code, it will sooner or later screw up something so although your code 'fixes' the symptom for this macro, I rather have the problem looked at and fixed (if possible).