This was originally going to start as “Enable print over LAN for P1P”.
But after thinking about it, the better feature request is to provide a simple API to send gcode files from BambuStudio or another slicer. Allow us to bypass the cloud service to send files, get some print status back via API. This allows us to air gap the Bambu printer, and then tie it into our existing print solutions and monitoring. Sending gcode should be fast over LAN and bypasses the step required to unzip the 3MF file on download.
Yes, it would be great to be able to access the printer through an open API. All our printers communicate with our MES/ERP system. We need such an API with Bambu printers before adding more.
All fine and dandy, but the printer still needs to be on the network to get firmware updates. That isn’t changing any time soon from what I understand.
“printer still needs to be on the network to get firmware updates” → Not necessarily. Download the firmware to SD card, and add a new option to flash firmware from the SD card. We implemented flashing of firmware at my own company. We could update any number of devices over the network, or in some cases where the device was not on the network, we could update from USB drive.
The bigger ask here would be the open APIs to send and monitor prints.
We only offer our firmware with OTA updates (network) Not on SD card, Not for download. So yes network is required for it. Would I love it if we would offer SD Card updates? Sure. But it has been decided we will not be doing that.
As for an API I don’t see that happening any time soon.
This is really a pity, because I think it will be absolutely a trivial case that people will want to include the printer in e.g. HomeAssistant - With cam stream + print status + possibly emergency stop, that would be quite enough. And I would think that this is actually nothing that would be somehow “dangerous” for Bambu Lab - These are simply GET requests, except for the emergency stop thing, well, that would be a POST… but even if… where are the doubts on the side of Bambu Lab?
I understand that they want a more or less closed system here. Nevertheless, both private people and companies have a certain preference on how they want to monitor their printers.
And sorry, but both the app and the options in Bambuslicer are still more than beta.
To even get a stream into the app, I had to delete it again.
In the Bambuslicer you also get more error messages so what else - well, the cam does work eventually… but the emphasis here is on eventually.
So sorry, but at this point a proprietary approach is probably here and there rather an argument against the purchase of a Bambu Lab?
Or would we probably just find through the API that every call would have to go through the cloud, and people would be even more deterred from buying a Bambu? As far as I can remember, there was already something with port 3000?
Please don’t misunderstand, I don’t want to badmouth Bambu here, I’m happy with my product so far, but I would just like to see a little more openness from the product at this point.
I’d just like to chime in with my vote for this suggestion. The reasoning is that an Open API to get the printer status and last print statistics (etc.) would also open the door for users to create their own plugins or interfaces and integrate with an OctoPrint based PI - not so much for handling the print side of things, but for using plugins that already exist.
Alternatively, you could develop plugin support for the printer, but most companies are reluctant to add such things to their proprietary on-printer OS’s.
I invite Bambu Lab to reconsider the potential market an API would open in the industrial world. Last year we purchased 300 industrial printers for a single client. The X1 is a capable printer and could be included in higher quantities in larger projects, if and only if the printers are able to communicate with an MES/ERP.
We need at least an endpoint to get the current status of the printer, like current print job, progress, Eta, temperatures, etc.
And a way to push and start print jobs automatically.
Folks want a simple remote control to save printer babysitting time, and a way to download, run or stop jobs. They want a wired connection too. Firmware updates aren’t new and shouldn’t be a deal breaker.
SirWill from Bambu Labs said:
“All fine and dandy, but the printer still needs to be on the network to get firmware updates. That isn’t changing any time soon from what I understand.”
It looks to me that SirWill is saying the AP idea is acceptable, just that firmware updates are not included in the API. Sound good, when can be have it? So john_olsen how do you input this change into the Bambu Lab system. I would be happy to be a tester.
APIs are a must for modern products. I understand Bambu labs wanting to product their IP as long as possible but I at the same fail to understand how this would open you to to people backward engineering the product. Even webhooks running on predefined events would be a bonus at this point.
For my current use case, I want to get print status for various projects, e.g. a color led indicator on my desk when the printer is done so I can start a new print.
I appreciate the quality of engineering enabled by a closed ecosystem, but it seems like a huge oversight to not have an API given the kind of people who buy these products.
Seems like a bad strategic decision not to have an api. Bambu currently has a huge hardware at price advantage in the market, but that will disappear (intel was able to keep a hardware advantage for 30 years, until it wasn’t). Integrations and communities are sticker than hardware, an api enables integrations.
As a small business owner it would be neat that people can order their models from my site and that my website can query the AMS to see which filament is available and how much.
I’d love to be able to monitor all my printers in a farm in one, simple interface. I have not way switching between in Studio. This is really very simple, read only API to write. Maybe make a cloud API? I’m happy to help (being in large scale IT systems for 3 decades)
Bambu studio is open source. The code to communicate with the printer is closed source. However, the Bambu studio slicer is able to communicate with the locally running closed-source communication tool. So it should be possible to fork the slicer and add in a web service. As long as the UI is running and logged in, the web service would be able to make the same calls that the local UI does (such as sendToPrinter: github: /bambulab/BambuStudio/blob/fbc04a98fc67cdeb7b0685e92b0bee16b28d4fed/src/slic3r/GUI/SendToPrinter.cpp#L616. If anyone wants to brainstorm on this, we can host a discussion in our discord.
An api will allow for a text based interface to send and monitor prints. I am blind and the printer or studio are not accessible so I need to ask for the help of my child each time I need something printed