Sorry to see that and it does look very similar.
Really impressed with your ideas and quality of your presentation too.
Hopefully BL will take some of your ideas on board.
3 Likes
I put your code in under filament management and set flush volume to 425, and it only did one wipe. Thanks for trying
You need to put the gcode in “Change filament G-code” as instructed.
The new gcode is very well commented so you know what each line is doing.
4 Likes
That’s exactly where I put it, and it only does one wipe for high flush volumes
At this point, I give up on pla interface for petg. I’ll just do solo filament prints with x1c, and get a Prusa xl for support interface.
while it’s not doing the multiple wipes on mine, it is significantly faster printing.
i do have a prime tower and a waste object that i have flush into object selected. if that is calculated into the total flush volume, maybe that’s why it’s only wiping once?
You are onto something. From my understanding that is exactly what happens. - And I don’t like some of the implications…
Have you checked on what size the related poop is?
Maybe I should put this into the explanation of my upload.
Well, I just received the answer from Makerworld regarding the skim off.
Rejected
And to top it off it just doubled its downloads over night. Looks like I did advertising here…
This is the second time a claim of mine is rejected (first one is someone including my models in a print profile of a remix).
I am fed up.
Almost - but Prime length doesn’t come out of flush - its a separate amount - so if for example you increase prime length you can in theory reduce all flush lengths by that amount.
So for a non flush-to print the order goes
- Offbed Flush - flush_length. - which gets included in flush_total
- Prime Tower - prime_length - which gets included in model_total
- Object -
For a prime-to print
- Offbed Flush - flush_length minus flush-to_object_layer_length - with lower amount included in flush_total
- Prime Tower - prime_length - (added to Model_total)
- Flush-to object - flush-to_object_layer_length (added to Model_total)
- Object
Example screen prints - with left hand GCODE with flush-to object present - so length of off bed flush reduced. If you add up all of the E figures on the right hand GCODE then divide by 0.4 - you get about 167.
I used 99% inflll in this example in the flush-to object (the right hand one).
NB/ This is with normal GCODE not yours, plus the flush length in this example is only 167 -
2 Likes
welp, my print failed again with stringing. im going to disable prime tower and i deleted the object. going to try one last time lol.
Nice, you seem to know one or two things about how the slicer runs. - I made my code private for now, there seems to be something I missed entirely.
It seems I really do need some tutoring here … Please correct me where I am wrong/missing something or paste me a link to further info where I could read up on it.
Starting points:
- flush_volume = volume set by user as volume to get rid of before continuing with main print part
- prime_volume = volume set by user, determines mm³ flushed into prime tower at each change
Used internally:
- flush_length_1 to flush_length_16 = pooped volume → calculation details, only 4 are used in the stock filament change G-code?
- prime_length (no access) = the volume that goes into the prime tower
- flush_to_object_layer_length (no access) = volume that goes into the upcoming layer of a selected secondary object
Variables used to estimate filament usage:
- flush_total (no access) = ∑ volume poop + ∑ volume prime tower
- model_total (no access) = volume primary print objects + flushed volume into secondary objects
Equation for a single event:
flush_volume =! flush_length + prime_length + flush_to_object_layer_length
What that boils down to is: My code needs a serious overhaul 
Btw, I had a failure again, but this time I think it was my filament. Popped it in the dryer this am and will try again.
When I disabled the prime tower and object to flush into, it did in fact wipe twice, which is exactly what I wanted. That being said, I may add the prime tower back, but am worried about adhesion with the petg and the pla. Also, I ordered some high temp pla because I think the temp difference in the nozzle is also an issue .
I don’t know about overhaul and whatnot because you know way more than I do lol.
Your filament change stl though, have you tried it with different materials to calculate purge? Ie petg and pla?
The other variables I mentioned as just totals I wanted to convey - not actual slicer variables as far as I know.
Re your ‘Variables used to estimate filament usage’ section.
I don’t think the flush total that you are presented with in the slicer includes the total volume of the prime tower - that seems to come in the model total for some strange reason.
Fairly easy to confirm this by just changing the prime length and reslicing - you will see the model total change but not the flush total.
In terms of your test objects I guess it just depends on whether they include a prime tower in the 3mf and calculations.
Not really sure why the prime length is split into 4 fields - I know in Prusaslicer you have view flushing volumes either as totals or separate unload/load values - so I wonder if the 4 fields somehow reflect this - might try testing it out one day.
2 Likes
How about trying an ABS top layer to your supports. I have found that it separates well, but sticks enough to give a very good surface using zero clearance between the support and part.
The other advantages are that the temperatures can be the same, and contamination between ABS and PETG is far less critical than PLA contamination.
One other thought on your Gcode - I came across a thread where people were reporting the same issue ford12acing has been having with filament spirals being to long for the off bed purge area with the 0.2mm nozzle.
I guess in this case as the filament is that much thinner then the 200mm length for switching to a second spiral might still be a bit long - so taking the nozzle size in to account too in the calculations might be worth thinking about.
1 Like
The calibration prints are separate for PLA with 0.95 and PETG/ABS/ASA with 0.98 extrusion factors. When both are used, deviation is a bit more present but from my point of view negligible.
I don’t know if it would work, but with what you describe, I would only use flushing (no prime tower) but place a fitting geometry close to & around my object instead. – A good old solid wipe shield that also minimizes stringy distances.
That indeed seems like a good point to add. So far I thought the curling would solve that anyway.
My code does not need an overhaul by the way, I just got confused by the “variables” you mentioned… But I added an explanation to my description for others. - Currently I am updating the calibration part of the upload. Once finished, it goes back online (that small nozzle extra wiping comes a little later).
Reworked flushing volumes calibration files and modified G-code are back online. I included some explanation in regards to the flushing volumes.
@Ukdavewood
I would appreciate your opinion on the “1. Basics information” part.
1 Like
Great work and I agree with everything you have said in your write up and like your way of presenting the print/purge/prime/secondard-purge cycle.
I will try your GCODE out at some point and put feedback on your model, plus also try your inter colour purge length tests.
I notice that the Beta Bambu Studio has auto-recalculate - so I guess that could end up being an issue.
I agree that secondary purging does risk some issues with the little remaining wisps getting dragged back onto the bed - but I have done quite a few prints without them causing an issue - I guess making them slightly longer or completely removing them might be worth considering.
Although I worry slightly about whether removing the wisps might make the prime tower less consistent and therefore more error prone (like the purge/towers are on the Prusa MMU2).
2 Likes
Can anyone hint me to where to find the GCode? I’m to dumb to find it…
