To Bambu Lab:
I was planning to write a one year review of my experience with my Bambu Lab P1P. In it I was going to list positives and negatives. I had already written multiple pages before I decided to write this open letter with suggestions to support ALL users instead.
I will provide a much shortened list without detailed explanation here.
Pros:
- Fantastic hardware
- usable software
- perfect for the user that just wants to download models and print them
- good out of the box experience
Cons:
- too much is proprietary and Bambu Lab tries to hide as much as possible even when they do not need to and even if it hurts the users
- their focus is on creating a walled garden. For example instead of building a great system with local networking first and then adding cloud support, they built the system around the cloud and only when the uproar of the user base got too loud did they add LAN support, but in an incomplete and awkward way
- many features are incomplete and bugs do not always get fixed. Instead all the resources are put toward developing more ways of locking users into their ecosystem. (Did we really need another public model repository in addition to the dozen or so that already exist?)
Bambu Lab please consider focusing on your core competency and strength, which is the hardware, and open up the rest of the system to allow advanced users to
- help improve the system
- invent new ways of doing things
- use the printers in ways that do not fit well in your ecosystem vision
- create custom solutions
Next, stop trying to hide everything possible. This hurts the users. This makes everything more difficult. This causes you to receive more support requests than necessary.
Now I am going to make specific requests, some of which I have already submitted here and on GitHub.
Provide Complete LAN support
LAN mode should not be an afterthought that barely works. It should be the most usable and easiest way to use the printer. (Cloud is not always functioning. Printers are used in internet restricted environments, or with sensitive data.)
Specific functionality that is missing.
- ability to connect to wireless network without using phone app. It should be possible to either put a file with wireless network info on the SD card to be used automatically, or for the X1 printers it could be entered at the console.
- allow the printer firmware to be updated from Bambu Studio without the printer having internet access.
- provide a “use local network” preference in Bambu Studio so it does not try to use the internet in LAN mode. Before the network log was encrypted, I could see that even when my printer was in LAN only mode, Bambu Studio made dozens of cloud requests before a print was sent to the printer.
- provide a preference in bambu studio to allow the user to choose if it checks for available updates for it or for the firmware of known printers
- maintain printer information when the user switches between LAN and cloud mode. It is terrible now that in order to update firmware I must turn off LAN mode, then use Handy to re-add the printer to the cloud, update the firmware and then change back to LAN mode.
- Always use the LAN when available to communicate with the printer. If the user sends a print to the printer then send it directly via LAN. In addition, if they are using the cloud the send a copy of the file to the cloud for storage. This eliminates problems when the cloud is not functioning.
- add the source code for the network dll to the Bambu Studio repo. Hiding this gives the user community the feeling that there might be network traffic that they would not approve of.
Store all log files in plain text.
The primary reason for storing all log files in text format, both for Bambu Studio, and for the printer itself, is to allow the users to easily access the log information which allows them to troubleshoot and solve problems that occur. This lets users quickly get things working again. This is a better user experience. This minimizes support calls.
The secondary reason for providing plain text log files is security. Many of us in the user community would never send a log file to a company or add it to a bug report on GitHub without being able to scan it for any sensitive information. For users, not knowing what they are giving away is a bad idea.
Fully document all G-code
We know that the G-code is based on Marlin, but there are many common codes that are not implemented and many custom codes added. There are also codes that are implemented in a non-standard way. All of this makes it hard for any users that want to write custom g-code. There is no reason to hide this from the users.
I use my own start and end g-code. Of course, this is not always easy because the default gcode provided in Bambu Studio uses codes that are not documented.
There are other uses for hand coded g-code. Sometimes advanced users want to do things that cannot be done in the slicer. There are also many users who test printers and filament by generating custom gcode with a program other than the slicer.
Fully document all error codes
Users must be able to quickly identify the cause of errors so that they can correct the issue and continue as quickly as possible.
- Currently error codes are not easy to look up. There should be a simple numerical listing of all error codes. Error codes should be pulled directly from source code so that none are missed.
- all error codes should be documented with cause and potential solutions
- the correct error code should be raised when an issue is detected by the printer. (This is not always true currently.)
When I originally asked for this I was told by a BBL employee that Bambu Lab did not want to provide all error codes because… (I do not recollect all the details, but there is no valid reason to hide error codes.)
Allow users to contribute to the wiki
I find the wiki hard to use because:
- organization is not good, although is is slowly getting better
- the search function is not good and search disappears when a page is chosen.
- most of the links do no allow opening in a new tab.
There is a note about users being allowed to contribute to the wiki to help add more information and to correct small errors. However I requested access almost a year ago and have not heard back. This is another case of not letting the user community participate to make the Bambu Lab ecosystem better.
Complete the implementation of real Projects
One of the big features added to Prusa Slicer when creating Bambu Studio was the notion of a project with multiple plates. That is a great idea. It would allow bundling everything in one place. Sadly, it was never completed and projects are not providing the ability to use a project for many of the most useful functionality.
- although the ability to set presets (printer, filament, process) for the entire project is useful for simple projects with one plate, to be able to actually use a project to manage dozens of objects, which might use different filaments and other settings to print correctly, the ability to set presets per plate is an absolute requirement. (Currently the user will end up using multiple project files.)
- Plate naming and plate management must be simple and easy.
- Plates should be in a sidebar in prepare mode like they are in preview. Currently in prepare mode more than about six plates is unmanageable because they are all shown. Selecting more than one to be visible is required also so allow moving objects among plates. Dragging an object from a plate to the icon in the sidebar would also be useful.
- an unnamed plate should be automatically given the name of the first object added to it. In many, if not most, situations this will be a usable name and not require the user to go through the steps to name the plate explicitly
- Plate names should be shown in printer status. That should be the primary display and the project name secondary. It is the plate name that is specific.
- G-code should be saved in the project after a plate is sliced. There is no reason to require reslicing when the user opens a project on another day to reprint an object/plate. In fact, saving g-code can prevent the user from reslicing a model that printed perfectly and have it print poorly because some setting has changed. Currently this is an issue because presets are not saved per plate. (Presets are only settable per project.)
Fully document the IOT/MQTT implementation
While I am not sure that a 3D printer should be part of the IOT or use MQTT for communication, I can see how monitoring and MQTT are highly compatible.
Given that the printers do support MQTT, it should be documented to allow users to integrate printer monitoring and control into other systems. Preventing this does not benefit Bambu Lab, but in contrast just shows that it does not want users to be able to do more than what BBL allows. (To reiterate, users are buying your printers because of the hardware. Opening up the ecosystem and allowing users to do more with the printers with sell more printers.)
Encourage contributions to the software
Bambu Studio is on GitHub, but I do not believe that it is very open to contribution. Many of the issues that were reported more than a year ago are not fixed. Features have not been implemented. In fact, Orca Slicer was created to be able to quickly add new features that were not accepted into Bambu Studio.Open Source software gets better quickly when the entire user base is allowed to contribute.
BBL does not even point users to GitHub to report issues. Rather they let users just post them on the forum where they may never get addressed. There certainly is no status for issues reported on the forum.
Other
I am sure that I did not cover everything, but this should be a good start.
I hope that other users in the community will also put pressure on Bambu Lab to support our creativity and help us help them.
Respectfully,
Julie Jones