Feature whish: Colorchange with MMU2s Channel switch
Hi everyone
today i had to print some simple keychains with a color change
i think prints with only one change of filament at a special layer are more usual than fully multicolor prints
why there is no chance to use the mmu in that case?
Color change
retract old filament, change to next channel, reload new (purge remove by hand)
or
(even better)
retract old filament, change to next channel, reload new and purge to air or single layer outside the model
for now there is only the functionality to print all the layers an additional purge tower for that one change during the print...
do you think that functionality is usefull for the future?
RE: Feature whish: Colorchange with MMU2s Channel switch
Instead of using the Colorchange feature you can slice the model for a MMU print using the Height range Modifier of Prusaslicer 2.1.
RE: Feature whish: Colorchange with MMU2s Channel switch
@petr-f12
I tried that
But in that case you have to use the purge tower on every layer
I think that's a lot of waste for a single change
RE: Feature whish: Colorchange with MMU2s Channel switch
You may want to look at my and Gnat's purge bucket mod. It really shines in situations like this where there are infrequent changes high up in the model:
RE: Feature whish: Colorchange with MMU2s Channel switch
@planetace
Of course you waste some filament in the wipe tower but it is hollow. In my example there were 7.52 m of filament used in the object and 0.29 m of filament used in the wipe tower. I wouldn’t call it a lot of waste. For me it is an acceptable price for a comfortable unattended print.
RE: Feature whish: Colorchange with MMU2s Channel switch
(Don't forget the wipe tower also adds (not insignificant) time to the print)
RE: Feature whish: Colorchange with MMU2s Channel switch
Thanks @vintagepc
I will check that link when I am back at home on Sunday
@Petr-f12
Sure, the waste is not that much but I would love to find a solution without that waste
A semi automatic change of the filament channel would be another nice solution I think
In that way we would be able to prepare alle the changes
Click once
Pick the little waste
And that's it
RE: Feature whish: Colorchange with MMU2s Channel switch
We are testing a new wipe tower option to only print the wipe tower layers where a tool change happens, and to lower Z towards the wipe tower if necessary. It looks promising, but as of now we don't have any automatic check for collisions of the print head or the X rods with the printed object. If you put the wipe tower to the rear right corner and the object to the left front corner, for most prints the collisions will be avoided and such feature will be a winner for a MMU supported automatic color change.
RE: Feature whish: Colorchange with MMU2s Channel switch
That'll go a long way to reducing waste for sure!
(But a bucket mod goes a step futher towards enabling MMU prints at lower layer heights that would otherwise require an unholy amount of build space for the purge tower's volume... 😉 so I plan to keep working on it once my MMU is back up and running)
RE: Feature whish: Colorchange with MMU2s Channel switch
PrusaSlicer can calculate the exact space occupied in the space by the object during the slicing. Then it can be set to "know" the exact measure of the i3MK3S/MMU mechanical parts and so be able to calculate the free space required to move the axes and the nozzle around the object without hitting it . No need of collision sensors. It can be mathematically calculated, I know its very complex, but it technically possible.
RE: Feature whish: Colorchange with MMU2s Channel switch
We are testing a new wipe tower option to only print the wipe tower layers where a tool change happens, and to lower Z towards the wipe tower if necessary. It looks promising, but as of now we don't have any automatic check for collisions of the print head or the X rods with the printed object. If you put the wipe tower to the rear right corner and the object to the left front corner, for most prints the collisions will be avoided and such feature will be a winner for a MMU supported automatic color change.
Not entirely true... turn on sequential output and enjoy shuffling things around the build plate and getting yelled at because it can't print them in that order for size constraints... for exactly those reasons (object and extruder or x-rod interference).
Seems you should be able to leverage that code for this too...