Much better 
bTW my printer firmware is 1.06 if that matters. I got a notification that there is new firmware available but I was afraid it would break my Xtouch.
I enabled debugging and pulled up my octoprint logs and found these entries below. It says it isn't getting a response from the printer. Can someone point me in the right direction please?
2024-07-30 20:56:34,357 - octoprint.plugins.bambu_printer.BambuPrinter.serial - DEBUG - Closing IO read loop
2024-07-30 20:56:34,384 - octoprint.plugins.pluginmanager - INFO - Loaded notice data from disk, was still valid
2024-07-30 20:57:04,268 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.
2024-07-30 20:57:05,277 - octoprint.util.comm - ERROR - Could not write anything to the serial port in 5 tries, something appears to be wrong with the printer communication
2024-07-30 20:57:05,280 - pybambu - WARNING - On Disconnect: Disconnected from Broker: 0
2024-07-30 20:57:05,787 - octoprint.util.comm - ERROR - Error while trying to close serial port
Traceback (most recent call last):
File "/home/pi/oprint/lib/python3.9/site-packages/octoprint/util/comm.py", line 1250, in close
self._serial.close()
File "/home/pi/oprint/lib/python3.9/site-packages/octoprint_bambu_printer/printer/bambu_virtual_printer.py", line 575, in close
self._serial_io.close()
File "/home/pi/oprint/lib/python3.9/site-packages/octoprint_bambu_printer/printer/printer_serial_io.py", line 98, in close
self.flush()
File "/home/pi/oprint/lib/python3.9/site-packages/octoprint_bambu_printer/printer/printer_serial_io.py", line 104, in flush
self.raise_if_error()
File "/home/pi/oprint/lib/python3.9/site-packages/octoprint_bambu_printer/printer/printer_serial_io.py", line 108, in raise_if_error
raise self._error_detected
File "/home/pi/oprint/lib/python3.9/site-packages/octoprint_bambu_printer/printer/printer_serial_io.py", line 72, in run
self._process_input_gcode_line(line)
File "/home/pi/oprint/lib/python3.9/site-packages/octoprint_bambu_printer/printer/printer_serial_io.py", line 184, in _process_input_gcode_line
self._handle_command_callback(gcode, command)
File "/home/pi/oprint/lib/python3.9/site-packages/octoprint_bambu_printer/printer/bambu_virtual_printer.py", line 466, in _process_gcode_serial_command
handled = self.gcode_executor.execute(self, gcode, full_command)
File "/home/pi/oprint/lib/python3.9/site-packages/octoprint_bambu_printer/printer/gcode_executor.py", line 307, in execute
return self.gcode_handlers[gcode](printer, data)
File "/home/pi/oprint/lib/python3.9/site-packages/octoprint_bambu_printer/printer/bambu_virtual_printer.py", line 443, in _set_feedrate_percent
percent = int(data[1:])
ValueError: invalid literal for int() with base 10: '220 S100'
2024-07-30 20:57:05,789 - pybambu - WARNING - On Disconnect: Disconnected from Broker: 0
2024-07-30 20:57:05,828 - octoprint.util.comm - INFO - Changing monitoring state from "Printing" to "Offline after error"
2024-07-30 20:57:05,854 - octoprint.filemanager.analysis - INFO - Starting analysis of local:_3DBenchy_PLA_37m35s.gcode
2024-07-30 20:57:05,859 - octoprint.filemanager.analysis - INFO - Invoking analysis command: /home/pi/oprint/bin/python -m octoprint analysis gcode --speed-x=6000 --speed-y=6000 --max-t=10 --throttle=0.0 --throttle-lines=100 --bed-z=0.0 /home/pi/.octoprint/uploads/_3DBenchy_PLA_37m35s.gcode
2024-07-30 20:57:05,865 - octoprint.server - INFO - Starting autorefresh of serial port list
2024-07-30 20:57:05,901 - octoprint.plugins.action_command_notification - INFO - Notifications cleared
2024-07-30 20:57:06,002 - octoprint.server - INFO - Serial port list was updated, refreshing the port list in the frontend
Please when searching for issues, always attach a systeminfo bundle. That has way more information.
This may be related to recent changes to the plugin when being refactored. The difference between file/timelapse listings is that's done via ftps and temp reporting is done via MQTT protocol so it's completely possible that one would work and not the other. If you don't mind, try the previous version and see if it's the same for you. Go into plugin manager > get more and in the ...from URL field copy/paste this URL into it and click install. When you restart, don't upgrade the plugin when prompted and see if it does the same thing.
https://github.com/jneilliii/OctoPrint-BambuPrinter/archive/refs/tags/0.0.23.zip
@MisterTee please provide system info bundle in this issue: https://github.com/jneilliii/OctoPrint-BambuPrinter/issues/35
Is MQTT part of the installation package? I don't recall installing it. I just uninstalled the newest plugin and I'm restarting. I'll install the old one and let you know how it works.
Wait it just started working with the old version. It started working after closing the System Info page. Maybe the older version did fix it.
So to clarify. the Bambu A1 does currently have compatibility with Octoprint on a Rasberry Pi, but will require some fiddling to get it working correctly with most/all features you would see on other printers? I'm still learning and want to make sure before I buy a new printer, which I am considering to be the A1
The Bambu printers kind of have their own ecosystem that utilizes the slicer as kind of command and control of the printer. If you enable cloud connectivity to the Bambu servers you can also use their mobile app and monitor/control remotely outside of the network. Cloud mode also allows you to list files on the printer's SD card, which you can't do in non-cloud mode.
What my plugin does is use the same communication protocol that the slicer uses to send commands and receive data to/from the printer. It has the added benefit of being able to use non-cloud mode to list files and you can start printing those files that have previously been sent to the printer by the slicer.
Yes, it's fiddly but there have been people report that it works on the A1.
Understood. Thank you for the detailed response
Oh, and since you mentioned the A1, using OctoPrint with a USB camera and streaming may be way better in quality vs the built-in camera from what I've heard from others. It also enables built-in timelapse functionality of OctoPrint that way.
Oh amazing. That was something i wanted to look into as well. You're a star, thank you.
i've got a bambulab A1 running a working actopi with bambu-plugin. temp working, movement working, sd-reading working. but when i send a file the 3mf files are corrupted and the printer shows a "microSd card read/whrite exception" anyone has an idea to fix this?
I haven't heard of that issue from anyone else. Have you tried a different SD card. Enable debug logging in OctoPrint's logging section for the plugin and it might hint at what's happening.
As I understand: You try to print a *.3mf file?
With bambu printers when you slice a file it puts the actual gcode into a 3mf. The plugin actually adds this to allowed extensions and should upload to the printer's SD card via OctoPrint as a virtual SD card. However, sending the file directly from the slicer is what I've always done, although direct smf file upload has also been tested and working on my X1C. I should probably re-validate that since the big refactor though.
1 Like
Yep, it does appear that the recent refactor broke the file uploads. Looking into fixing it now and will be part of the next release soon.
Tested with my A1, currently it connects to the printer, it takes quite a while to show files from the SDCARD but it shows them, but I cannot start a print or send terminal commands.
It shows me the terminal of the printer and I recieve commands, but I cannot send.
When selecting and pressing print, it modifies the octoprint ui to seem like it's printing but it's not. Also, moving files to the sdcard works very weirdly. It gives me an access error, but if I refresh, the file is on the sdcard.
Also, octoprint cannot see the camera but that's not a big deal for me.
To be honest, the only thing I would use octoprint for, on my A1, is to track filament usage. So, for me it would be enough to be able to start prints from it.
I'm just so annoyed that a sophisticated printer as the A1 doesn't offer any modern way of tracking filament usage.
this generally makes sense because moving files from OctoPrint's local files to SD card is something that is handled by sending commands line at a time to the printer. because of the way Bambu printers work I'm surprised that even works. you should be able to upload files through OctoPrint to the SD card though.
Starting and managing print jobs that are stored on SD may not be able to track filament usage anyway, because the plugins that do that I don't think work with SD card files, and this plugin is developed completely around the fact that Bambu printers are presented as a virtual SD card to OctoPrint.
The only thing that could hinder operation is cloud mode vs local only mode, and not using the same for both the printer and the plugin.