@MalcTheOracle Spot the Lack in here - may look a bit flimsy - but working out pretty well so far for me for the last few months.
Making some progress with incorporating the melted flat sheets into my ‘purge block’
system.
Plus some smaller stand alone brackets - for making things like boxes etc.
Quite pleased with the little 3d printed grub screws.
Test prints in solid colours - but will eventually start creating them as flush-into ‘purge blocks’
Ready to start Britannia printing.
Without flush objects - Flush ratio about 110% - print time 18h17m
With lots of flush objects - print time up by 9h28m to 27h45m, but flush ratio down to less than 5%
Print time for flush objects by themselves would be 11h40m - so also a couple of hours total print time saving.
Is there a way to utilize print by object instead of print by layer to manage the waste? It would be preferable ensure proper clearance to print a separate object (or group of objects) of Exactly 109 g in the ship example to printing an additional 169 g of material to recover the 109 g.
This would create challenges with ensuring proper print head clearance but I would think it would be more efficient provided the gcode can be adjusted to create a safe path to where the last object layer where printing was paused.
Yes it would certainly be technically possible to reduce the number of purge objects by allowing the print head to up or down a few layers when doing the purge objects, and this would reduce the total print time down possibly to close to the time it would take to do normal off bed purge.
My focus so far has been mainly on keeping things as standard as possible - but I do agree that the substantial increases in print time that are often needed to save the purge are difficult for many people to accept.
indeed I have recently myself done quite a few standard prints without flush objects, as the waste is less of an issue to me now that I have the melted flat sheet solution.
I think a good way of approaching this is to do some GCODE analysis of for example the most recent print I did, to see whether it would be possible to post process it and automatically remove one or more whole flush objects by introducing a degree of Z axis freedom when creating the other flush objects.
I think it should be possible to include within the logic intelligence to avoid the head clashing with objects already printed.
I am in the early stages of working on something similar related to avoiding head clashes when doing parallel printing using multiple fully independent print heads trying to print in parallel on the same fixed print bed.
I am thinking that some sort of Blender addin might be able to help with this - as its possible within Blender to model the precise structure of the print head, rails, movement and print as it grows up - so that you can then check that any paths generated to do clash with the print or other print heads.
Update - raised a BS enhancement request for this feature here
Nice haul of extra table parts - and only 8g of waste (BS estimate 5.85), or total of 21g including slightly messy prime tower.
interestingly I didn’t get any purge shoot build ups with the 27hr print spread over about 45hrs.
One part failed slightly near the end (on near the prime tower), and unfortunately due to a design mistake with supports the actual multi coloured print isn’t good enough for release.
Will you leave these looking like an acid trip or do you intend to paint them?
No I like the colouring of the flush-block parts. I am however planning to try printing directly onto the flat sheets at some point - so I could I suppose cover up the colours with a couple of layers to flatten them out which would also mostly hide the colours on the less attractive sheets.
Interesting result so far.
Further up you asked the question if it is worth reducing the flushed filament while increasing the print time. I think that entirely depends on what value the flushed-into-objects hold to you. - Same with sheets and compressive molds from waste.
My thoughts:
A lot can be done but the biggest hassle (mainly in the first world) is that we simply do have nearly everything in abundance and these “products from rescued ressources” often look a bit silly right next to the common casual products - or are plain inferior to what we are accustomed to.
But, a table it is and it works. If you have no table at all, there already is value.
Not directly flush waste related - but have been working on a gcode post processor to segment up prints vertically - for parallel printing (which I am still hoping the 1Q25 BL printer has) - by cutting out parts of the print within a particular rectangle - and adjusting any lines or arcs that may be partly in and partly out of the segment.
Could also quite easily do things like post process the gcode to remove things like the prime tower.
Some examples of the output attached - the biggest issue is probably travel moves around the cut edge.
Straight lines aren’t too difficult as they only intersect the border in a maximum of 2 places. Arcs are a lot more complicated. In the short term I solved the issue by converting the arcs into lots of little straight lines.
Before
After
Travel moves (shown in blue) around the edges of the segment are probably the biggest issue.
Example of more complicated print - which took quite a while to process
I am curious about your use of python, here. Can you share more about your scripts? It has been a while since I’ve used python. I’d love to figure out how to optimize my prints for my kids. They love using the AMS, but some of these trinkets weigh 4 grams and purge 24 grams!
Unfortunately I haven’t progressed my scripts to a state where they are suitable for sharing.
My aim was to create a ‘print queue’ - which would manage a list of ‘to print’ objects - and then automatically select the right ones to match the print in question - working out which object best matched the objects to be printed in terms of layers where colour changes happened etc.
More recently I have focussed more on just manually adding parts of my purge table, or just letting the purge happen and then melting it into flat sheets.
If I ever get back to working on this - I think what I will want to do is create a post processor that firstly selects ideal objects for flushing into - plus also modifies the gcode to move the Z position up or down a little bit - so that the flush objects ideally don’t add any additional time to the prints.
Lets get back to work dave!!! lol
j/k
Great read!
Thanks. I’ve been distracted for the last few months on a project that will hopefully be demonstrating dramatic reductions in print speed and waste for big multi colour prints - but the launch of the H2D will probably bring this thread back to life soon.
Its interesting to see that they seem to have changed the shape of the prime towers which might bring some benefits in terns of being able to slot them together into something useful.
I think I need to solve the issue of flush-into objects making overall print time longer before I start using them again.
I’ve been working on some fairly complex gcode manipulation for my non BL parallel printing project so might be able to use some of that to help with the flush issue,
I think the way to do this is to
-
have a fairly simple queue of ready sliced extra objects for automatic adding to multi colour prints.
-
Write a gcode post processor that takes the gcode from a normally sliced off bed flush/prime tower multi colour print and reworks it so that
a) All of the off bed flush goes into the minimum number of flush-into objects added from the queue.
With logic to allow the print head to go up or down a few layers while doing the flush-into object printing - to limit and in some cases completely eliminate the extra time overhead you almost always get with flush-into objects due to the extra non flush parts of those objects.
b) also remove the prime tower - making sure all priming needed in instead done in the flush-into objects.
Using this approach I think it should be possible in most cases to make flush-into prints slightly quicker than standard multi colour prints (instead of up to 30% slower) whilst also pretty much eliminating waste.
I think some of this prime tower stuff could also apply to H2D 2 colour prints.
Moved some posts here from another thread which I think it is getting a bit confused between flush and prime.
Allowing the prime tower to be a little bit lower than the model is a feature of
prusaslicer (which BS is based on) called ‘no sparse layers’ I think - I always used it
without issue on the Prusa Mk3s with MMU2.
The prime tower would still need to keep fairly close in height to the print to avoid the
impact mentioned of long slow Z axis travel moves, plus the risk of the model hitting
the gantry or top glass when it is raised to give the print head access to a lower prime
tower.
I’m expecting the larger build plate of the H2D to help with this sort of thing too - as it
will allow more room for different height objects to be printed at the same time without
risking gantry clashes.
For me the ideal ultimate solution would be to allow
A) ‘flush-into’ objects to also be ‘prime-into’ objects.
B) for these ‘flush/prime’ objects to where practical be built at slightly lower Z heights
than the main multi colour objects.
I’m planning at some point to write a post processor (similar to the old Palette2 P2PP
prime tower features) to demonstrate the benefits of this type of approach on waste
and time savings to prime towers and ‘flush-into’ objects - which I think could be quite
substantial - including for 2 colour H2D prints,
Looking at the motion abilities with BS - it looks like Z is around 25x slower and
accelerates 40x slower than X&Y. Looks like the Z axis can get up to 30mm/s - so I
agree that the Z height of the prime tower needs to keep within a few mm’s of the
object - as >2 seconds for example for a 60mm Z move would be too long to maintain
the benefits of priming.
It looks like there is already a 0.4mm Zhop as part of the prime tower back to object
move .
I see both prime and flush as waste - both of which could be put to better use if they
went to usable objects - rather than being discarded.
I don’t think there is really a good reason for having both a prime tower and flush-into
objects. Because the flush-into objects effectively prime - as they come between the
prime tower the object print. However when I tested it flush-into only works when you
specify a prime tower.
I did run a few tests with prime tower + flush-into - but with the prime tower stripped off
of the print by a post processor, and it seemed to work ok. Haven’t tried it on an H2D -
which I think needs a prime tower more than the X1C - as you get a lot more wisps on
the side on H2D prime towers than on the X1C.
For another printer I am working on - which actually requires 3 prime towers I have actually modelled the prime towers as individual objects - which could eventually be something useful, and then using the ‘Intra-Layer-Order’ option in Orca Slicer
Put the prime objects first in the order, and also named them prime
Then they act automatically like little prime towers.
NB/. A post processor then actually picks out the prime object for parallel printing too - so that priming is done in parallel to tool changes - a feature that I hope will be available in future Bambulab printers - see my YouTube channel @dwuk3d for more info if anyone is interested.
This topic deserves a bump! I know it’s a few years old but I’m seeing it for the first time, and I want other people to see it too. Even if we’re not tackling making furniture with the purge waste, it’s a great idea and I want to play with it. Thanks for sharing your experiments and learnings!
Thanks for the bump - one interesting point on this subject is the fact that no sparse layers is now available in the Beta BambuStudio - will try that when I get back to printing - as a few of my models have quite a few layers without a colour change.
No sparse layers - combined with so slight shape tweaks to the prime tower so that it can be used for something useful is pretty much as far as I think you can go - other than stopping the off bed purge whisps you get when you fully implement flush-into objects.