I’ve been printing these 0.2mm plates full of prints for over a year, they are 40+ hour prints with 5 colors of Bambu PLA on 2 AMS with a print that has been tuned extensively for everything on the X1C (I can’t get these to print even close to X1C quality on the H2D disappointingly) so I have to continue to use my garden of 5 X1Cs for this print job. Today all 5 of my X1Cs failed in the same way, and I can’t determine if it’s Bambu Studio or the latest firmware. I originally thought there was some kind of AirPrint/extruder jam situation happening and layers were somehow being missed, but no - it’s some kind of combination of flushing volumes and code being sent wrong somehow. Ive sent 6 different jobs from Bambu Studio trying to fix it, so it’s not just a bad gcode, but a repeating problem:
While watching it print, I noticed the most bizarre never-before-seen behavior on my X1Cs, after loading a new filament color, 0.2mm poops take a long time, several minutes usually, but these poops were quick, and they would end up wiping on the prime tower the ‘old’ color, and then start printing the ‘old’ color on the print, but the print towers would have missing areas on them, causing some printed filament in both the prime tower and print to just sit on top and never adhere properly. this super strange behavior causes all the fails below, I’m almost in tears here, not sure wether to downgrade firmware or bambu studio, or both. The ‘working’ prints unfortunately are no longer in my Print History because I’ve printed so many jobs that they are pushed into oblivion.
Isolate the source of your trouble by changing only one variable at a time. It is easy enough to return to older versions of Studio and firmware. I would probably try an older Studio first, then roll back firmware on one machine if the problem persists.
Old versions of Studio are available at Github:
Scroll down to the last version that worked for your model, then expand the associated “Assets” to download the correct version for your computer.
For a PC, get the portable .zip version, extract all the files to a single folder, then run the bambu-studio.exe in that folder. This lets you have multiple versions of Studio available for testing on a single computer. (I do not know how or if Mac/Linux can have multiple versions.) I only install the .exe version after I know it is working for me.
If using an older slicer does not fix the problem, roll back the firmware on just one machine and try again. You can use Handy to roll back the firmware, or download an older firmware and install it via a µSDcard.
I also recommend running “Restore factory settings” from the printer menu after every firmware change. This seems to clear out memory and prevent weird problems, though it does wipe out filament calibrations stored on the printer. (I don’t do that - I use Orcaslicer and put the calibrations in the filament profile where it is safe.)
OrcaSlicer has a checkbox to enable or disable this feature. I’m on a very old BambuStudio Version, so I can’t check it there. In Orca, you can find it in the filament profiles → tab “settings override” → long retraction when cut (far down). Maybe there is the same option in latest Bambu Studio?
No issues with normal prints on latest firmware, but my camera is acting strange since the update. Super laggy like im getting 1 or 2 smooth frames then a couple seconds pause before the next frame dump.
Both in studio and on handy app
Are you sure the slicer isn’t telling you about this?
Slice model, Preview panel, sort by: Filament
How many filament change times does it say?
How much is in the Flushed column, in grams? Does this seem like the current behavior’s flush amount, or the previous good prints flush amounts?
Prepare panel → filament → flushing volumes
Are these set to 0, or oddly low? If you reset this, then re-slice, does your “flushed” amount change?
Prepare panel → General Process → Multimaterial → Are Flush into objects support/infill checked when you did not expect them to be checked? (your pics look like its flushing into a support in the middle … or it could be an infill area… but without the 3mf i have no idea what your prints supposed to be)
If you have an issue that the new firmware/software release notes specifically says is being addressed, update. Otherwise, stick with what works. Change for the sake of change is never a good idea.
Downgrade to what you were using before. If the problem goes away, problem solved…
I’m still running the slicer and FW from just before all the BBL security changes. Haven’t had a reason to update. Don’t think there’s ever going to be a need. Printer is rock solid as is.
So, what I notice on these updates, where the printer basically breaks, or files stop printing as expected… that costs me money and business downtime to figure out a fix. What I notice is that there is a string of “contributors” to the update. I don’t know who these “contributors” are, but I highly suspect that they are not software engineers with Bambu Labs. They are more than likely community people who are just trying to help.
When you have a closed ecosystem, updates should be done by employees of Bambu Labs only. These updates that break things, because some hobbyist wants to print a faster benchmark for YouTube, cost real businesses money and downtime to fix their fu@@ups, as these “contributors” have no business making fixes in any software project. If this is the case. Bambu, please stop letting people make updates and use proven SE methods to make updates before rolling them out.
That’s fine, but your position ignores reality: the bulk of bambulabs software stack originates from open source “contributors” (that you seem to disdain) and only a very small fraction of it is actually what bambulabs produces. Incredibly small. All they’ve done is brand it, altered some layouts, ripped out the networking functionality to replace it with [redacted], slapped a proprietary coloring scheme in the metadata, and refined the workflows for what is (was?) their competetive advantage: multimaterial.
Granted, this is a chinese shenzhen based company and doesn’t have to do anything more than lipservice to IP and licensing laws, but i digress…
Adding to what Bullock has written, it is not like somebody wants a faster benchy, throws some half baked code into BambuStudio and then it is part of the next release.
Instead, the contributor has to ask for the change to be added. Then the maintainer of BambuStudio will review the proposed code, there will be tests, there are beta releases that many people will test and only if all that passes, you will see it as a new feature in the next official release.
And it is not even clear yet, if the problem is a bug in the new release or if the update triggered a problem that was completely unrelated to the changes.
What you wrote is really an insult to all the people that created 98% of what BambuStudio is. Maybe that was for no better knowledge, but then you should be really careful with your claims based on assumptions.
Best practice is that when you make a product that uses firmware or software, and you make changes to that SW/FW, you put the new implementation through something called a “regression test” to make sure you haven’t broken anything, prior to releasing.
Regression tests are suites of tests (they can be programs that are run, or environmental conditions that change like voltage and temperature) designed to exercise and verify the correct functionality of the product. If a test fails that had previously passed, it’s called a “regression” and the change has to be debugged and verified as corrected before the product release can move forward.
When you do a release and it turns out you missed something, you do analysis on that to figure out how to test for whatever the issue is, and you roll that in to your regression test suite so next time, that same issue doesn’t escape.
If your regression test capability is limited, you can make use of Beta Testers and have them test the changes prior to release. But that’s a more empirical approach that can be less effective than targeted testing.
Bambu must have this kind of process but it seems like it needs a tune up. Too many reports of issues with new FW or slicer releases. The testing they’re doing as part of their release process isn’t robust enough to catch the bugs it should be catching. Not enough machines in their test population, maybe. Not enough focus on “closed loop corrective action/feedforward improvement” maybe. But whatever the reason, they’re not doing it as well as it seems like they could.
Which is why you shouldn’t upgrade unless you have a specific reason to. And even then, it pays to wait and see how others do before taking the plunge.
I in a very minor way am one of those “contributors”… and am not affiliated with Bambu, and you will find the vast majority of the contributions are not made by Bambu.
No, black box development is not the solution by any stretch of the imagination. What is needed is proper in house beta and regression testing before release. Clearly this is not being done sufficiently.
You didn’t answer yet if you performed a factory reset after the update. BambuLab claims that this is necessary, otherwise one might experience strange behaviour. Your problem fits that very well. So maybe it would be worth a try.
@RippeyFamily, did you do the reset? Of course BambuLab support should be the one to help you especially with the X1E. But maybe it solves your problem?
Hmm, IDK why it didn’t notify me of the reply; I better double check the notification settings. No reset, I didn’t initiate any updates, so i wouldn’t not have read that in the change log. Doubt I will reset it and attempt retest for a long bit. Did get a cool new to me error.
I can tell you support is joke, even for enterprise class machines. Its the same lack off response, days delay, no real self support for actual technical issues. The same as their consumer grade printers. I personally will never by another printer from bambu unless its less then $500 and it fits the requirements. May explore the alternative OS I have seen for the x1c, at least I can diagnose with that. On a snarky snippet; if I break it, there is no difference when you can’t use it reliable or fix anything outside of basic maintenance, especially when you pay thousands for a higher tier.
I am still on the last firmware before bambu decided to do all the lock down of the printers and slicers etc… I have been keeping up to date on the studio updates and I still have zero issues with my x1c.
If your claims were accurate, the firmware would be flawless—but we both know it still experiences odd issues from time to time.
Community-driven software is not inherently less reliable than proprietary alternatives. In many cases, patches and improvements are released faster by the community than by the original developers.
Personally, I switched from the official firmware to a community version on my CNC machine after the company repeatedly failed to address critical issues. The community version is now over 240 commits ahead—and far more stable.
So unless you have concrete evidence, don’t point fingers at the community. Accusations without proof only undermine serious discussion.
The forum’s notifications are lagged it seems, every single reply here came all at the same time to my email this morning - I’m reading through these responses.
