You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Trying out the newest firmware with BG enabled, and your version of the filament cleaner with 2 brushes.
So far stringing isn't contaminating the print bed.
However, I did run into two issues:
The print put down print head 4 (connected to AMS), which then performed a BG switch.
The print proceeded to print out with the other print heads as expected, and the BG switch was in progress.
But I guess that activity with the other heads was too short for the BG to finish. It grabbed print head 4, and just as it was extruding the newly switched filament, it pulled out the print head and created a blob on the plate. Paused the print and removed the blob manually. It didn't do this every time, but did occasionally catch it while it was extruding.
The second, though this may be a me problem as I use a shortened bin, is that the BG purge still has long strands, and those strands after many switches end up creating a sort of bed that filament piles up on since it doesn't seem to topple over unless I jump in every now and then and try to tip it over. Again, this may be a me problem since I am not using the full size bin so maybe it just won't have room to allow those strands to not pile up near the nozzle.
But so far, it's working very well, with switches occuring reliably. I just have these 2 issues.
Edit: now that I think of it, issue 1 may make issue 2 more likely. As it's extruding and it grabs the print head, a bit of material gets onto the back brush, creating a nearby anchor so that it can pile up filament near the nozzle. But I wouldn't be concerned with the second issue as I'm not using it the way it's intended, but, fixing issue 1 so it doesn't grab the head mid extrusion may make issue 2 be less of a problem for me.
On issue 2: right now a full size bin is basically mandatory for background load and unload printing, and for exactly the reason you hit. The background prime purges through the open dock with no cutoff and no wipe, so it comes out as long strands that take up a lot more room than a normal purge. With a shortened bin they will pile up. That is expected at the moment, not something you did wrong.
On issue 1: I will look into it. I cannot really prevent the pickup itself, the print takes the head when it needs it, but I may be able to add a cleaning move so it does not leave material behind when that happens.
What would most likely help with both of your issues today: in your ace.cfg, in the [ace_bg_swap] section you already have, add:
load_enabled: False
So the section looks like this:
[ace_bg_swap]
heads: 3
load_enabled: False
That way only the unloads run in the background, which causes less purge and no longer starts extruding before a pickup.
I was going to switch to that setting full-time, but did want to try out your new wiper model and see how it went, but yeah, that may be my only option since removing the panda breath is such a hassle to fit in the full bin.
Got it, so it will still drop a small bit of filament as it’s unloading in the BG, so the opening is still needed to let it fall through, but the priming of the new filament will happen when the toolhead is attached. That should work fine since it’s just a small wisp.
Regarding the toolhead being picked before ready, why can't the preprocessor inject a macro before the toolhead change that waits for a background operation to conclude if one is still in progress, else it is a noop
We already do. _wait_bg_op sits at the entry of ACE_SWAP_HEAD/LOAD/UNLOAD and blocks while the bg engine is busy on that head. It matters most during the bulk retract: a V2 rollback has a fixed length and must not be cancelled, so the arrival waits it out.
It sits after the T, not before, for two reasons:
Position. Before the T the head is still on the part, so stalling there for 30 to 60 s means an ooze blob and a heat mark. After the pick it's parked and waiting is free. A pre-T wait would need its own park-and-return choreography, which costs time itself.
The math usually doesn't favour waiting. Measured on a long real print: an arrival on a fully bg-loaded head costs 5 to 10 s, on staged filament about 60 s, a full inline swap about 146 s. When the pick lands mid grip/prime, the bg op typically has ~40 s left, so waiting saves ~60 s of inline load but spends ~40 s of stall. Net gain is around 20 s, and it converts hidden work into visible downtime, which is exactly what background swapping is meant to avoid.
Aborting is cheap because it's staged: abort before the tip reaches the sensor and the filament stays staged (the arrival finishes it inline); abort after grip/prime and the head is already loaded (the arrival is a no-op). No work is ever lost, only shifted forward.
Where the idea does have merit is a conditional wait, waiting only when the bg op's remaining time is shorter than the inline load it would save. That needs a reliable per-phase time estimate the engine doesn't have yet. It's on the list, but it isn't a one-liner.
30. Ok I have included the log files for that day 10/16/2026. I believe that log1 ~17:00 is around the time it happened. klippylog2.log klippylog1.log
@decay71 I should have been clearer; these logs were for the "air printing" where my second ACE Pro v2 had a tangled spool and was air printing. When I came to the printer, there was no error; it was just paused.
I did have the air print detection set.
You can see below that the purple was air printing for several layers due to the tangled filament in the ace pro
Thanks, the logs show two separate things. The freeze at 18:59 UTC was not a pause: a background swap on head 1 switched that head's heater off right when the print was most likely waiting for it to reach temperature, so the print waited forever without an error. i am looking into it. For the air printing on head 4, Air Print Detection logged one chewing window at 18:46 UTC but pauses only after two in a row. Could you attach multiace_wiggle.log from Oct 16, and the processed gcode file of that print?
Thanks, the gcode confirms it. Before every tool change the slicer waits for the next head to reach temperature (M109), and in your print that next head was the one the background swap was working on. When the cold pull finished it switched that head's heater off, so the wait could never complete and the print froze without an error. It's a timing race, which is why the same file printed fine later. I will fix it her, i f that happens again, please grab multiace_wiggle.log right away.
Happened at 17:22 in the log file. I just flipped the ACE off, turned it back on, and resumed it, but this was the first time it's happened to me, so I thought I would share it.
ACE 1 dropped off USB at 17:22 (log time, UTC), reconnected by itself about a minute later, and the color change finished normally. The pause right after came from a check that missed the reconnect, so the power cycle wasn't needed, and i'll fix that.
Axolotl 6 colors Background Swap Test for posterity:
Print Time Estimates from slicer
-- NextSlicer | Single Nozzle Mutlicolor Anycubic Kobra K3 - 14h14m
-- SnOrca | Snapmaker U1 (if it had 6 nozzles) - 3h57m (Assume this is how long a Prusa XL/Core One w/INDX would take?)
Print Times Measured
-- Snapmaker U1 ToolHead 0 ACE PRO v2 3 colors, other heads single color, new version of bg swaps #186 - 7h33m (see #172 (comment))
-- Snapmaker U1 without background swaps - 9h7m
-- Want to know if better with TWO ACE PRO v2 vs just ONE??
31. Axolotl 6 colors Background Swap Test for posterity:
### Print Time Estimates from slicer
-- NextSlicer | Single Nozzle Mutlicolor Anycubic Kobra K3 - 14h14m
-- SnOrca | Snapmaker U1 (if it had 6 nozzles) - 3h57m (Assume this is how long a Prusa XL/Core One w/INDX would take?)
### Print Times Measured
-- Snapmaker U1 ToolHead 0 ACE PRO v2 3 colors, other heads single color, new version of bg swaps #186 - 7h33m (see #172 (comment))
-- Want to know how long it would take without background swaps??
-- Want to know if better with TWO ACE PRO v2 vs just ONE??
@decay71 did your "Multi" ACE print of the axolotl finish and what were the window settings and number of swaps?
Also should I print an axolotl without background swaps for a control or can we somehow calculate how long it would take from the log files?
Hi, no, the first print screwed up as i told you and i did not manage to make time for another so far, heavily testing creality cfs nano atm. I will print another as soon as possible.
Very cool. Ok no big deal I can also print with multiple aces if need be.
Don't want to interrupt your fun 😉
I think I am going to kick one off with no background swaps for a control
31. Axolotl 6 colors Background Swap Test for posterity:
### Print Time Estimates from slicer
-- NextSlicer | Single Nozzle Mutlicolor Anycubic Kobra K3 - 14h14m
-- SnOrca | Snapmaker U1 (if it had 6 nozzles) - 3h57m (Assume this is how long a Prusa XL/Core One w/INDX would take?)
### Print Times Measured
-- Snapmaker U1 ToolHead 0 ACE PRO v2 3 colors, other heads single color, new version of bg swaps #186 - 7h33m (see #172 (comment))
-- Snapmaker U1 without background swaps - 9h7m
-- Want to know if better with TWO ACE PRO v2 vs just ONE??
@decay71 I finished the axolotl w/o bg swaps which puts me at 244 consecutive tip-forming swaps without intervention/errors 🥳 I see why you thought there could be improvements to bg swaps time though:
8h54m w/bg swaps & No ACE BG WAIT function enabled being 2.4% faster (13m) then without
9h7m w/o bg swaps
7h33m w/bg swaps & extra Prime Tower Moves ACE BG WAIT function 17.2% faster (1h34m)
Tmrw morning I will kickoff the improved ACE BG WAIT which eliminated the extra Prime Tower moves (est ~3% faster) + 2 ACE Pro's pipelining w/o #197 (est ~8-10% faster).
31. Thanks for running the control, 244 swaps without an intervention is a great result.
I am kicking off a 2x ACE Pro with the most current on my branch. I am a little unclear on how MultiAce decides the optimal loadout. I did notice it changes when I change the filament print order. Here is what I am currently doing:
@decay71 Also, I am noticing that I am purging too much, which wastes time and filament (tip-forming is more efficient, I assume). For example in the purge waste below, once the head is picked up (after a bg swap starts) it does (1) and then follows with (2) which I would like to reduce (2) especially given that we use a prime tower.
Do bg swaps follow the per-pair matrix that comes from the slicer? I dropped it from 0.3x to 0.15x, but the purge waste looks the same. I did start the print with the per-pair setting off; I turned it on, hit Apply, saved, restarted the printer, and resumed the print.
On the loadout: the head-mode optimizer ignores what is currently loaded and tries every assignment of colours to heads (each ACE head swaps among the slots of its own ACE). It scores each one by the print time lost to swaps over the actual toolchange sequence: an inline swap counts 210 s, a swap whose unload can run in the background counts 30 s (head bg-enabled and parked long enough). Lowest total wins; ties go to fewer swaps, then fewer pinned colours, then simply the first one found. Changing the filament order changes the toolchange sequence and with it which swaps fit into a background window, and it changes the order in which equal candidates are found, so a different loadout can come out on top.
Background swaps do follow the slicer's per-pair matrix: the preflight stamps each pair onto the ACE_BG_SWAP line (PURGE=), and the bg prime is that length plus 40 mm against colour carry-over, so at least 80 mm. Two things explain why your change looked the same:
The stamps use the RAW matrix (x0.45, clamped to 40-150 mm). The flush multiplier only scales them up, never down, because it calibrates the tower, not the melt zone. Going from 0.3 to 0.15 has no effect on our purge.
The stamps are written when the file is processed. Toggling purge_matrix, restarting and resuming does not change an already processed file, and purge_matrix only affects inline swaps anyway.
After the pick, a bg-loaded head first gets whatever prime the pick cut short, then a short flow check (20 mm plus the anti-ooze retract) and the wipe. Which of these are your (1) and (2)? The screenshots don't tell me.
Activity
r3ferrei commentedon Jul 25, 2026
Trying out the newest firmware with BG enabled, and your version of the filament cleaner with 2 brushes.
So far stringing isn't contaminating the print bed.
However, I did run into two issues:
The print put down print head 4 (connected to AMS), which then performed a BG switch.
The print proceeded to print out with the other print heads as expected, and the BG switch was in progress.
But I guess that activity with the other heads was too short for the BG to finish. It grabbed print head 4, and just as it was extruding the newly switched filament, it pulled out the print head and created a blob on the plate. Paused the print and removed the blob manually. It didn't do this every time, but did occasionally catch it while it was extruding.
The second, though this may be a me problem as I use a shortened bin, is that the BG purge still has long strands, and those strands after many switches end up creating a sort of bed that filament piles up on since it doesn't seem to topple over unless I jump in every now and then and try to tip it over. Again, this may be a me problem since I am not using the full size bin so maybe it just won't have room to allow those strands to not pile up near the nozzle.
But so far, it's working very well, with switches occuring reliably. I just have these 2 issues.
Edit: now that I think of it, issue 1 may make issue 2 more likely. As it's extruding and it grabs the print head, a bit of material gets onto the back brush, creating a nearby anchor so that it can pile up filament near the nozzle. But I wouldn't be concerned with the second issue as I'm not using it the way it's intended, but, fixing issue 1 so it doesn't grab the head mid extrusion may make issue 2 be less of a problem for me.
[-]Tip forming result and strings[/-][+]Background print discusseon[/+][-]Background print discusseon[/-][+]Background print discussion[/+]decay71 commentedon Jul 26, 2026
Hi,
On issue 2: right now a full size bin is basically mandatory for background load and unload printing, and for exactly the reason you hit. The background prime purges through the open dock with no cutoff and no wipe, so it comes out as long strands that take up a lot more room than a normal purge. With a shortened bin they will pile up. That is expected at the moment, not something you did wrong.
On issue 1: I will look into it. I cannot really prevent the pickup itself, the print takes the head when it needs it, but I may be able to add a cleaning move so it does not leave material behind when that happens.
What would most likely help with both of your issues today: in your ace.cfg, in the [ace_bg_swap] section you already have, add:
load_enabled: False
So the section looks like this:
[ace_bg_swap]
heads: 3
load_enabled: False
That way only the unloads run in the background, which causes less purge and no longer starts extruding before a pickup.
r3ferrei commentedon Jul 26, 2026
Thanks!
I was going to switch to that setting full-time, but did want to try out your new wiper model and see how it went, but yeah, that may be my only option since removing the panda breath is such a hassle to fit in the full bin.
decay71 commentedon Jul 26, 2026
The new wiper ist still necessary with bg unload only.
[-]Background print discussion[/-][+]Background swap discussion[/+]r3ferrei commentedon Jul 26, 2026
Got it, so it will still drop a small bit of filament as it’s unloading in the BG, so the opening is still needed to let it fall through, but the priming of the new filament will happen when the toolhead is attached. That should work fine since it’s just a small wisp.
I’ll give it a shot. Thanks!
decay71 commentedon Jul 26, 2026
Yes.. an many bg swaps just unload anyways as the time windows is to short.. So still 2/3 of time saved, depending on the print of course..
johnlaur commentedon Jul 28, 2026
Regarding the toolhead being picked before ready, why can't the preprocessor inject a macro before the toolhead change that waits for a background operation to conclude if one is still in progress, else it is a noop
decay71 commentedon Jul 28, 2026
We already do. _wait_bg_op sits at the entry of ACE_SWAP_HEAD/LOAD/UNLOAD and blocks while the bg engine is busy on that head. It matters most during the bulk retract: a V2 rollback has a fixed length and must not be cancelled, so the arrival waits it out.
It sits after the T, not before, for two reasons:
Position. Before the T the head is still on the part, so stalling there for 30 to 60 s means an ooze blob and a heat mark. After the pick it's parked and waiting is free. A pre-T wait would need its own park-and-return choreography, which costs time itself.
The math usually doesn't favour waiting. Measured on a long real print: an arrival on a fully bg-loaded head costs 5 to 10 s, on staged filament about 60 s, a full inline swap about 146 s. When the pick lands mid grip/prime, the bg op typically has ~40 s left, so waiting saves ~60 s of inline load but spends ~40 s of stall. Net gain is around 20 s, and it converts hidden work into visible downtime, which is exactly what background swapping is meant to avoid.
Aborting is cheap because it's staged: abort before the tip reaches the sensor and the filament stays staged (the arrival finishes it inline); abort after grip/prime and the head is already loaded (the arrival is a no-op). No work is ever lost, only shifted forward.
Where the idea does have merit is a conditional wait, waiting only when the bg op's remaining time is shorter than the inline load it would save. That needs a reliable per-phase time estimate the engine doesn't have yet. It's on the list, but it isn't a one-liner.
DjFillament commentedon Aug 3, 2026
Havent had any issues with stringing on bed using a poop blocker shield. I've printed swaps now probably almost 1000 swaps now.
decay71 commentedon Aug 3, 2026
WTF (deletes Warnings).. 1000? What filament? And can you send me a link to the poop blocker shield?
decay71 commentedon Aug 4, 2026
Thank you, will test that!
35 remaining items
docx-tech commentedon Oct 21, 2026
@decay71 I should have been clearer; these logs were for the "air printing" where my second ACE Pro v2 had a tangled spool and was air printing. When I came to the printer, there was no error; it was just paused.
I did have the air print detection set.
You can see below that the purple was air printing for several layers due to the tangled filament in the ace pro
decay71 commentedon Oct 21, 2026
Thanks, the logs show two separate things. The freeze at 18:59 UTC was not a pause: a background swap on head 1 switched that head's heater off right when the print was most likely waiting for it to reach temperature, so the print waited forever without an error. i am looking into it. For the air printing on head 4, Air Print Detection logged one chewing window at 18:46 UTC but pauses only after two in a row. Could you attach multiace_wiggle.log from Oct 16, and the processed gcode file of that print?
docx-tech commentedon Oct 21, 2026
I provided the gcode which has printed successfully.
As for the multiace_wiggle.log I don't see one for that data the log1, log2 and log3 files are empty and only today's log has something in it.
multiace_wiggle.log
axolt multicolor_PLA_3h57m.zip
decay71 commentedon Oct 21, 2026
Thanks, the gcode confirms it. Before every tool change the slicer waits for the next head to reach temperature (M109), and in your print that next head was the one the background swap was working on. When the cold pull finished it switched that head's heater off, so the wait could never complete and the print froze without an error. It's a timing race, which is why the same file printed fine later. I will fix it her, i f that happens again, please grab multiace_wiggle.log right away.
docx-tech commentedon Oct 21, 2026
Printing right now and got an ACE Comm disconnect
Happened at 17:22 in the log file. I just flipped the ACE off, turned it back on, and resumed it, but this was the first time it's happened to me, so I thought I would share it.
klippy_10-21-2026.log
decay71 commentedon Oct 22, 2026
ACE 1 dropped off USB at 17:22 (log time, UTC), reconnected by itself about a minute later, and the color change finished normally. The pause right after came from a check that missed the reconnect, so the power cycle wasn't needed, and i'll fix that.
docx-tech commentedon Oct 26, 2026
Axolotl 6 colors Background Swap Test for posterity:
Print Time Estimates from slicer
-- NextSlicer | Single Nozzle Mutlicolor Anycubic Kobra K3 - 14h14m
-- SnOrca | Snapmaker U1 (if it had 6 nozzles) - 3h57m (Assume this is how long a Prusa XL/Core One w/INDX would take?)
Print Times Measured
-- Snapmaker U1 ToolHead 0 ACE PRO v2 3 colors, other heads single color, new version of bg swaps #186 - 7h33m (see #172 (comment))
-- Snapmaker U1 without background swaps - 9h7m
-- Want to know if better with TWO ACE PRO v2 vs just ONE??
Anycubic Sliced File
Snorca Sliced File
docx-tech commentedon Oct 27, 2026
@decay71 did your "Multi" ACE print of the axolotl finish and what were the window settings and number of swaps?
Also should I print an axolotl without background swaps for a control or can we somehow calculate how long it would take from the log files?
decay71 commentedon Oct 27, 2026
Hi, no, the first print screwed up as i told you and i did not manage to make time for another so far, heavily testing creality cfs nano atm. I will print another as soon as possible.
docx-tech commentedon Oct 27, 2026
docx-tech commentedon Oct 28, 2026
@decay71 I finished the axolotl w/o bg swaps which puts me at 244 consecutive tip-forming swaps without intervention/errors 🥳 I see why you thought there could be improvements to bg swaps time though:
ACE BG WAITfunction enabled being 2.4% faster (13m) then withoutACE BG WAITfunction 17.2% faster (1h34m)Tmrw morning I will kickoff the improved
ACE BG WAITwhich eliminated the extra Prime Tower moves (est ~3% faster) + 2 ACE Pro's pipelining w/o #197 (est ~8-10% faster).decay71 commentedon Oct 28, 2026
Thanks for running the control, 244 swaps without an intervention is a great result.
docx-tech commentedon Oct 28, 2026
I am kicking off a 2x ACE Pro with the most current on my branch. I am a little unclear on how MultiAce decides the optimal loadout. I did notice it changes when I change the filament print order. Here is what I am currently doing:
Preflight compile GCode
axolt multicolor_PLA_3h58m.zip
Print order:
MutliAce Loadout:
docx-tech commentedon Oct 28, 2026
@decay71 Also, I am noticing that I am purging too much, which wastes time and filament (tip-forming is more efficient, I assume). For example in the purge waste below, once the head is picked up (after a bg swap starts) it does (1) and then follows with (2) which I would like to reduce (2) especially given that we use a prime tower.
Do bg swaps follow the per-pair matrix that comes from the slicer? I dropped it from 0.3x to 0.15x, but the purge waste looks the same. I did start the print with the per-pair setting off; I turned it on, hit Apply, saved, restarted the printer, and resumed the print.
Purge waste
decay71 commentedon Oct 28, 2026
Hi,
On the loadout: the head-mode optimizer ignores what is currently loaded and tries every assignment of colours to heads (each ACE head swaps among the slots of its own ACE). It scores each one by the print time lost to swaps over the actual toolchange sequence: an inline swap counts 210 s, a swap whose unload can run in the background counts 30 s (head bg-enabled and parked long enough). Lowest total wins; ties go to fewer swaps, then fewer pinned colours, then simply the first one found. Changing the filament order changes the toolchange sequence and with it which swaps fit into a background window, and it changes the order in which equal candidates are found, so a different loadout can come out on top.
Background swaps do follow the slicer's per-pair matrix: the preflight stamps each pair onto the ACE_BG_SWAP line (PURGE=), and the bg prime is that length plus 40 mm against colour carry-over, so at least 80 mm. Two things explain why your change looked the same:
After the pick, a bg-loaded head first gets whatever prime the pick cut short, then a short flow check (20 mm plus the anti-ooze retract) and the wipe. Which of these are your (1) and (2)? The screenshots don't tell me.