Need to lower the nozzle
-
Thanks for trying but the only way this will sink in is if I do it myself directly on the printer!
-
@jens55 How about this: What the probe trigger height is doing, is telling the system how far away from the bed it detects contact. So if I'm blind folded and have a stick that is 1 meter long, and touch the wall infront of me with it - I know I can move an additional meter towards the wall and not smash my face, but just have my nose touch it.
But if someone TOLD me my stick is 1.5 meter long, but in reality it is still a 1 meter long stick - I'd smash my face because I'd walk towards the wall an addition 1.5 meters from sensing the contact @ 1 meter. -
The penny dropped, the light went on and things make sense.
Thank you kindly for all the help to get things through my thick scull! -
-
Well that clears that up. lol thanks for the info and the macro.
-
@Kolbi said in Need to lower the nozzle:
it made my brain mushy and I had to get a drink.
Perhaps that is why you are walking into walls?
Frederick
-
The math (or logic) in my original posted macro was incorrect.
The baby-stepping value should be subtracted from the trigger height, not added.
Macro shown above is correct.
I should have stated that I had not tested it as I personally see no value in working this way.
It was hastily done just to show the OP that it could be done.
I have corrected the original post. -
I am really glad to know that confusion about these measurements is not a rare phenomenon
-
I found the blog post at https://www.sublimelayers.com/2017/05/fdffsd.html?m=1 helpful when I was learning what trigger height means and how it changes.
He posts still in some of the Delta communities and the visuals really help one understand. With the FSR and Smart Effector style probes the understanding is key and confusing with all the negative values.
-
BIG issue with the macro.
Not sure what happened but somehow or other my z offset got set to z 395.xx with the obvious " Let's see if we can run the nozzle to China".
Thankfully nothing broke.
I haven't figured out as everything seems to run just fine if you run the macro just once. I did run into another issue though:
If you run the macro multiple times without changing the babysteps, it will merely add onto the previous saved value of the z offset. The macro needs to reset the babysteps to zero before it exits. -
OwenD, in another thread, mentioned to use
M290 R0 S0 ; clear babystepping
But there seems some concern about this working..... I will try it out.
-
This is the new and improved macro:
Note that there are two changes - the line that clears the babysteps but also line 9 which introduced an error in the echoed text for Z offset.
How can I get a nice text box like the previous posters ?
-
Hi,
You use the </> tag.
Frederick
; 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."
-
; 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."
-
-
One last comment .... the previous huge error in the Z offset was probably caused by the interaction of the macro with internal Z values of the Duet. See the post from yufanyufan here https://forum.duet3d.com/topic/16328/baby-stepping-can-it-or-can-it-not-be-permanent/55
One needs to be careful about using this macro as there is some strange interaction happening that I don't quite follow yet.
I recommend rebooting the Duet after running the macro so that everything is in sync. If you don't reboot but then home z, weird stuff happens. -
@jens55, So one run of the macro is ok, but multiple runs are not ok?
Did you happen to home between runs?
I never ran it multiple times. Good call on M290 R0 S0 .
-
With the updated macro, multiple runs seem to be ok but there is still an issue as reported in this thread :
https://forum.duet3d.com/topic/16328/baby-stepping-can-it-or-can-it-not-be-permanent/55?_=1596951896532
I now believe that an incorrect Z offset value is stored if the macro is run while the printer is doing a regular print job.
I have run out of time for the day and tomorrow to go any further on the diagnosis. -
The M290 R0 Z0 is courtesy of owenD and wasn't my call.
-
@jens55 Ok, so the only change was the M290 R0 Z0?