RE: The MMU2 Purge Bucket Thread (Mod/WIP)
Sure. Rub salt into my broken printer wounds 😛
😉
I like the v3 bucket. I think even without the long drop you have that will do a good job keeping things clear.
I'd like to try your updates on the purge speed. I know there was room to improve over what I had, but I kept running into issues where the extruder would grind and skip even at lower speeds. I wonder if that was just tuning for my idler, an extrusion issue, or some difference in how the Skele extruder drives the filament.
I forgot if you told me already, is that the factory extruder motor or an upgrade? If the later, 0.9 or 1.8?
I decree we should use "putting fingerprints on your PEI" as a better metaphor 😛
It's the skelestruder-recommended OMC pancake ( 17HS10-0704S). 1.8 degree, putting a 0.9 on a geared extruder is just silly since you already have a geared reduction. End result is a mass savings of ~220 grams or so over stock.
RE: The MMU2 Purge Bucket Thread (Mod/WIP)
I've pushed a number of processing script improvements to the repo; the tool should now be much more flexible in what it parses out of the printer settings rather than fixed defaults. I'm going to try a longer print this weekend and see what comes of it.
I do not yet know how well purging to infill and objects will work in conjunction with this tool. There is a minimum volume that PS will purge to the tower, but I'm guessing it will purge $total_purge-volume - $purge volume of objects/infill to the tower. We can't easily determine that last parameter without being tapped into the actual slicing process, or making the code massively complicated. So the solution here may just be to ensure your wipe object and infill has sufficient density to accomodate your purge volumes, and only ever dump the bare minimum to the waste bucket.
I will need to noodle on that problem some more.
RE: The MMU2 Purge Bucket Thread (Mod/WIP)
I inspected the gcode for purging objects and it may not be as bad as I thought. I've got some ideas.
RE: The MMU2 Purge Bucket Thread (Mod/WIP)
I've updated the repo with a fix for a bug that caused toolchanges to get skipped. The new version also has alpha support for wiping to objects and infill.
I got distracted by the possibility of implementing a toolchange randomizer that will randomly change tools during a print. I copypasta'd and bashed something out. You'll probably see that appear soon too, inspired by https://forum.prusa3d.com/forum/original-prusa-i3-mmu2s-mmu2-general-discussion-announcements-and-releases/multicolor-print-without-wipe-tower/#post-158877 and the lack of a palette-like mode.
RE: The MMU2 Purge Bucket Thread (Mod/WIP)
Damn! You are just rocking at this while I'm sitting here all grumpy about an uncooperative printer 🙁
RE: The MMU2 Purge Bucket Thread (Mod/WIP)
Damn! You are just rocking at this while I'm sitting here all grumpy about an uncooperative printer 🙁
RE: The MMU2 Purge Bucket Thread (Mod/WIP)
Proof of concept, the random toolchanger works. Ergo, I present, the (world's first?) MMU2 Cali(co)cat:
It's identified a few issues that I'll need to address (mostly stringing and needing to add a wipe prior to moving to the purge bucket)
Also, because the purged volume is much shorter, this will either need a brush on the bucket or tighter tolerances, once or twice it pulled out a ~4cm piece of purge and attached it to the print - but they do come off fairly easy when that happens.
RE: The MMU2 Purge Bucket Thread (Mod/WIP)
Update: I modded my bucket with a brush & nozzle wipe routine. It helps in some aspects, and hinders in others. I'll need to tinker some more. To complicate matters my PLA probably needs drying, it's gotten a little stringy and that tends to exacerbate the issue where the purged waste flips out of the bucket onto the print bed.
Sorry I haven't uploaded my random layer change script yet; gitlab's been giving me grief. I just haven't bothered to do a proper git checkout yet and have just been using the web interface.
RE: The MMU2 Purge Bucket Thread (Mod/WIP)
Bucket randomizer uploaded (randombucket.py). Still alpha, recommend running it through a gcode visualizer (e.g. pronterface) just to make sure it's doing what you expect.
Slice your to-be-randomized part in MMU mode normal (no toolchanges defined).
use the following additional startup gcode to configure:
; BUCKET_X <your bucket X position>
; RANDOM_TOOLS <highest T# allowed> e.g. 3 uses tools 0,1,2 and 3. This is so you can skip slot 5 if it has soluble support, etc or you want fewer than all 5 colours to be used.
; RANDOM_MIN_LAYERS = <Minimum # layers between toolchanges, default 5 >
; RANDOM_MAX_LAYERS = <Max number of layers between random changes, default 20.> (Note you may see more layers of the same colour in the case where the random pick re-selects the same tool again)
Separate script for now but they share a lot of code so I'm going to likely merge them at some point when I go through and do some cleanup.
RE: The MMU2 Purge Bucket Thread (Mod/WIP)
Hello,
Thanks @gnat for your files on GitLab.
I remixed some parts and published that on Thingiverse : https://www.thingiverse.com/thing:4096815
It's working very well!!!
RE: The MMU2 Purge Bucket Thread (Mod/WIP)
Are people still working on this? Would love to hear about updates on it.
(I have looked at the PrusaSlicer source and have my own ideas by the way.)
RE: The MMU2 Purge Bucket Thread (Mod/WIP)
Hey there - Sorry, development on the design itself kinda stalled due to other priorities; The BigBrain3d mechanism seems to work well for folks, and I just haven't done a huge number of multicolor prints recently that necessitated driving forward the code itself. I did, however, spin some updated and improved code for use with that mechanism. Feedback on the code would be appreciated if you do end up using it and find issues.
https://github.com/vintagepc/RPM-Post/
RE: The MMU2 Purge Bucket Thread (Mod/WIP)
Hello,
I got one, and assembled it, but I never installed it on my i3MK3S + MMU2S printer.
I don't like the logic that the motor of the X-axe should strongly press the lever with the extruder block to strive the springs to operate the movement. In addition I don't like to disable collision controls to make it work. I want the collision controls always on.
So I am trying to design an improved version, with a mini motor step controlled by an arduino micro, to operate its own movements required, without the help of the mk3 motors.
Not yet sure if it will be an independent device (e.g. that detects the extruder arriving and then moves the bar autonomously) or I will connect it to the MMU2 board.
However it should be absolutely reliable, and easy to setup Possible scenarios:
- Bucket should be controlled by its own microprocessor and motors.
- PrusaSlicer Dribbling, will be enhanced to support the bucket as a g-code generation option.
- Prusa MMU2 firmware enhanced to support new bucket command Tx
It is not an easy task and will require a lot of time, and I will start to work on it as soon as I will some spare time.
In this moment I am busy studying the MMU firmware to understand why it often loose the bearing position, moving too far from the filament and then it is not able to drive it correctly.
Stay tuned.
Cheers.
RE: The MMU2 Purge Bucket Thread (Mod/WIP)
Hello,
I got one, and assembled it, but I never installed it on my i3MK3S + MMU2S printer.
I don't like the logic that the motor of the X-axe should strongly press the lever with the extruder block to strive the springs to operate the movement. In addition I don't like to disable collision controls to make it work. I want the collision controls always on.
So I am trying to design an improved version, with a mini motor step controlled by an arduino micro, to operate its own movements required, without the help of the mk3 motors.
Not yet sure if it will be an independent device (e.g. that detects the extruder arriving and then moves the bar autonomously) or I will connect it to the MMU2 board.However it should be absolutely reliable, and easy to setup Possible scenarios:
- Bucket should be controlled by its own microprocessor and motors.
- PrusaSlicer Dribbling, will be enhanced to support the bucket as a g-code generation option.
- Prusa MMU2 firmware enhanced to support new bucket command Tx
It is not an easy task and will require a lot of time, and I will start to work on it as soon as I will some spare time.
In this moment I am busy studying the MMU firmware to understand why it often loose the bearing position, moving too far from the filament and then it is not able to drive it correctly.
Stay tuned.
Cheers.
FWIW, in my own testing, I:
- did not need to disable crash detection
- did not need to bump motor current
RE: The MMU2 Purge Bucket Thread (Mod/WIP)
Hello,
I got one, and assembled it, but I never installed it on my i3MK3S + MMU2S printer.
I don't like the logic that the motor of the X-axe should strongly press the lever with the extruder block to strive the springs to operate the movement. In addition I don't like to disable collision controls to make it work. I want the collision controls always on.
So I am trying to design an improved version, with a mini motor step controlled by an arduino micro, to operate its own movements required, without the help of the mk3 motors.
Not yet sure if it will be an independent device (e.g. that detects the extruder arriving and then moves the bar autonomously) or I will connect it to the MMU2 board.However it should be absolutely reliable, and easy to setup Possible scenarios:
- Bucket should be controlled by its own microprocessor and motors.
- PrusaSlicer Dribbling, will be enhanced to support the bucket as a g-code generation option.
- Prusa MMU2 firmware enhanced to support new bucket command Tx
It is not an easy task and will require a lot of time, and I will start to work on it as soon as I will some spare time.
In this moment I am busy studying the MMU firmware to understand why it often loose the bearing position, moving too far from the filament and then it is not able to drive it correctly.
Stay tuned.
Cheers.
FWIW, in my own testing, I:
- did not need to disable crash detection
- did not need to bump motor current
Agreed. I wouldn't slam the extruder into the bucket engagement shaft at full speed, but in my testing for @vintagepc's bucket I found a few things:
- You could do a fast move to a couple mm before the extruder touched the lever, then do a slower move to engage with no issues.
- The extruder could still travel the full length (255mm in my case) just as it does without the bucket.
I never did any testing with the BB bucket, but #1 should be true and I expect #2 is true as well.
I really need to get back to playing with the bucket idea, but the MMU is working flawlessly for me right now so I don't want to screw with things😉 I'm also not really printing much either so there is even less incentive...
RE: The MMU2 Purge Bucket Thread (Mod/WIP)
Looking through the PrusaSlicer source code a bit more, it's defiantly 'possible' to make it work from there, but it's gonna require a bit of work.
It seems there are (currently) deliberate measures in place to force a certain amount of filament to go to a WipeTower, with no options (yet) to disable a WipeTower or completely replace it with other objects.
Even though the functions to 'WipeIntoObjects' already exists, when you have multiple objects, each (individually) still wants to wipe to a WipeTower, despite whatever the WipeToInfill, WipeToObject settings are.
I can understand the 'why' part.. (cuz math is hard!), but it certainly seems like the following scenerios should work:
If you have a single MMU object, and just want to purge filament 'off the plate' (to purge bucket, etc), an option could be added for 'customWipeTower' and
instead of it moving around, just purged using the exact same code as the purge when you 'LoadToNozzle' (options to set how my times to cycle through it to ensure you get a clean color change),
and you could set it's location (like off to the side where PurgeBucket springs into place) by moving a PseudoWipeTower (small block)).
In another scenario.. something with 2 (or more) objects..
1 smaller object with 10-20 infill with no Wipe options, the other object (same size or larger) set with 'WipeIntoThisObject' and 'WipeIntoInfill', and infill set to 100%.
If it weren't for the 'mandatory' WipeTower, there is plenty of room in the larger 'trash' object to wipe into and there should be no need for a WipeTower.
In cases where you have 1 main object (the actual desired MMU print), and several smaller 'WipeTo' objects, (still useful because of their shape, but you don't care about the colors), it should
work the same. The math on it would be something like
AmountToWipeIntoEachWipeObject = ( (definedPurgeAmountPerFilimentSwap * numberOfFilimentSwaps) / numberofWipeObjects))
(a bit more complex than that because of loops and things (and math-logic may not be correct there), but you get the general idea)
Once the full amount for Wipes (at each layer) us 'used up' by all the 'WipeObjects', (+ supports if present) then it can go to a wipe tower, but only if there is 'left over' stuff that needed swapping.
Getting rid of the First initial Wipe and the last one and just using a standard WipeStripe (if needed or chosen as an option) would also save alot of time and filament.
Looking at the code, it's an older 'style' and the way it's written, it seems like only a few people (or maybe just 1 person) is actually working on it.
Lots of comments, which is good, but also lots of 'placeholder' stuff where they either didn't have time to mess with something, or haven't figured out how they are going to do it yet.
It would help if the coders could provide some insight into 'future plans' with respect to this particular aspect of things, so that we know if we should continue to wait in the hopes they eventually add
functionality for it, or use something else if they plan to deliberately not have that functionality (I can certainly understand why they wouldn't want it.. hard to code, hard to maintain (especially with future updates),
might require either a seperate 'module' or even a completely separate version of the slicer, and they might even sell less filiment if people weren't wasting so much of it. (that last part is a joke.. it's openSource.. if that was their intention,
there are tons of better ways to do it that wouldn't risk an all out 'rebellion from the peoples'. hehe).
I haven't delved TOO much into the code yet to see exactly what would be required, but I think a of team of 2-3 people, experienced in VisualStudio2019 and previous versions, as well as the knowledge requires to re-compile
some libraries (in Linux is probably easiest), could probably sort it out in a week if they had time to dedicate to it.. a few months of they all were really dedicated to it but had other jobs.
I work full time and don't have much to spare these days.
(Today is actually my first 'vacation day' in several years.. and I am still kinda working (phone calls, text, emails, etc). I actually just want a nap! LOL!)
In the meantime, GCode workaround seems to be the best option.
BigBrain is doing a fantastic job with it so far and I am sure, as time allows, there will be more updates to the project.
There is an obvious 'need' for it to happen.. it's probably just going to be a matter of 'who gets to it first' and which way is easiest for non-experienced users to implement.
(Buy/print a 'snapOn bucket' kit and copy/paste some gcode into slicer; VS. the slicer has built in support for customized-purging off the side (bucket) and/or into other objects (in place of a WipeTower).
Either way, gonna be interesting to see what happens with it.
As an Aside, I did a manual filament swap (with simple 10mm purge) for an MMU Gecko.
It DID work, but my arms got tired after about 2 hrs.
(it was then that I truly appreciated what the MMU2s does.. although I'm still upset that it has to use a WipeTower since that is also the same moment I realzied just how much filament was being wasted
for no obvious reason I could see at the moment).
RE: The MMU2 Purge Bucket Thread (Mod/WIP)
Looking through the PrusaSlicer source code a bit more, it's defiantly 'possible' to make it work from there, but it's gonna require a bit of work.
Actually it should be easier than that. There is an option to disable the wipe tower entirely and there is another that allows you to provide custom tool change code. Between those two you can use a bucket.
The catch, at least the last I looked, is that you don't have access to the custom purge functionality so you would need purge for you worst case (e.g. black to white) which would result in wasted filament for other changes that don't really need much purge (say black to a dark brown).
although I'm still upset that it has to use a WipeTower since that is also the same moment I realzied just how much filament was being wastedfor no obvious reason I could see at the moment).
The purpose is two fold. First is to make sure that filament has indeed reached the nozzle. The second is to avoid/limit bleed. When it ejects the previous filament, there is some left in the nozzle and it won't simply push out first.
It was a very nice feature add when they gave us the ability to tweak purge volumes so that we could reduce the waste for colors not likely to bleed and increase it for changes where bleed was probable.
RE: The MMU2 Purge Bucket Thread (Mod/WIP)
@gnat
Having the ability to set 'purge amounts' on a per-change basis would be a nice option, but should probably be 'hidden' in the 'Simple' mode.
If you have time, can you see if you can replicate this?
Drop the MMU version of the ShockerLizard into 2.2.0.
That is the 'main' print.
Now add the solid (original) version (the one with the base), make it just slightly larger ..
that will be your wipe object.
Set the eyes of your main print to be some color different than the others.
(for this I had eyes set to green, the body purple, and the rest yellow.. not sure if it matters)
Now Disable WipeTower and slice.
See if you see any green (or whatever eye color you chose) in the supports or the wipeObject.
(I don't)
Now enable the WipeTower (leaving second WipeObject) and slice again.
Eye color now shows up in both the wipeTower and the wipeObject...
But no matter how big you make the WipeObject, it won't lessen the amount of the eye-color that wipes into the wipeTower.
I understand that it's trying to keep up with the layer-height while at the same time, trying to save time by not swapping filament again, but it seems like it's doing several full wipes worth into both objects, instead of just using whatever the minimum is to maintain the layer height in way that doesn't cause collisions. and then it wipes to the tower again at the 'end' for some reason (just before tool change.. ramming settings maybe?)
Also, if you now lower the width of the wipetower (from 60 to 10), it compensates by making the wipe tower longer, but still splits the eyecolor with a bias toward the wipeTower (and, on mine at least, it even changes to that color just to wipe into the tower (wipe tower only.. nothing else.. not the wipeObject, or the main Object).. like 50 layers before that color even starts in the main print.)
Is that a bug, or am I missing something?
If I don't disable the WipeTower, it seems to work ok, but then it wastes all the filament, just trying to keep up
with height.
If I don't disable the WipeTower, and add a single wipeTo object, it wastes more filament that it would normally, because it's forcing itself to wipe into the tower from 'both' objects (so that part has to also 'keep up' with the layer heights)
If I do disable the WipeTower, and use a single wipe-objects, it seems to 'skip' wipes sometimes, and once, it just skipped the color entirely and it mixed up the order (that was quite a while back though so could have been something else that got fixed.. but the issue still appears to do the same in the slice 'preview' )
If I disable the WipeTower and have multiple wipe0Objects, it does the same thing as having the wipe-tower and wipe-objects, extending the wipe-color into the other objects.
(i.e. instead of it checking for how much it needs to wipe to do a color change, it seems like layer height is priority and it just splits it and keeps going (for layer height), but has a bias toward added objects and wipe-tower.. like it doesn't seem like an even split percentage of totalwipeAmount+Whatever is left to keep up layer height into the wipe-objects (+wipeTower if there is one).. seems more like it's going by how may objects there are and biasing towards the latter ones and putting more of that color in later ones (including wipe tower).
I'm still experimenting with changing sizes of 2nd,3rd objects and going to attempt 'different' objects as well
to see if that makes a difference (hollow cubes maybe.. would probably be easier to 'see'.
(any suggestions appreciated)
The PurgeBucket option seems to solve a lot of those issues all at once.. but again, the ability to control
how much is purged is gone when the wipeTower is disabled, leaving only gcode to handle it (manually)...
unless I am missing something.. which is entirely possible. LOL!
Thanks!
RE: The MMU2 Purge Bucket Thread (Mod/WIP)
You cannot wipe-to-infill or objects when the wipe tower is disabled, PS does not run the calculations.
I have open PRs for both leaving the volumes enabled for custom toolchange sequences
( https://github.com/prusa3d/PrusaSlicer/pull/3573)
and leaving the wipe calculations enabled when doing custom changes w/o wipe tower:
https://github.com/prusa3d/PrusaSlicer/pull/3576
At least some of your observations are explained by the filament settings. There is a 'minimal purge on wipe tower' setting per-filament that dictates how much is guaranteed to be put on the tower.
RE: The MMU2 Purge Bucket Thread (Mod/WIP)
Actually it should be easier than that. There is an option to disable the wipe tower entirely and there is another that allows you to provide custom tool change code. Between those two you can use a bucket.
The catch, at least the last I looked, is that you don't have access to the custom purge functionality so you would need purge for you worst case (e.g. black to white) which would result in wasted filament for other changes that don't really need much purge (say black to a dark brown).
You have access to the values in the gcode's config dump, but you can't change them in PS unless the wipe tower is enabled. My various PP scripts I wrote/extended for this project do all use those values and respect them.