I’ve been a P2S owner for around 5 months now and this is my first 3D printer. I have never used anything other than Bambu Studio.
Since owning this printer, I’ve seen four Studio software updates come through and have not installed any of them in fear of what I read upon each release. So far, I’ve seen nothing that makes me confident any update will ever be implemented without issues (when I say issues, I mean potentially consequential ones; not annoyances).
All of the updates seem to include features that I would like to have but I don’t want to fix something that isn’t broken. Will I ever be able to update?
For example, 2.7.0 had issues. 2.7.1 claimed to resolve those issues, it did not…now here we are with 2.7.1.57 and there are new issues in addition to no documentation that confirms said previous issues were fixed. How do I know when issues are actually resolved? Am I just being a wimp? Should I just update?
For some reason I am having a hard time understanding and keeping track of Bambu versioning and I’ve never had a hard time tracking changes for any other software in my life.
… not to mention the 2x P2S firmware updates and the 1x AMS2 firmware update I’ve seen since my purchase. I’ve skipped those too.
Also, if you go to github releases to find your installer, there are portable windows installs [ the zip file ] , so you can just have a bunch of different versions on tap at the same time to test with. Settings cloud sync might want to be toggled on or off depending on your use case.
Warning: those are not truly “portable.” They all use the same user configuration location and there’s no way to change that. Every time you start a different version it will want to copy over all the presets that version ships with. Also each one will require a different version of the network plugin, which is impossible since the plugin binaries live in the user config location.
Currently the only way to run parallel versions on the same computer is to use one Beta version and one final release (they use different config locations). A third way is to build the software oneself in “internal” mode (yet another different config location). Or run other versions in a virtual machine.
I feel your pain. I have a P1S running 2.5.0.66 I have tried two of the updates and like you said things are broken. I keep reverting back to 2.5.0.66 because of this. I have reported the issues but they go unchanged.
What bothers me is they break things that worked before and were not part of the update target. I do not have an AMS so my situation is very basic. I should not be losing functions with updates.
I have the luxury of being able to test things in seperate VM’s, most don’t but I have also tested (in Windows) creating another user account, logging into that account and then doing the install in a non default directory (and even a different drive or USB drive if available). This keeps the user profile settings seperate (but you can still copy over custom settings for testing if you want) and the non-default directory use keeps the existing one from being updated/over written.
Edit: I am running LAN Only mode, never used Handy or logged my printer into BambuLabs and have never had an issue pointing/connecting multiple instances of BS or Orca to the printer (P1S) so I really don’t know if all of this will work the same for people who do the “normal” BL garden of printing delight.
logging into that account and then doing the install
It may be even simpler to set up/use…
One thing to note is that Studio doesn’t really need to be “installed” anywhere per-se, just uncompressed. For Windows that’s basically all the installer does, plus create shortcuts (and the uninstaller). The ZIP format distribution can be unzipped into any folder and used from there by running bambu-studio.exe. On Mac and official Linux builds, the distributed archive is just executed directly anyway.
Anyway, once there is an executable to run, it can be run via any user of choice. Even on Windows!
In Windows Explorer view, one can SHIFT + right-click on an executable and get a “Run as different user” option. It should prompt for user/pass.
There is also the runas utility which could be used from a shortcut or command line, eg:
The optional /savecred switch will save login credentials for next use. First use of that shortcut may require to be “Run as admininistrator” (to allow saving credentials). More info on runas with some googling.
Generally you can get around something like that by using symbolic links. Though not being a Windows user I don’t know what Windows calls them. Essentialy it’s like a “shortcut” or “alias” to a file or folder so that the actual folder isn’t the one the application thinks it’s using. You might need to ask a Windows technician.
Not really in this case, that I can think of, or at least w/out some custom launcher scripts (Windows/NTFS does have the equivalent of symlinks, not to be confused with “shortcuts”). The issue is that the Studio config paths are hard-coded into the binary, based on current user. So version A will look for configs in the same place as version B, if both are run as the same user. Of course one could make a script to switch out the configs (or modify symlinks) before running a specific version, as long as multiple versions don’t need to run at the same time, so that’s definitely an option!
For what it’s worth, I don’t think I’ve ever been bitten by the Horrible Terrible Very Bad updates unless I have explicitly installed a beta, in which case I expect trouble.
As logic goes that is horribly flawed of me, but the real point is that most users don’t experience most bugs, and probably you won’t be affected.
In addition, you have a fairly new printer and the associated software is under active development and tuning. Bambu has a history of making significant improvements to print profiles, slicer and firmware in the months following a new product release.
Just install the update. If it gives you trouble, fetch the last known good version from the releases page. It is also possible to downgrade firmware. Unlike Apple products, version updates are not a one-way ratchet.
I have the same worries. I joined the beta experience to help improve Bambu Studio, but the last update hasn’t been able to install the network plug-in (it downloads it, but it doesn’t login). So I had to reinstall the previous version, which I luckily kept in my drive.
Thank you for being straight up. I really appreciate the vote of confidence, and I think I am going to just do the update(s) and roll back if needed. I’m glad to know that there’s not really a high probability of bricking or anything like that.
It’s nice to hear it from other people with experience so I appreciate your feedback. I’m also getting the sense its one of these deals where ‘the only info that you read is the negative info’. If something works no one is going to post that it worked . So, hearing it from you all makes sense that the vast majority of people do not have issues to begin with.
From what I am gathering from all the comments so far it seems like I will probably
Look up some basic info or potential issues with an update just to know what to pay attention to
Download the current version before updating (so I can roll back)
Installing the update
Monitor and roll back if needed
Join the user experience program and report issues to support the community
I’m glad some of you mentioned the github, the portablity (or lack therof), and some of the ideas about running different versions on alternate VM’s or accounts. I’m going to look into VM that if I encounter any issues and use caution especially if dealing with carrying over configs.
Another data grab attempt, IMHO, sorry (I have nothing against sharing with other users in general). To a Chinese company that must answer to their gov’t. What data is actually sent or collected or how/where it’s stored or who has access… no real details besides an assurance that it complies with their privacy policy. The closed-source proprietary network plugin, responsible for sending this data from Studio, runs with the same privileges as Studio itself.
Not saying the intentions are necessarily evil, but I think this is something to be aware of for anyone who (still) cares.
When the app asks for whatever name it has hard coded into it, the operating systme, or file system, can look up whether that’s been symlinked, and if so, return a different path.
