Toolchange Movement Option 2 behaving like Option 4?

[Durahl]

Greetings!

I'm trying to optimize my Config for faster ERCFing and was pondering about how Tip Cutting Option 2 is being performed...

1. Move to Wipe Tower and do essentially nothing?
2. Move to Cutter Pin
3. Move to Purge Bucket ( in my case Nozzle Cleaner )
4. Move to Wipe Tower
5. Move back to Print

Compared to Option 4:

1. Move to Cutter Pin
2. Move to Purge Bucket and Purge Filament
3. Move back to Print

Is it possible to have Option 2 - with a Wipe Tower - behave like Option 4?

1. Move to Cutter Pin
2. Move to Purge Bucket ( still just Nozzle Cleaning )
3. Move to Wipe Tower
4. Move back to Print

The Pictures with the Graphics and CFG Entries do show the differences but it's not exactly clear which one is responsible for the Toolhead to make its detour stop above the Wipe Tower before moving on to the Cutter Pin in Option 2 🤔🤨

On a somewhat related question... I've noticed the Tool Head - once it positioned itself again over the Wipe Tower - preextruding the tiniest Squirt of Filament before doing the actual Wipe Procedure which in the grand scheme of things is hardly noteworthy but it still kinda rubs me wrong seeing it happening - Is this an ERCF related Setting that can be disabled?

Cheers!

[moggieuk]

Well, don't assume the doc is 100% correct! :-). I spent a lot of time on it but didn't do a formal QA.

Briefly, if I can remember what I was thinking when I wrote this, the main difference between option 2 and 4 is if the slicer wipetower is enabled.

Option 2 it is. This means that the slicer will move to wipetower then want to form tip (lets say you have correctly nullified this), then it will call the toolchange. Happy Hare takes over and with tip cutting enabled will move to cut tip and then parking position, unload, then load. After that it moves toolhead back to "last" position (where the slicer left it) passes control back to the slicer. The slicer will move back and forth on thethe wipetower and purge out the old filament. It will then return to the print.

Option 4: the slicer has no wipetower and is thus configured to do no purging. It just calls toolchange. Happy Hare moves to the cutting position, then parks, does unload, load, and purge (this pic does not consider blobifer but that could include additional moves). It then is ask to move the toolhead to "next" which is the next point to print. Control passes back to slicer and it immediately continues printing. HH could move toolhead back to "last", but this increases the chance of the wrong color being deposited at the previous color position.

On the "squirt" problem .. your slicer is doing this. Maybe a ramming move or similar. Best is to examine some generated gcode. Look carefully before and after the Tx or MMU_CHANGE_TOOL command ... what is the slicer doing? That whould put you on the right track.

[Durahl]

I assume this means we can't have Option 2 without the first Wipe Tower detour before moving on to the Cutter Pin? 😭

I had a look into a Generic Color Changing File to see if I could spot Extruder related Code that would cause the Squirt but couldn't find anything: Line 435 ⬆️ is the last non-Extruding move after the Tx Command on Line 429 before it starts drawing the Wipe Tower on Line 439 ⬇️ Essentially somewhere between Line 429 and Line 435 is where the Squirting Happens and with it not being in the File, I assume it being part of a Config? 🤔

From my limited Logic it cannot be anything else but HappyHare causing this as the only non-HappyHare Code happening between the Filament being loaded and the Wipe happening is a Nozzle Scrub Command ( having no Extruder related Moves in it ) being called out for using variable_user_post_load_extension : 'CLEAN_NOZZLE'

[moggieuk]

You probably want to eliminate this if you can. It looks harmess but is kind of a pre-form tip move..

Do you get the "squirt" when running a manual tool change? I.e. load T1, extrude filament so you know the nozzle is primed. Run T2 and watch nozzle. Does anything ooze? If not, when you manually extrude 1mm do you see the extrusion? Trying to validate configuration first. It could be that mmu_toolhead_ooze_reduction is slightly too short. Di you run through this: https://github.com/moggieuk/Happy-Hare/wiki/Blobbing-and-Stringing

[Durahl]

I don't think I have any authority when it ccomes to removing that Retract(unload) section of Code - Enable filament ramming has already been disabled, disabling Purge in prime tower does not affect it, and all the Measurement Settings have been Zeroed out as much as possible: Considering how much it unloads and then reloads the Filament though it explains a different Squirt that is happening when the Nozzle makes the "unnecessary" Detour Wipe Tower Move before moving to the Cutter Pin.

I did read the B&S Guide but didn't quite follow it as I'm aiming for a 100% primed Nozzle and have thus set the mmu_toolhead_ooze_reduction to a negative value that will extrude a small amount in the Purge Bucket Area BEFORE doing the Nozzle Scrub.

I tried recording the Tool Head doing the offending Squirt but it's difficult due to where the Cutter Pin and Purge Area are located resulting in unfavorable Recording Conditions ( not too keen in the Tool Head smacking my iPhone out of my hands 😅 )

While I NOW couldn't observe the Squirt happening ON the Wipe Tower I noticed it happening AFTER the Nozzle Scrub ( triggered by variable_user_post_load_extension : 'CLEAN_NOZZLE' ) but before moving to the Wipe Tower. Is the offending Wipe Tower Squirt perhaps caused by the HappyHare Restore last Position function? 🤔 As in not just restoring the X, Y, and Z but also E? 🤨

[moggieuk]

Negative mmu_toolhead_ooze_reduction can't be correct (if other dimensions are correct). At the end of the toolchange macros the nozzle should be toolchange_retraction distance short of full. That final un-retract move is made by HH after lowering the toolhead to the print.

One the "restore_position" setting .. i'm wondering about that. It was actually added through a PR so I'm not 100% sure, but it will do whatever "RESTORE_GCODE_STATE MOVE=1" does....

Looked at klipper and it does:

        # Restore the relative E position
        e_diff = self.last_position[3] - state['last_position'][3]
        self.base_position[3] += e_diff        # Restore the relative E position

so could be the source. Need to think through the klipper logic after a good nights sleep but it does look like it trying to restore/correct the relative extruder position to exactly what it was when recorded (but wouldn't that be -= e_diff??). If you disable this "return" option does it work? (I know its not the movement you want, but just to ascertain if this is the root problem).

Let me ask.. are you using relative extruder (E) movements in the slicer? or absolute?

[moggieuk]

Ok. So I was tired last night. Klippy and the cut macro is correct -- the extruder position will be correctly reset but it isn't moved. Only X, Y,Z are. So this isn't the source of your oozing..

[Durahl]

Sorry the late reply ( I thought I had actually replied but apparently never hit the Comment Button 🤔 )

Despite being the Author of my own Tool Head with all Dimensions available to me I couldn't get HH to work using the actual numbers unless I'd be fudging them ( Even taking the comment about CHT Nozzles and Holding the Blade in position for Calibration into consideration ) - Filament would either take way too long to extrude when freshly loaded or perform the Cut with the Filament long having left the Chat. Squeezing mmu_toolhead_ooze_reduction and making it negative made sure I'd ensure it cutting the Filament while also getting a good prime.

But then again... The Nozzle gets primed and the Cutter cuts so nothing really to complain about 😏 Perhaps I'll be revisiting those settings once more at another time.

As for the Question regarding Relative or Absolute I assume it is Relative? 🤨: