Need to lower the nozzle

jens55

@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

Kolbi

@jens55 I do miss the USA - born there but I've been overseas for ~18 years, someday I'll go back

Kolbi

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

jens55

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 !

Kolbi

@jens55 Ha - that is true, and I take no offense to such stuff

Kolbi

@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

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

fcwilt

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

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

jens55

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

Kolbi

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

jens55

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.

Kolbi

@jens55 Yeah, its a bit confusing but fun.
But I do think my last revision is stable and safe.

jens55

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

Kolbi

@jens55 Haha, no worries.

fcwilt

@jens55 said in Need to lower the nozzle:

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

Can you use M98 to invoke config-overwrite.g in your macro?

Frederick

jens55

Oh oh ..... danger Will Robinson, danger, danger ....

The scenario ..... 20 hour print job and you are at 19:59. you are admiring your perfect print job that took 3 tries to get right. You realize you forgot to save the offset and hit the magic button.
The printer comes to a shuddering halt as it resets itself to activate the new values in config-overwrite.g.

Visions of the users head slowly turning red, smoke pouring out of every orifice until .... his head explodes and you are left with a bloody and ragged neck on top of a lifeless body.

Printer merrily finishes it's reset and happily notifies the no longer exiting user that it is connected to the network and ready to print!

Hmmmm .... maybe I got carried away there but I can vividly (too vividly) see it in my mind!

fcwilt

@jens55

Why did the printer reset?

Frederick

jens55

You said you wanted the config-overwrite.g values to go live (execute) ... as far as I know that only happens when config.g is run which I am thinking is a printer reset.
Don't know .... but it invoked all kinds of horror scenarios in my mind.
Maybe I have been watching too many horror movies ?
Oh .... the previous scenario happened in a darkened basement full of spider webs

jens55

Ok ok .... just had an actual look at the file and maybe the horror show was a bit over the top and your idea may just work .... but it's not giving us any entertainment value