Some questions about firmware retraction on a toolchanger

sonderzug

Hi all,

I'm using an E3D Toolchanger (currently on FW 2.05.1) and had some unpleasant issues in connection with firmware retraction.

The reason to use firmware retraction is that Cura doesn't seem to handle the Toolchanger and its retractions very well (and multiple materials/print heads in general, but that's another issue). I feel that it's easiest to load arbitrary filaments onto arbitrary tools when the according retraction setting is stored in a central location, such as a filament script.

First, I am aware that FW 3.01 and onwards now handles different sets of M207 params for each tool, which seems very handy. ATM I moved the M207 for each print head/filament to the post.g, which works okay
IF the retraction settings have the same z-hop value: if not, it seems that the state of retraction/z-hop is not remembered across different tools.

I have some issues with z-height that I am nailing down to this combination (tool changing and G10/G11 retraction), but it isn't totally clear to me how this is actually handled.

if a tool is retracted (including a z-hop) and another one selected which is then unretracted, will a possible varying z-hop height be respected and corrected for?
can a tool actually print in retracted state? This would seem counterintuitive since there would be a length of filament missing and the z-value might be wrong (I suspect strongly that this might be one of my issues)
there was a discussion about this here: https://forum.duet3d.com/topic/9507/unretract-after-tool-change where the user had the issue that, when retracting after priming in the post.g, there was no unretraction before the first printing move afterwards was started. I have this same issue. Intuitively, keeping in mind my former point, if a tool is retracted then before any next printing move, an unretracting move should be inserted first.
can the retraction state somehow be shown? It seems that I've actually done some z-height calibration in the retracted state of some tools that obviously messed some things up.

I'm hoping for some input, especially in regards to any updates in the firmware since 2.05 that would improve my experience and make an upgrade to 3.x worthwile (aside from above mentioned M207 and other obvious advantages). Thank you all in advance,

Best regards, Niklas

dc42

@sonderzug said in Some questions about firmware retraction on a toolchanger:

I have some issues with z-height that I am nailing down to this combination (tool changing and G10/G11 retraction), but it isn't totally clear to me how this is actually handled.

if a tool is retracted (including a z-hop) and another one selected which is then unretracted, will a possible varying z-hop height be respected and corrected for?

Yes. RRF remembers the actual amount of Z hop used, and undoes that amount when G11 is executed.

can a tool actually print in retracted state? This would seem counterintuitive since there would be a length of filament missing and the z-value might be wrong (I suspect strongly that this might be one of my issues)

Yes.

there was a discussion about this here: https://forum.duet3d.com/topic/9507/unretract-after-tool-change where the user had the issue that, when retracting after priming in the post.g, there was no unretraction before the first printing move afterwards was started. I have this same issue. Intuitively, keeping in mind my former point, if a tool is retracted then before any next printing move, an unretracting move should be inserted first.

RRF never inserts retraction or reprime (unretraction) moves. When changing tool, slicers typically issue a retraction command for the old tool before the T command, and a reprime command for the new tool after the T command. But there is nothing to prevent you from doing a retraction at the start of tfree#.g and a reprime near the end of tpost#.g if you want. If you execute G10 twice without an intervening G11, RRF will ignore the second one. Similarly if you issue G11 when you haven't done a matching G10, the G11 will be ignored.

can the retraction state somehow be shown? It seems that I've actually done some z-height calibration in the retracted state of some tools that obviously messed some things up.

Yes I can add it to the object model.

sonderzug

@dc42 thank your reply.

Yes. RRF remembers the actual amount of Z hop used, and undoes that amount when G11 is executed.

so to clarify; if the code looked like this

[active tool T0]
...print moves...
G10
T1
G10

would T1 actually be retracted again since there has been a G10 before? (not actually a reply to your statement above, but a consecutive question).

Thank you,
Niklas

deckingman

@sonderzug said in Some questions about firmware retraction on a toolchanger:

@dc42 thank your reply.

Yes. RRF remembers the actual amount of Z hop used, and undoes that amount when G11 is executed.

so to clarify; if the code looked like this

[active tool T0]
...print moves...
G10
T1
G10

would T1 actually be retracted again since there has been a G10 before? (not actually a reply to your statement above, but a consecutive question).

Thank you,
Niklas

I'll wait for the official answare from @dc42 but I would expect and hope that that the second G10 would not get acted upon assuming that there are no G11 command in tfree.g or tpost.g.
The reason why this should be so is that individual tools don't always have uniquely different extruders. So in your usage case example, if T0 and T1 were two tools of a mixing hot end and shared the same two extruders but with different mixing ratios, then one would not want to perform the second G10 retraction unless there had been a G11 un-retract command in between the two.

dc42

@sonderzug said in Some questions about firmware retraction on a toolchanger:

would T1 actually be retracted again since there has been a G10 before? (not actually a reply to your statement above, but a consecutive question).

Each tool has a separate retracted/not-retracted status. So in the above example, retraction would occur twice, assuming that tool 1 is in the "not retracted" state at the start of that sequence.

A possible workaround if you don't want the retraction to occur more than once is to put a G11 command in the tfree.g files, to cancel any G10 in effect when the tool is released.

cosmowave

@dc42 said in Some questions about firmware retraction on a toolchanger:

Yes I can add it to the object model.

Do you know, when the retract state is available at OM? Will that be in the next update?

dc42

@cosmowave said in Some questions about firmware retraction on a toolchanger:

@dc42 said in Some questions about firmware retraction on a toolchanger:

Yes I can add it to the object model.

Do you know, when the retract state is available at OM? Will that be in the next update?

Yes, I have added a new field isRetracted to the Tool object model.

deckingman

@dc42 said in Some questions about firmware retraction on a toolchanger:

Each tool has a separate retracted/not-retracted status. So in the above example, retraction would occur twice, assuming that tool 1 is in the "not retracted" state at the start of that sequence.

That could be problematic with a mixing hot end. So for example, both T0 and T1 use the same extruders and nozzle but with different mixing ratios. If both tools were in the un-retracted state then T0 G10 - T1 G10 could lead to double retraction. Maybe the retraction status should apply to extruder drives rather than tools?

dc42

@deckingman said in Some questions about firmware retraction on a toolchanger:

If both tools were in the un-retracted state then T0 G10 - T1 G10 could lead to double retraction.

Yes. But would you ever do T0 G10 followed by T1 G10 without an intervening G11?

Maybe the retraction status should apply to extruder drives rather than tools?

That would get complicated if you switch to a mixing tool that has some drives marked as retracted and others not. Besides, the Z-hop element of G10/G11 is independent of extruders.

deckingman

@dc42 said in Some questions about firmware retraction on a toolchanger:

Yes. But would you ever do T0 G10 followed by T1 G10 without an intervening G11?

I could foresee a scenario where that might occur. A purge macro might consist of a G10 retraction, a non-print move to a "bucket" followed by a G11, then an extrusion, then another G10 to end the purge - probably followed by a nozzle wipe for which a G11 would be undesirable. One might run that as part of a pre-print routine but also after selecting a tool. If the pre-print purge ended with (say) T5 - G10 but the first command in the gcode file was T0 which instigated the tool change macro, then one would get another G10 without an intervening G11.