SOLVED Double G10 retraction - happens but should not (IMO).

deckingman

Short version.....
I have a situation where two consecutive G10 firmware retraction commands get enacted without a G11 un-retrcat in between. My understanding is that this should not happen and that the second G10 would only be enacted if it was preceded by a G11.

Long version....
I've been struggling with stringing and getting retraction right for some time but suspected that it was due some fault with my experimental 6 input hot end. However, I noticed something today which might explain my issues. To be clear, the hot end is configured as a mixing hot end so all tools use the same 6 extruders, even if only one is moving forward during the print. This means that, by using firmware retraction, all 6 filaments (should) get retracted and un-retracted concurrently.

I started a print today and happened to notice that all 5 drives which were configured but not in use (moving forward) for the selected tool were showing a position of -5 (minus 5mm). Co-incidentally 5mm is the retraction length that I have set up. As I had only recently turned the machine on, and I had not issued any extrusion commands, I would have expected them to be showing zero. Further observation shows that during retraction/un-retraction (G10/G11)events, the "unused" extruder drives go from minus 5 to minus 10, then back to minus 5. This is the expected behaviour since the retraction amount is symmetrical and set to 5mm.

So essentially, the print starts with all extruders retracted by 5mm and continues with subsequent G10 retractions adding a further 5mm and then the G11 unretract restoring them to minus 5mm. For the filament which is moving forward, it starts at minus 5mm but then the skirt will move it forward so subsequent G10/G11s will work as normal. But overall retraction will be bad because the other 5 filaments will go from minus 5 to minus 10 and back to minus 5, rather than from zero to minus 5 and back to zero.

Looking through everything that happens with my pre-print macros, there is only one G10 event which happens after I purge the nozzle and there are no subsequent G11 commands. The first command in the actual gcode file is G10.

So I think this is what is happening. The purge macro has a G10 but no G11. The first command in the gcode file is G10 but this should not get acted on because there was no intermediate G11. I'm guessing there must be flag somewhere which gets set whenever a G10 command is acted and "unset" when a G11 command is encountered to prevent multiple G10s (or G11s) from being actioned. My guess is that this flag is either not set when G10 is run as part of a macro, or maybe the "flag" value isn't being carried over between the macro running and the gcode file proper being run.

I could get around it by editing all my gcode files to remove the first G10 but then the first G11 might not get acted on either. The only other thing I could do is remove the G10 from purge macro but then I'd be wiping the nozzle while it is still oozing filament.

EDIT. Firmware is 3.4 stable (I think).

oliof

@deckingman As a workaround, you might be able to replace the G10 with a normal G1 E-5 move to get a retract that's not messing up the relationship between G10s and G11s.

This is how it's usually done in IDEX/Tool changers where parking script does a "retract equivalent" move, and the tpre/tpost one does an "untetract equivalent" move (with the possibility that these park/unpark moves often are at different lengths than retract/unretract during printing). If you do want to ensure that your priming retract is always the same as you retract/unretract, you could read retract settings from object model to set the length and speed of the move. Or even wrap it in a G10.1.g script and then just use G10.1 so you only have to do liminal changes to your setup, keeping everything encapsulated.

deckingman

@oliof said in Double G10 retraction - happens but should not (IMO).:

@deckingman As a workaround, you might be able to replace the G10 with a normal G1 E-5 move to get a retract that's not messing up the relationship between G10s and G11s.........................

Yes that would be a viable temporary workaround.

dc42

@deckingman what I suspect is happening is that tool changes are affecting this. The current retracted/non-retracted status is saved per tool. This makes sense on machines for which different tools use different extruders, because you might want to retract filament in the old tool as part of the tool change procedure, and un-retract it for the new tool. So please check whether the purge macro and the G10 command in the print file are executed using different tool numbers.

PS - what is the reason why the purge macro contains G10 but not G11?

deckingman

@dc42 said in Double G10 retraction - happens but should not (IMO).:

@deckingman what I suspect is happening is that tool changes are affecting this. The current retracted/non-retracted status is saved per tool. This makes sense on machines for which different tools use different extruders, because you might want to retract filament in the old tool as part of the tool change procedure, and un-retract it for the new tool. So please check whether the purge macro and the G10 command in the print file are executed using different tool numbers.

PS - what is the reason why the purge macro contains G10 but not G11?

No, it's the same tool. The entire pre-print macro procedure is complex but essentially things get pre-heated, the printer is homed using tool zero (T0) with a partially heated hot end and mostly heated bed, then the correct tool for the filament to be used is selected but with the P0 parameter to suppress the tool change macros (in this case T4 P0) but to set the requisite temperatures. Then the print head is moved over the purge bucket and it waits (M116) for all temperatures to stabilise, after which it runs the purge macro (which is simply a G1 E100 F300 using the current tool, followed my M400 and G10). After that, there is a nozzle wipe macro which simply moves the print head back and forth across a silicone rubber strip while moving from left to right. Then it's into the gcode proper.

The reason for the G10 after purging is that the purge extrudes 100mm of filament and this hot end has a tendency to ooze. Usually (but not always) a purge is followed by a nozzle wipe and I don't want to wipe the nozzle while it is still oozing filament and I don't want to un-retract untill the print head is in the first print position. Hence retract first, then wipe, but hold off doing the un-retract. Then it's into the gcode file proper and because the first move is a non-print move, there is another G10 followed by the non-print move and then the un-retract.

I don't know if it's relevant but I usually add a Tn command into the gcode file - just to be doubly sure that the correct tool is selected and in case I ever change the pre-print macros. In this case, it is T4 (the same tool as selected for the purge)

So in terms of tool changes and G10 commands, the sequence for this filament is as a follows.

On machine boot - T0 P0
In the pre-print macro (which is called as the first line of the gcode file) T0 P0 (for homing which is common to all tools), then T4 P0 immediately after homing but prior to final heating and purging. Then the purge happens at the end of which is G10.
Then the gcode proper starts with another T4 followed by another G10, then the first (non-print) move to the start position in XY and Z followed by G11.

deckingman

I don't if this is relevant but the pre-print macros reside in the .sys folder while the purge, wipe and other macros reside in the macros folder. The reason for this is that I have multiple copies of the pre-print macros which do slightly different things depending on the machine configuration (6 input multi materials, 6 input mixing, single input, dual input etc), while the other macros are common across all configurations. This means that my slicer start code can simply contain the line (e.g.) M98 P"PrePrintASA.g" and I never have to change it. What actually happens will depend on how the machine is configured and thus which version of "PrePrintASA" gets called.

dc42

@deckingman the location of the macros does not affect how they are interpreted, although whether they are system-called macros or other macros does affect the behaviour in some ways, e.g. whether WCS offsets are applied to coordinates.

dc42

@deckingman I've checked the code, and this is how it works:

G10 is only executed if there is a current tool and it is flagged as "not retracted".
G11 is only executed if there is a current tool and it is flagged as "retracted".
When G10 or G11 is executed (i.e. the above conditions are met), the current tool is flagged as retracted or as not-retracted accordingly.
When a print is stopped, if the current tool is flagged as retracted then it is flagged as not-retracted and the current user position is updated to account for any Z-hop that was not undone.

So I don't see how it could execute two G10 commands without an intervening G11 unless either they were executing using different tool numbers, or the first one was in a print that was stopped.

You can check the retraction status of a tool in the object mode, it's at tools[N].isRetracted.

deckingman

@dc42 Thanks. The print I was running has finished so I've just spent a few minutes sending various Tn (with and without the "P" parameter) and G10/11 commands via the console but I can't replicate the behaviour I witnessed earlier. It's getting late now so I'll dig around tomorrow and see if I can find out what's happening. I guess the tool number theory is the most likely so I'll trawl through all my macros again to see if I can spot the error.

deckingman

@dc42 One quick question. What happens to the retracted/not-retracted flag with multiple tools on system boot? Do all tools get flagged as not-retracted when config.g is first read? Or is the flag set the first time the tool is selected? Another quick question - is it conceivable that using Tn P0 could affect the status of the retracted / not-retracted flag?

dc42

@deckingman tools are initialised to non-retracted when you create them using M563. Your Tn P0 command should not affect the retracted flag. A Tn command without the P0 could affect it if the tool change commands contain G10/G11 commands.

deckingman

@dc42 Found it ! Thanks for pointing me in the right direction.

The problem was that the version of the macro "nozzle wipe" that was on the machine, was not the version that I have on my PC. I don't know how this happened because I only ever modify files on the PC, then upload them to the SD card. But in this case, I must have modified the file on the SD card for some reason. This is what made it so hard to find.

In the event the version of "nozzle wipe" on the machine started with G10. Because it is also run as part of the homing macro (due to the fact that I use the nozzle as a Z probe), and because I home using Tool 0, this meant that there was a retraction using Tool 0 before it later switched to using Tool 4.

I didn't know about the G10/G11 flag being on a per tool basis (which makes perfect sense) so I've also learned something new and will know in future what to look out for.

dc42

@deckingman I'm glad you sorted it.

deckingman

@dc42 said in SOLVED Double G10 retraction - happens but should not (IMO).:

@deckingman I'm glad you sorted it.

So am I! I was beginning to doubt my own sanity