[BUG]: A1 not reporting printing status and temperature #52
Comments
|
It doesn't appear that a file list is ever generated of files that have been sent to your printer from the slicer. I feel like this might be a connection issue between the plugin and cloud. I assume you were able to login and generate the token necessary for connecting the plugin to the cloud? I'm concerned this may be a connection limit issue possibly because looking at the log, it seems that the plugin was stuttering connection to MQTT on startup. What firmware version are you running on the printer because I think @synman mentioned recently that there was a firmware update that increased that limit I think. |
|
I'm using firmware 01.03.01.00, was able to log in and generate the token |
|
So Just to confirm, the connection problem is still persistent ? I'm unable to have the plugin work locally or through the cloud. When clicking on "login" in the cloud connection settings, nothing happens and no tocken is created. Locally, Octoprint shows the A1 as "operational" and that's it. Temps and print status are not being reported. A1 firmware is up to date. Things were running normal a month or 2 ago.. |
|
If you switch the release channel for the plugin to release candidate and update when prompted there are changes in that version that might resolve the cloud connectivity issues. I haven't had time to personally test it myself, hence it still being in release candidate state. If it's still an issue, please do provide full logs (with |
|
Thank you. I installed the RC version but it's not showing in the settings menu. |
|
thanks, I can confirm the same. looks like I may have missed a file during release. in ocotprint.log do you have the error of missing filaments.json file? |
|
Yes I do: FileNotFoundError: [Errno 2] No such file or directory: '/home/orangepi/OctoPrint/lib/python3.9/site-packages/octoprint_bambu_printer/printer/pybambu/filaments.json' |
|
Ok, just fixed and verified. You can copy/paste this URL in plugin manager > get more > ,,,from URL to install and it should work. |
|
I think this release fixed the issue. I'm now able to log-in with cloud connection and token was successfully created! I'll keep you updated if I find any issues. Thank you you're a hero!! |
|
After some testing, I can see that Octoprint is now correctly reporting the bed/hotend temperatures, however the issue related to print status is still present. Octoprint will show "State: Operational" even after the printer starts printing. The attached log shows the same error as before "No SD Card printing" |
|
I think this might boil down to when printer is cloud connected, the connections to other services in local mode (ie file upload, listing, etc. via ftps) is blocked. From the log it seems that the printer never responds to the |
|
I am not sure if this would also apply to the plugin, but I am able to access the files on the printer while its cloud connected via FTP using FileZilla, username being bblp and the password being the access code of the printer, see attached screenshot for the exact settings. |
|
Well, those are the settings the plugin uses to connect to ftps, so must be someone else causing the issue. Maybe that's was an old firmware version limitation that doesn't exist anymore. What firmware version is everyone running? |
|
running 01.03.01.02 on the printer, might be beta firmware but i'm not 100% as it doesn't really make it clear when beta firmware is being used |
|
I pushed version 0.1.8rc2 of the plugin after finding a couple of other spots where I needed to adjust for the transferring of the pybambu module into the plugin itself. Those would have only effected pause/cancel commands though and shouldn't have an impact on the file listing I don't think. Relative to the file listings though, like I mentioned, the list is pulled from the printer using this patched ftp module in the plugin. It's one that I've found online in the bambu forums or part of some other integration. Maybe I need to tweak it more for A1 support. |
|
The file list generates fine, at least for me. The things not working are the temps (both always report at 21.3C with target being off), and it always saying not SD printing, even if it is printing. |
|
Are you running the 0.1.8rc2 version of the plugin? That should be fixed in that one. |
|
am running 0.1.8rc2, included the logs |
|
weird, it looks like it's just not establishing the connection to the cloud mqtt server |
|
Just connected my printer to the cloud to validate, and temperatures seems to be reporting properly for sure. I was able to change the temp from both the OctoPrint interface and the bambu handy app and they changed in the other. |
|
Just want to add to this discussion, as I'm having similar problems (I'm on 0.1.8rc3 now, but I was having the same issue on 0.1.7). I'm in LAN only mode. Octoprint is getting temps, file info, AMS info, etc., but the State is stuck on "Operational" and doesn't change. To keep the logs short, here are my logs for a brief period of time. Please note that I connected and disconnected manually. serial.log If there's anything I can do to help track this down, please let me know. Thanks for all your work on this plugin. |
|
The more data the better. A unaltered (you can prune it for any possible passwords, etc.) octoprint.log would be helpful and based on this snippet of serial.log were you printing "Alien_Cutie_0821003814.gcode.3mf" or "ub_out_4.gcode.3mf"? |
|
I was printing "Alien_Cutie_0821003814.gcode.3mf". (https://makerworld.com/en/models/644787#profileId-570879) Here's my log: Edit: In that log, there's a section where I was trying to connect to the printer at the wrong IP address. Hopefully save you some time with that. |
|
If you get a chance please enable debug logging for the whole plugin. I'm only really seeing printer disconnect messages in this octoprint.log. Once enabled you'll need to re-create the situation so I can get some more data in the log.
|
|
Not a problem. I enabled serial logging, enabled debug logging for the plugin, rebooted octoprint (with auto connection enabled on boot), let it run for a bit, and then manually disconnected before grabbing the logs. octoprint.log Edit: I can't believe I didn't mention this yet, but I'm using an X1C... not an A1. |
|
Hi again! I updated today to RC3 and I have no issues with the temperature reporting. RC2 fixed it and it's still working. I'm cloud connected, but I'm planning to try local connection only through Bambu Print. RC3 appears to have fixed some issues. Octoprint is detecting the correct status of the printer and is showing "Printing" in stead of being stuck on "Operational". However the moment the print order starts it immediately shows -100% and doesn't show the time left or print progress.
Octopapp is running and monitoring spagetti detection but showing -100% Ocoteverwhere immediately sent an email when I started the print saying that it completed printing (100%) Aside form this, my main concern which is spagetti detection is now running and Octoprint can detect print orders. EditI'll report once the current print job finishes to see if Octoprint is able to detect that! |
well, the title of the issue was for A1, but it seems you are experiencing similar issues so could be related, but I think it might be a different issue altogether, rare condition with specific reasons why. I find this entry interesting...
I need to look at that makerworld listing and look at the 3mf file, because there have been weird instances of named plates in a 3mf file not matching the file name resulting in stuff like this in your log.
When that happens it doesn't know the total size of the file in order to report to OctoPrint the percentage value, and that subtask_name attribute is what the plugin uses to figure that out and start reporting printing. |
|
Interesting... Now that you're saying that, the print state stopped working in 0.17 when I started printing that file. It had been working before. I'll get a different print going tomorrow and see if my issue goes away. |
|
If it works regularly with another file you might try downloading the stl and slicing it in the slicer and sending to the printer instead of using direct 3mf. might make a difference in getting the subtask_name to match the sliced file. |
|
one option might be to see if either |
|
Yeah, was considering that as an option, but adding additional lookup round trips through the file list doesn't feel efficient. I'm already thinking that there may be a bunch of unneeded lookups currently in the codebase, which was something I missed when reviewing a big refactor of the plugin by someone else. I will consider that as an option though now that I'm looking at this file lookup code more in depth. |
|
If I send a file from Orca everything works fine. If I start a print from the printer or OctoPrint it seems to get stuck on 1/x bytes printing. As a result, when the print does finish it never triggers printing all the file and is seen as cancelled by OctoPrint. I can't tell yet what variable isn't getting reset during the print start or finish process that would cause this weird condition. file started from printer... |
|
interesting, I haven't yet tried starting from the printer, but when I start a print from octoprint, I get an SD card error if its a file from the printer's SD, or it sends batches of commands really quickly, which causes the printer to get confused if the file is on the raspberry pi's SD card. |
|
I get some errors occasionally when starting from OctoPrint but the print still starts. Would be interested in seeing what error you are referring to. |
|
it gives a micro SD card read/write error, included a screenshot below |
|
That is very strange. The errors I were referring to were in octoprint.log, I've never seen an error like that from Orca/Printer. I wonder if the file pathing I use for the start print command changed or got messed up for non X1 devices (can't remember who has what device in this thread). |
|
It might be different for the A series (A1 and mini) as they are bedslingers rather than coreXY printers, I personally have the A1 with AMS lite, I think @aslabsalbeh and @jcostom also have an A1, so for those that do have an A series printer, do you also have the same issue of the sd card exception being shown when starting a print from the SD card through octoprint? |
|
Just FYI...cloud connected printers are probably going to be broken due to changes by Bambu... greghesp/ha-bambulab#673 |
|
interesting, though I think this would only affect the plugin being connected to the printer trough the cloud. My printer has a cloud connection, but the connection between octoprint and the printer is local only, which seems to work just fine. |
|
you would think that, but there are some instances of A1/P1 devices not accepting local connections when they are cloud connected. |
Back tracked this issue and appears it was another mistake by the person that refactored the plugin. The base path was incorrect for non X1 devices. 0.1.8rc6 should resolve that. |
|
Downloaded the repo to test, and printing from the SD does now work, however, the AMS lite slot selection does not seem to function. When I start print I click slot 4, but it tries to use slot 1 (which doesn't have filament and causes it to stop). |
|
Yeah, the AMS assignment for starting prints is very convoluted, mainly because the way the slots are assigned. In general, if you sliced your file using slot 1 of your AMS, you rearrange the spool buttons (drag the buttons around) to put the color you want in that first position. Double-click buttons to disable them (only necessary for multi-color prints I think). |
|
potential fix for the progress not updating in the above commit, about to release 0.1.8rc7 with those changes. |
|
just release 0.1.8rc9 with some tweaks related to starting prints with cloud connected printers. your printer has to have the cache files locally option enabled but that hopefully will be the last bit related to this issue that could be causing problems. Please report back your experience. |
|
I'm connected locally and things seem to work normal except that the print progress is stuck at 0%. |
|
are you running the latest rc version? I know from the HA side of things that cloud connected printers are probably broken again as cloudflare/Bambu have added additional blocks and not sure if there will be a fix. please make sure debug logging is enabled and share both octoprint.log and bambu logs after recreating the issue. |
|
I just experienced the same thing, and it boils down to the file name not matching the project name saved in the 3mf file. This seems to happen probably with 3mf files downloaded directly from printables/makerworld or ones that have been saved locally. so basically this: |
|
I've been running the latest release candidate for a bit now, and it mostly works except for the progress, its always at -100%. Print is started from bambu studio/orca slicer. I am running beta firmware 01.03.20.20. |
|
@Joelminer-satisfactory is the files you are printing downloaded 3mf files, as mentioned above in the previous post? I need to know if the un-matched model name to file name is causing your issue. |
|
No they should match, I imported an stl that I made and the project file was filename.stl.3mf, it did correctly show the file in the status panel |
|
could I get updated debug logs from your instance, after a full restart of OctoPrint. I suspect the first print will go correct from 0 - 100% and the following print will be the one that is stuck at 100%. that's what happened to me when I saw this before. |
|
I won't have that for a bit as I have run out of filament, so I'll need to wait for the new rolls to arrive, but ill send it asap after that. Both prints I did stayed at -100% though (sd printing byte 1/0) |
|
another thing to test while it's broken and printing. if you disconnect from OctoPrint's connection panel and reconnect, does the percentage then update to where it's supposed to be? |
|
Hm it now seems to work fine, both with a downloaded model and a local project, maybe octoprint rebooting solved the issue |
|
sounds like a race condition, which are usually really hard to nail down. |
Description
When connected to my bambu A1, octoprint does not report the temperature correctly, it also doesn't show the status as printing, it just constantly repeats "not sd printing" in the terminal
Debug Logs
octoprint.log
plugin_bambu_printer_serial.log
Printer and Plugin Setting Details
printer model: A1 + ams lite
box for local access: unchecked
printer is cloud connected, cloud connection works via bambu handy and bambu studio
The text was updated successfully, but these errors were encountered: