Unpaired couple of G10 (retract) - G11 (unretract) impair the tool switching GCODE

[walterbux]

Version Version PrusaSlicer-2.1.0+win64-201909160915

Operating system type + version Windows 10 Pro Version 1903

3D printer brand / version + firmware version (if known) Custom Built with Repetier FW v.1.0.3

Behavior (problem to solve) I use the Firmware retraction and in particular I raise the hotend of 2 mm to avoid spots during the tool change gcode sequence having the purpose to purge and clean the extruder before continuing the print after the tool change.

The couple G10 - G11 is necessary to move the extruder without dirting around. Unfortunately the tool change gcode sometimes happens in the middle of a couple G10 - G11 processed by the slicer therfore impairing the raising of the hotend of 2mm and casually giving the wrong Z heigth of the extruder mainly after the toolchange. The result is that the extruder sometimes hurts the layers already printed destroyng the print.

Expected Results (solution of the problem) Trigger the execution of the tool change gcode before G10 or after G11 of the slicer produced gcode.

N.B. I have seen also 2 times unretract before a retract inside slicer gcode. This should also be avoided because has consequences on the correct Z positioning of the extruder.

Is this a new feature request? NO

Project File (.3MF) where problem occurs Any multi material object. Thank you.

Walter

[lukasmatena]

Thanks for the report. Could you please create a minimal example to reproduce the issue(s), just to be sure that we discuss the same thing?

If I understand correctly, you seem to mention two issues:

1. G10/G11 is paired correctly in the gcode, but it somehow messes with the toolchange /z-hop. I don't understand how. Could you enclose a 3MF and ideally a short gcode excerpt to demonstrate the issue?

2. One member of the G10/G11 pair is missing in the gcode. This would of course be something to be solved, but I need a 3MF to reproduce it to see what settings combination causes it. I just checked in a simple scenario and the pairing was correct.

[walterbux]

Hereafter I attach the file. Look at the code produced from line 1 to 111 first where everything seems ok whilst from lines 8351 to 8423 it is not ok (I look at them with Repetier Host gcode editor so you have the same line numbers). Around the second T2 the things go wrong with 2 unretracts. Here there is a G10 before tool change gcode and a G11 after but this results in a double unretract happening after tool change T2.

This happens every tool change with tool T2.

Around the tool change T3 instead the things go ok !!

In conclusion I could delete the last G11 of the tool change gcode to adjust the things fot T2 but then I would go wrong for T3 so how to solve ?

Take into account that inside the tool change gcode I need to perform

• at least one Unretract first to switch filament and relaod the next color
• at least a retract before returning to the place where to continue the printing to avoid spots and dirty with a raising of the hotend that is 2 mm (after I should unretract only in the place where I restart printing the new color or if I unretract where I was before the print interruption to change the color I would leave a spot of the new color where I finished the previous printing.

How to do all this ? Thanks for your work and effort in answering.

Walter homer-test.zip

[walterbux]

Hi Lukas, any new ?

Walter

[walterbux]

Hi Lukas, do you have news ? Did you perform some test ?

Thanks.

Walter

[walterbux]

Hi Lukas, can you please update me on the activity to solve tis issue ? Thanks.

Walter

[lukasmatena]

@walterbux Sorry about the late response. I didn't get to it yet, there were other pressing issues and since this is probably this way for years, I didn't consider it critical enough to give it absolute priority. I now had at least a quick look at your 3MF to see what is happening.

First of all, I'm afraid that your custom gcodes are completely wrong, which makes troubleshooting difficult, because it is far from a minimal example. You seem to be using the macro language, but the processor doesn't even recognize it. For example:

if [next_extruder] != [previous_extruder] G1 E-40 F120 ;unload filament only substitutes the variable names by values, but no condition is actually evaluated. What you probably intended was: {if next_extruder != previous_extruder} G1 E-40 F120 ;unload filament{endif} Note that this specific condition should always be tautological.

I don't understand the purpose of emitting a Tn command after an M600, but I have no clue how your firmware behaves. Also, a quick look at your custom toolchange gcode shows one G10 and two G11, so you return control at different retraction state than you got it. I'm now not sure what will happen next. Same holds for your custom start gcode. I'd guess that if you ended up printing at wrong height, it is caused by mistakes in custom gcodes and not by G10/G11 pairing.

---

All that being said, you are correct about imperfect G10/G11 pairing. There is a parameter in 'Print Settings->Extruder->Retraction when tool is disabled->Length' which retracts the filament just before the toolchange. Setting this to zero disables this extra retraction, but only if you do NOT use firmware retraction. If you do, this retraction seems to be always added and is never unretracted (which does not even make sense, given that the filament was unloaded). I'm not sure if this can cause any issues or not.

[walterbux]

Thank you Lukas for your answer. I am grateful also to the developers for the rudimental macro language provided but sincerely the documentation about it is very incomplete and being in the need to build something more complicate than the minimal examples given is obviously prone to errors. In my understanding the square brackets were needed to evaluate an expression so including a variable between them was not so wrong, may be redundant, instead I have understood after the mandatory addition of {endif} after every if... I recognize this was my error.

In Cura you can add user gcode both before switching extruder and after in 2 separate windows... Being it not possible in prusaslicer I had to include Tn command inside the unique window for tool change specific gcodes. This also can cause conditions in which next extruder be equal to previous extruder...

The addition of G10/G11 inside custom gcodes was aimed to solve 2 problems: 1 - avoid to unload/load/prime filament under retract condition generated before the execution of custom gcodes 2 - try to pair unpaired G10/G11 couples.

The purpose of emitting a Tn command after an M600 is to cut the filament by hand before loading the new one more or less as your MMU does ...

I have observed imperfect G10/G11 pairing in the slicer output gcode despite every my attempt to pair them inside my custom gcode. The pairing infact was ok on a layer and in another layer was wrong. In particular the big problem I have found was the impossibility to unload/load/prime filament under retract condition generated before the execution of custom gcodes because this obviously creates problems to good pairing that in my opinion should always be done outside custom gcodes.

Even with your observation of completely wrong gcodes they apparently behaved correctly except for the wrong Z heigth of the extruder mainly after the toolchange.

Thank you.

Walter

[lukasmatena]

Like I said, the only unpaired retraction occurs just before a toolchange, it was like this for years and nobody reported any issues related to that (as far as I know). Also, I seriously doubt that any incorrect pairing of G10/G11 could cause printing on a wrong layer. Until your custom gcodes contain lines such as G1 Z+5; level "up" (which is exported verbatim into the output gcode without any actual substitutions), I suspect that your issues are caused by your gcodes. Also understand that you're running a custom printer and I cannot properly understand what it does and doesn't need, so I cannot fix your custom gcode.

I'm not saying there is not a bug. But I did not find it.

[walterbux]

My custom code does: ; tool change M401; store current position in memory G91; Use relative coordinates G1 Z+5; level "up" G90; Use absolute coordinates.

This is needed to store current position in memory and raise the extruder to avoid hitting printed material whilst going to park position where the extruder tip is cleaned through some movements but at the end there is:

G1 Z0 F800; continue purging on bed ... M402 Z F2000; resume Z stored position this before x and y to avoid hitting the printed material M402 X Y F2000; resume stored position

So the Z level is restored at the value memorized by M401 command and no Z level error is possible.

Moreover I use Repetier FW with firmware retraction. Inside the G10/G11 Retraction parameters of the firmware there is:

Z-Lift on retraction that I set = 2 mm needed to avoid dirty spots on my printed parts.

Obviously there is a 2 mm raise on z every time I retract and 2 mm down every unretract.

This is the reason why wrong G10/G11 pairings lead to wrong z heigths.

May be I wrongly disabled retraction in Prusaslicer, if so please correct me otherwise the solution is

"Don't use firmware retraction at all....".

Regards.

Walter

[lukasmatena]

Ok, I finally understood that the z-hop is set up on the FW side and performed by the G10/G11 commands. Somehow I didn't get this at first and the strange gcodes misled me.

In that case, you are correct. There is some bug in PrusaSlicer that issues the G10/G11 commands inconsistently around toolchanges and your attempts at pairing them correctly thus fail in some cases. This should be fixed. And yes, not using fw retraction should be a valid workaround, as far as I can tell, this only affects the fw retraction (and I'll be grad to hear if it is indeed so).

[walterbux]

Hi Lukas, I had the good new (no more problems) starting to disable the FW z-hop. Then by disabling FW retraction and enabling Prusaslicer retraction + z-hop everything worked like a charm... Obviously I reworked the custom gcode accordingly deleting every G10/G11...

Thank you for all and now I would like to know how and when you will modify the Prusaslicer. Wormest regards.

Walter