[Bug] Color Change Command Adding Retraction after M600 - Delaying Extrusion on Resume

[andymnel]

Version

2.4.1 (tested 2.3.3 and 2.4.0 as well)

Operating system type + version

MacOS Big Sur 11.3.1

3D printer brand / version + firmware version (if known)

Ender 3 v2 with custom marlin build - Marlin 2.0.7.2

Behavior

Newer versions of Slicer (v2.3.3+) are adding a retraction command after every M600.

This is causing the extruder to perform a retraction right before resuming the print. Causing a delay in extrusion equal to the retraction length under Printer Settings.

Using the exact same config from v2.3.1 (that I've used for 18 months before that), newer versions all generate the additional retraction line in the gcode.

Likewise, if I delete the retraction line in the gcode file the filament change behaves as before with no retraction, and extrusion resumes properly.

Is this a new feature request?

no

[rtyr]

If you look closely to your screenshot, you will see that 2.4.0 gcode is actually correct, unlike 2.3.1 gcode.

2.3.1 screenshot:

1) the last position before M600 command is X99.937 Y117.774 2) same X99.937 Y117.774 is the location to which printer resumes after filament change 3) note that the nozzle is primed after the filament change 4) travel to X99.632 Y99.632 without retraction - incorrect 5) incorrect 8mm "deretraction", creating blobs on most printers (that is the main reason we fixed it). 6) See https://github.com/prusa3d/PrusaSlicer/issues/6362

2.4.0 screenshot:

1) the last position before M600 command is X108.58 Y99.225 2) same X108.58 Y99.225 is the location to which printer resumes after filament change 3) note that the nozzle is primed after the filament change 4) retraction before travel - correct 5) travel to X100.032 Y99.632 6) deretract

As you can see, the behavior regarding the retraction is correct in 2.4.0 and incorrect in 2.3.1. Likely your issue is about insufficient pressure in the nozzle after M600 command, which is also partially present on some of our printers (some material leaks during travel back to the object). You can solve that by adding custom priming to the color-change gcode.

The handling of M600 command depends largely on printer firmware.

See https://github.com/prusa3d/PrusaSlicer/issues/6732 (similar issue).

and

https://github.com/prusa3d/PrusaSlicer/issues/6362, this if why we fixed it

[andymnel]

@rtyr thanks! That makes sense from a code perspective and seems like it should be viable. However, in real world behavior what I notice is:

1. With the introduction of retraction in #6362 to compensate, the deretraction doesn't appear to be occurring - ie, the extruder visibly retracts and the perimeter continues to print with no extrusion for quite some time
2. So with the custom gcode compensation, it seems it will be adding a custom deretraction (prime) on top of the existing, retraction, and then another deretraction. Adding more code unnecessarily to compensate?

Thoughts on pre #6362

1. During filament purge it seemed to be best practice to let the back pressure in the nozzle diminish before pressing continue.
2. With either scenario/solution, this will be a real world factor that is hard to avoid and has to be handled manually with single extruders. Eg, waiting and cleaning up the nozzle and the string of filament before continuing. I still have to do this either way if I don't want a long string dragged across my print.
3. That back pressure from the purge is usually what caused the blobbing and I have seen similar to #6362. However, once the back pressure was relieved by waiting (or opening the extruder lever for a moment), the deretaction on resuming in 2.3.1 actually seemed to help the print resume seamlessly and the blobbing was gone or minimal.

[andymnel]

Examples from before solution in #6362. These prints and perimeters resumed well after color change.

[rtyr]

Printer does exactly what is in the g-code. One big variable here is the firmware, which handles M600 differently based on the firmware configuration.

The previous behavior was incorrect, because it ignored the fact, that print was interrupted for filament change. The nozzle is usually primed after filament change, so deretraction based on the previous retraction doesn't make sense anymore or at least not the same amount (few mm on bowden printers, 0.x mm on direct drive printers).

So with the custom gcode compensation, it seems it will be adding a custom deretraction (prime) on top of the existing, retraction, and then another deretraction. Adding more code unnecessarily to compensate?

It will prime the nozzle after the travel back to the print, then there is another travel, which needs retraction. Without it you are doing only retraction/deretraction which doesn't solve missing material after M600. It may not be ideal with your printer, just a way how to change the behavior to fit your printer better.

Side note: I noticed G1 E6 F25, that is extremely slow (should be probably F1500).

During filament purge it seemed to be best practice to let the back pressure in the nozzle diminish before pressing continue.

This really depends on the firmware. For example our printers extrude some filament after "continue".

There are several discussions how M600 should behave and where should be inserted, https://github.com/prusa3d/PrusaSlicer/issues/2672, https://github.com/prusa3d/PrusaSlicer/issues/4432.

Anyway, the current behavior regarding retraction (resetting internal retract counter) is intended.

[fontenele]

Prusa printers do not have this problem, but others... If we have an option to disable retraction after M600 command (like reset internal retract counter after all M600), that will solve the problem! Please look for us, not prusa printers users.

Here my partial sollution, with gcode substitutions i can comment the next line (retraction) after M600.

[rtyr]

Just add priming as mentioned here https://github.com/prusa3d/PrusaSlicer/issues/8047#issuecomment-1063766720 if your printer requires it. Not doing retraction before travel is not correct.

[pacocatech]

It is not correct, however, the firmware itself already has a retraction during the M600 process, what happens is that for the community that does not use PRUSA printers always suffer from this flaw. I think there could be an option to disable this extra retraction being done.

[rtyr]

the firmware itself already has a retraction during the M600 process

After the new filament was inserted and purged? Only retract without deretract? What firmware does that? As far as I know, there is only initial retraction when parking to M600 position, which is not relevant.

Actually looking at Marlin configuration, there is a setting which does the same thing I proposed, additional priming after return from M600.

So again, you should be able to easily solve it by adding second line like on this screenshot (with your own E value, this example is valid for relative extruder positioning). The retraction you don't like will be still there, but the nozzle will be primed before that. .

[fontenele]

i dont know if this is the better sollution...

[andymnel]

A few confusing typos I just noticed. Here's what I meant.

M600 - Hit resume print after purge pressure is equalized and filament not oozing quickly G1 E8 F1600 - proposed inserted line to counteract the retraction line below - it just oozes more as it's moving back to the print G1 E-8 F1600 - retract that still causes the filament NOT to come out on resume G1 - MOVE BACK TO PRINT LOCATION G1 E8 F1600 - prime the nozzle before printing perimeter

On Tue, May 31, 2022 at 7:38 AM Andrew Nelson @.***> wrote:

I’ve tested this proposed solution - of adding extra deretraction. I understand the theory behind it. In real world, It doesn’t really work. At least on my machine.

It basically plays out like this:

M600 - Hit resume print after purge pressure is equalized and filament not oozing quickly G1 E8 F1600 - proposed inserted line to purge a little extra and supposedly counteract the default deretraction below - it just oozes more as it's moving back to the print G1 E-8 F1600 - retract that still causes the filament to come out on resume G1 - MOVE BACK TO PRINT LOCATION G1 E8 F1600 - prime the nozzle before printing perimeter

Since posting this months ago, I now just remove the retract line (G1 E-8 F1600) in the GCODE in my text editor like. Less commands and resumes print just fine.

M600 - Hit resume print after purge pressure is equalized and filament not oozing quickly G1 - MOVE BACK TO PRINT LOCATION G1 E8 F1600 - prime the nozzle before printing perimeter

old example code [image: image.png]

On Mon, May 30, 2022 at 3:28 PM rtyr @.***> wrote:

the firmware itself already has a retraction during the M600 process

After the new filament was inserted and purged? Only retract without deretract? What firmware does that? As far as I know, there is only initial retraction when parking to M600 position, which is not relevant.

Actually looking at Marlin configuration, there is a setting which does the same thing I proposed, additional priming after return from M600. [image: marl] https://user-images.githubusercontent.com/36745189/171059629-67f02154-fd95-490e-b3f3-91e74ef7c66f.jpg

So again, you should be able to easily solve it by adding second line like on this screenshot (with your own E value, this example is valid for relative extruder positioning). [image: m600_2] https://user-images.githubusercontent.com/36745189/157614844-37e900c1-f563-4d4f-a0f0-8b9c24e67a6a.jpg .

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/8047#issuecomment-1141486839, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADL37UJHSJTVRI4ZEFPZJ6DVMUXJTANCNFSM5QLO7FZQ . You are receiving this because you authored the thread.Message ID: @.***>

[rtyr]

@fontenele Yes it is... Just follow the g-code further. Prime - Retract - Travel - Deretract. Just try it.

And of course 5mm priming will be likely too much. It would mean you printer oozes 5mm worth of material during M600.

[rtyr]

@andymnel

G1 E8 F1600 - proposed inserted line to counteract the retraction line below - it just oozes more as it's moving back to the print

That is unlikely because this line is processed AFTER returning from M600, so it does not affect travel back to the object.

[andymnel]

Well either way. I just remove the retract line after the M600 in a text editor. Print works fine.

I’ve tried the proposed addition several times (from the earlier messages in this thread months ago) of adding another retract line after M600 to compensate. It didn’t do anything and in some cases just added more problems.

So, it just feels like a bunch of back and forth over what theoretically should happen in the commands. Rather than what actually occurs. So rather than waist more time, I just delete the line and it works.

On Tue, May 31, 2022 at 12:07 PM rtyr @.***> wrote:

@andymnel https://github.com/andymnel

G1 E8 F1600 - proposed inserted line to counteract the retraction line below - it just oozes more as it's moving back to the print

That is unlikely because this line is processed AFTER returning from M600, so it does not affect travel back to the object.

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/8047#issuecomment-1142454288, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADL37UJZ2HOJOQSMS2MQF7DVMZIPZANCNFSM5QLO7FZQ . You are receiving this because you were mentioned.Message ID: @.***>

[fontenele]

Well either way. I just remove the retract line after the M600 in a text editor. Print works fine. I’ve tried the proposed addition several times (from the earlier messages in this thread months ago) of adding another retract line after M600 to compensate. It didn’t do anything and in some cases just added more problems. So, it just feels like a bunch of back and forth over what theoretically should happen in the commands. Rather than what actually occurs. So rather than waist more time, I just delete the line and it works. … On Tue, May 31, 2022 at 12:07 PM rtyr @.> wrote: @andymnel https://github.com/andymnel G1 E8 F1600 - proposed inserted line to counteract the retraction line below - it just oozes more as it's moving back to the print That is unlikely because this line is processed AFTER returning from M600, so it does not affect travel back to the object. — Reply to this email directly, view it on GitHub <#8047 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADL37UJZ2HOJOQSMS2MQF7DVMZIPZANCNFSM5QLO7FZQ . You are receiving this because you were mentioned.Message ID: @.>

@andymnel Try this https://github.com/prusa3d/PrusaSlicer/issues/8047#issuecomment-1141392529

[pacocatech]

@andymnel works only using #8047

this is the best solution for those who don't have prusa printers.

[camilo-sx]

@andymnel did you find a solution? I tried commenting the line like #8047 did but I still see the same error, It retracts a little before starting the filament change... leaving a under extruded line in the perimeter

[andymnel]

I’ve tested this proposed solution - of adding extra deretraction. I understand the theory behind it. In real world, It doesn’t really work. At least on my machine.

It basically plays out like this:

M600 - Hit resume print after purge pressure is equalized and filament not oozing quickly G1 E8 F1600 - proposed inserted line to purge a little extra and supposedly counteract the default deretraction below - it just oozes more as it's moving back to the print G1 E-8 F1600 - retract that still causes the filament to come out on resume G1 - MOVE BACK TO PRINT LOCATION G1 E8 F1600 - prime the nozzle before printing perimeter

Since posting this months ago, I now just remove the retract line (G1 E-8 F1600) in the GCODE in my text editor like. Less commands and resumes print just fine.

M600 - Hit resume print after purge pressure is equalized and filament not oozing quickly G1 - MOVE BACK TO PRINT LOCATION G1 E8 F1600 - prime the nozzle before printing perimeter

old example code [image: image.png]

On Mon, May 30, 2022 at 3:28 PM rtyr @.***> wrote:

the firmware itself already has a retraction during the M600 process

After the new filament was inserted and purged? Only retract without deretract? What firmware does that? As far as I know, there is only initial retraction when parking to M600 position, which is not relevant.

Actually looking at Marlin configuration, there is a setting which does the same thing I proposed, additional priming after return from M600. [image: marl] https://user-images.githubusercontent.com/36745189/171059629-67f02154-fd95-490e-b3f3-91e74ef7c66f.jpg

So again, you should be able to easily solve it by adding second line like on this screenshot (with your own E value, this example is valid for relative extruder positioning). [image: m600_2] https://user-images.githubusercontent.com/36745189/157614844-37e900c1-f563-4d4f-a0f0-8b9c24e67a6a.jpg .

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/8047#issuecomment-1141486839, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADL37UJHSJTVRI4ZEFPZJ6DVMUXJTANCNFSM5QLO7FZQ . You are receiving this because you authored the thread.Message ID: @.***>

[fontenele]

Prusa printers do not have this problem, but others... If we have an option to disable retraction after M600 command (like reset internal retract counter after all M600), that will solve the problem! Please look for us, not prusa printers users.

Here my partial sollution, with gcode substitutions i can comment the next line (retraction) after M600.

@andymnel this gcode substitutions do exactly that you said... and now thats the official way we are using in Brazil. It works for all!

[andymnel]

@fontenele thank you! But isn't the comment code for gcode a semi colon? ";" Not "//" Maybe this is why it didn't work for @camilo-sx ??

[fontenele]

@fontenele thank you! But isn't the comment code for gcode a semi colon? ";" Not "//" Maybe this is why it didn't work for @camilo-sx ??

Yes, sorry my mistake 😂

[Andres-3DArtist]

Hey @fontenele @andymnel I think I'm having the same issue. After M600 and changing the color, the printer isn't "printing" for more than 1 layer... After reading your thread I think it's because of retraction, but I'm not 100% about what was the solution. Can you help me? I think I have to add M600\n;;? But I'm not sure where

Thanks for the help!

[andymnel]

You can play around with the code insert versions like that - it will technically work but it still might cause inconsistent extrusion behavior over time or simply just be a band-aid. I've found the cleanest, real-world results by editing the gcode directly and just removing the retraction line after the M600 line. Fixes the problem completely and isn't just bandage code.

On Fri, Nov 17, 2023 at 4:01 AM Andres Prados @.***> wrote:

Hey @fontenele https://github.com/fontenele @andymnel https://github.com/andymnel I think I'm having the same issue. After M600 and changing the color, the printer isn't "printing" for more than 1 layer... After reading your thread I think it's because of retraction, but I'm not 100% about what was the solution. Can you help me? I think I have to add M600\n;;? But I'm not sure where

Thanks for the help!

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/PrusaSlicer/issues/8047#issuecomment-1816162360, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADL37UMKATJ7IMA35C2DYCLYE47XNAVCNFSM5QLO7FZ2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBRGYYTMMRTGYYA . You are receiving this because you were mentioned.Message ID: @.***>