Octoprint for Bambu Lab A1 support available?

Depends what you mean by live stream. The Camera on the A1 maxs out at 1 frame per second, but through Bambu Handy (their mobile app) you can monitor and control what happens on your printer from remote locations. One frame per second is not great but it's enough to give you an idea how your print job is running.

have you made this yet?

If you read the full thread you'll see that I linked the repo on GitHub earlier. I have not published it to the official plugin repo.

1 Like

Hello folks,

I wanted to ask if it is possible to use octoprint only for timelapses and preferably with a webcam. I still have a Rasperypi and a logitech C920 lying around.
But everything else I want to do with the Bambu App /Studio.

In theory yes, but you can only use the interval timelapse since OctoPrint doesn't know when your printer changes layers. You also have to print some kind of dummy file on the virtual printer so it starts recording the timelapse.

1 Like

with my plugin you don't have to print the dummy file. it will detect print start and stop.

Ah nice

Even better :tentacle:

Just making sure I am understanding this right - if this plugin can detect print start/stop, does this mean you can effectively get "smooth" timelapse results with a DSLR or other camera?

Hello,

Would it be possible to a screen preview of integration of the pluggin in home assistant please? ( i would use a1 mini in my case)
Thanks a lot for the work and the sharing!

Unfortunately, the only method I know of for DSLR timelapse in OctoPrint is with the OctoLapse plugin, but that isn't compatible with the Bambu plugin because it treats the printer as a virtual SD card. For OctoLapse to work it has to be a "local" gcode file on the OctoPrint server. The default OctoPrint timelapse functionality does work with the timed option.

Home Assistant has its own Bambu integration, which the plugin relies on a module within it heavily for the communication to the printer.

Thank you for the clarification! Would a webcam or smartphone working as a webcam (with IP address) be able to produce timelapses with the previously mentioned detection of print starts and stops (made by the bambu lab smooth timelapse setting)?

I was able to get a smartphone with IP camera setup to connect to octoprint and configure everything. However, I was not able to get a timelapse to function. Would sharing a log of a print be helpful? This is my first time working with octoprint, so still learning the ropes.

the plugin in its current state doesn't know when that happens on the printer. depending on if there is a MQTT message being sent back from the printer/cloud it might be possible to hack a way around taking those snapshots in OctoLapse using it's classic triggers.

Was it enabled? Prior to the print starting or being detected as started you must enable the option on the timelapse tab.

It will show this in the state panel when enabled...

image

If the print starting is not being detected then that's back to the issue of recognition of print starting.

Thank you again for the clarification! I was able to get a standard timelapse to work, but I would really like to get a smooth timelapse. So taking your advice, I was able to get MQTTX to read MQTT messages coming from the A1 during a print. With smooth timelapse enabled, I was not able to see any discernable MQTT commands for pausing at the smooth timelapse position. So my next step is going to be attempting to manually add Gcode lines to the print file. Hopefully I can use some commands that will communicate with octolapse!

You might also be able to take a different approach and using physical triggers, ie gpio pin that gets triggered when the head moves to specific position and presses switch (would require one of the gpio plugins to send command for collapse). There's also an old trick with DSLR cameras and remote snapshot trigger buttons mounted at same position.

This means it's still possible to block Bambu printer from internet and print with Octoprint in LAN only mode?

yes it does

Hello, I find it very interesting to control my bambulab A1 mini from octoprint, it already works for me, but now I'm trying to configure it together with the Continuous Print Queue plugin, but I can't get the print queue to continue with the following files, has anyone managed to work the Continuous Print Queue from octoprint?

Are you running the latest rc version of the plugin? There was some things fixed specifically for starting SD card prints from OctoPrint that is currently broken in the stable release. You can go into software update settings of OctoPrint and change the release channel to release candidate for the plugin and then upgrade when prompted.

Hello jneilliii thanks for the reply,
Yes, I've tried it since RC18.

The problem is when you try to print the second part of queue. The first one prints fine, but the second one doesn't.
According to the OctoPrint error log, this is because it looks for a file and tries to print another one that's automatically generated. This is done by the Continious Queue plugin.

I've uploaded the log; these are the last few lines.

I'm not sure if the problem is with the Continious Print Queue plugin.

octoprint (5).log (300.6 KB)

It is very interesting to be able to print continuously and have the printer take out the pieces by itself. This is possible if we use the textured PEI plate.
When we finish printing, if we wait long enough, normally 45 minutes or so, or for the plate to drop in temperature to about 30 degrees, the piece will come off by itself.

We also have to add this to the final gcode and it will remove the piece by itself. This Gcode is for the A1 mini.
Final Gcode:

End g-code:
G91
G1 E-20 F1500 ; Retraer 20 mm para que no gote filamento
M104 S0 ; apagar hotend

G90
G1 X-13.5 Y180 F3600 ; Ir atras y al purgador para esperar a sacar pieza Y 180 En caso de A1 Mini Y235 en caso de A1

G91
G1 Z10 F600
G90
M83


; ======== eject the print =============
G0 -13.5 Y180 ; mover a purgador y esperar
G0 Z2 ; lower X until nozzle is almost touching
M140 S0 ; For some reason you need to set the bed temp again before
G04 S2700 ; ***Wait  2700 seconds "45min" wait to give the bed time to cool down around 30ΒΊ Celsius***
; M190 S35 ; Esperar a la cama a 35 grados para que retire la pieza, no funciona por un tema del firm no lo reconoce
G0 Y0 F1000 ; retirar pieza
G0 -13.5 Y180 F1000
G0 X27 Y180 Z3  F2000
G0 X27 Y180 F2000 
G0 X27 Y0  F2000 
G0 X27 Y180 F2000 
G0 X77 Y180  F2000 
G0 X77 Y0  F2000 
G0 X77 Y180  F2000
G0 X127 Y180  F2000
G0 X127 Y0  F2000
G0 X127 Y180  F2000
G0 X177 Y180  F2000
G0 X177 Y0  F2000
G0 X177 Y180  F2000
G0 X-13.5 Y180 F2500
G90 newly added - pending to test - culprit?
; ==== end eject ==================

M220 S100 ; Reset feedrate magnitude
M201.2 K1.0 ; Reset acc magnitude
M73.2 R1.0 ;Reset left time magnitude
M1002 set_gcode_claim_speed_level : 0

M400 S1
    M18 X Y Z ; disable stepper could also be culprit as Z might drop when stepper disabled - maybe 
    this should be deleted for automation