DWC and Lots of Tools
-
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...
-
A few more notes..
This is on an M3D Crane Quad. with a four port mixing hot end -
@nanoplane I've had a quick look at your files. One thing which leaps out at me is your settings for firmware retraction. With mixing hot ends with a single nozzle output, it is important to retract all filaments concurrently. For that reason, we normally only use a single M207 command and omit the tool number. Given that you use the same retraction values for all 25 tools (as is advisable with a mixing hot end) then I suggest you try simply using a single M207 command (without a tool number). Put this command in your config.g file and delete or comment out all the M207 commands that are in your gcode file.
The ability to use a tool number with firmware retraction is a very recent feature, so it could be that you have uncovered a bug in DWC which only applies to this particular scenario. But as stated above, with mixing hot ends, it is advisable to use the same firmware retraction value for all tools in any case.
Let us know if that helps or otherwise.
-
@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?
-
@nanoplane Not sure what the problem is. I run a 6 input mixing hot end and by default I have 11 tools defined. I've never experienced the issue that you are seeing. Apart from the firmware retraction "thing", the other differences are that all my tools are defined in config.g. But I regularly change the mixing ratio "on the fly". Maybe the firmware or DWC doesn't like defining tool once a print has started, which is what is effectively happening if you use the slicer to define the tools? Dunno - just a guess.
Other differences with my set up is that I have a generation 3 6HC main board, rather than a Maestro and 3 expansion boards with 3 extruders connected to 2 of those expansion boards but that shouldn't really matter.
-
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...
-
@nanoplane Ahh OK. It does rather look like you've found a bug but we need an official response from the Duet team (I'm just an end user like you). I have to confess to never having used more than about 12 tools at any one time. I have printed 300+ colours but I tend to "recycle" the same tool and simply change the mixing ratio. I don't know if that's a viable option for you but it might be work around until you get an "official fix".
-
@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.
-
@nanoplane There never used to be a limit but one was introduced with version 3 some time back. However, I was told that was 50 tools.
Ref mixing hot ends, now all we need is one that actually mixes. I'm working on it.,..... You'll find the quad also suffers from the stripey toothpaste effect. M3D mitigate it a bit by adding transparent filament into the mix. But that reduces the other combinations to 3 inputs and we need black and white as well as CYM.
-
@nanoplane, this issue is caused by RRF running out of message buffers, due to the very long response needed when DWC requests the 'tools' subtree of the object model. I think the best fix will be to change DWC to request the data for each tool individually when there is a large number of them.
-
@deckingman said in DWC and Lots of Tools:
we need black and white as well as CYM.
When I tried 3 color mixing, I had a hard time to find one vendor selling all the CYM filaments.
Did that change over the past 3 years?
I also had trouble because Cyan often was refered to as lightblue or other less helpful names. Same to magenta.For your on_the_fly mixratio changes, would it help to have 3 (or 6) encoders on the printer and a small LCD that would show the RGB/CYM values? Or an RGB-Led that indicates the chosen color?
-
@o_lampe said in DWC and Lots of Tools:
@deckingman said in DWC and Lots of Tools:
we need black and white as well as CYM.
When I tried 3 color mixing, I had a hard time to find one vendor selling all the CYM filaments.
Did that change over the past 3 years?
I also had trouble because Cyan often was refered to as lightblue or other less helpful names. Same to magenta.For your on_the_fly mixratio changes, would it help to have 3 (or 6) encoders on the printer and a small LCD that would show the RGB/CYM values? Or an RGB-Led that indicates the chosen color?
You'll still have a hard time finding CYM filaments. But unless you can truly mix them together, it's pointless because when the "mixed" filaments come out as striped, the colours will vary depending on the viewing angle. I simply settle for light blue, red and yellow (with white, black and clear).
Getting the filaments truly mixed is still on my list of objectives but I've largely taken a break from 3D printing just now. Maybe I'll get back to it at some time in the future and re-visit my 6 input mixing hot end which was showing promise but still had some way to go.......
-
@deckingman said in DWC and Lots of Tools:
Getting the filaments truly mixed is still on my list of objectives
Back in these days, I started experimenting with a post processing script that mixes the colors while printing the perimeters. The nozzle would run in rectangles across the perimeters instead of individual straight tracks. It was horrible, because the Diamond hotend was heavy and the small moves made the printer shake.
