Yep, that's it....

Recreating or adding a new tool sets the retraction to a default value of 2mm..

So I need to add an M207 S0.5 F1000 Z0.2 command to my custom gCode after creating all the tools...

cool.

@deckingman
For me, I just split the task into two parts. no problem... The task I'm working on is a color cube that can act as a reference when selecting colors and mix ratios. It actually has 125 colors but I can easily change colors vertically within a single tool.

I've built a special version of SuperSlicer (based on PrusaSlicer) for this called SuperSlicerMx. it added built in support for mixing hot-ends while still maintaining the model of a "color" per extruder... but in this case a color can be a single color, a gradient or a set of layers.. so far it's been pretty effective. I'm also adding special purging / wiping functionality for mixing hot-ends to deal with back flow and "bubbles". Great fun..

I do wish that ReprapFirmware didn't have a fixed limit on the number of tools though.

They have responded to my issue in GitHub.. we'll see how it goes.

@deckingman

The whole thing works fine if I limit the number of tools I'm creating to < 19 :-).. but I was printing a color cube, which required 25 tools to be defined. If I split that up into two jobs, it all works fine...

If you create the tools one at a time using the console, the same failure happens, so it's not a print file thing...

@deckingman
Yes, I know about the retraction...
What I did miss was that setting retraction without a tool number applied to all of the tools...

In my case, it will always retract all filaments equally, but it might do it differently based on the current mix... not that that would be that useful :-)...

It would be much easier though if I had a single retraction update after all the tools have been created... I'll implement that..

Thanks.

Note that the problem I'm having doesn't seem to be related to the retraction updates... If I remove all of those commands, it still blows up..

Also, There appears to be corruption in the actual data when printing.. I'm not sure this would be a DWC issue since I think once it's transported the file, RRF takes over the actual printing, doesn't it? or could DWC be corrupting the RRF code base?

@phaedrux

A few more notes..
This is on an M3D Crane Quad. with a four port mixing hot end

@deckingman

So most of the tools I'm creating via GCode in my print file. I can send you a short version of that as well...

config.g tooltest.gcode

@phaedrux

Firmware version 3.2.2
DWC version 3.2.2

So, I've posted an issue on GitHub. When this happens, there appears to be some data corruption going on since I get weird effects. In particular, some of the filament drivers are running backwards... On a mixing hot end, this is just bad....

@o_lampe Yes, that was my expectation.. hence the surprise when things blow up. :-).

@owend
I get 50 as the limit

18 tools total seems to be the limit.