-
-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG]: Successful print reported as Cancelled #53
Comments
Was the print started from OctoPrint or by sending to printer from slicer? Would be great to get the full log as an attachment, you can just drag it into the comment here on GitHub. |
I sent the print from the slicer (Orca) As for the octoprint log, it is not the hole file but everything from befor starting the print until it is done. |
I found some weird stuff in my OctoPrint installation and custom GCODE Scripts that might be the reason for this behavior, I will try a print tomorrow and let you know if I found something. For some reason the username and the password was typed in some of the fields: But I will do a test and get back. |
I was just about to say to make sure you don't have any gcode scripts configured in OctoPrint to start. Also, make sure in OctoPrint's logging section that the |
So I just finished a print, still printing from the slicer (Orca), I get no Print Started nor Print Finished What I am trying to achieve is for the plugin to get Print Started, Print Finished, Print Paused, Print Canceled, etc and then by using the WLED Connections plugin set status light. New log file: |
If you start a print from OctoPrint and it sees "Not SD Printing", it will assume that the print was cancelled. From the plugin code, I can conjecture a couple of ways this could happen:
We could introduce some mechanism where after an M24 is processed we pretend there's a print_job for some time interval so that we don't answer incorrectly while waiting for the next MQTT. For the queue's passing each other, I'm not sure. Dumping the outgoing queue when M24 is received might be too late because OctoPrint may already have read the queue before the virtual printer processes the M24. |
wow, @markwal, blast from the past. didn't even know you were still around. always open for suggestions, but I think in this case it may have been related to detecting the start of the print. I have made several tweaks to the current rc branch and relevant rc releases that will probably help drastically in this issue. |
also, as mentioned on the other issue #52 If the file name does not match the project name saved in the 3mf file the print won't get detected as printing when started from printer panel or cloud. This seems to happen probably with 3mf files downloaded directly from printables/makerworld or ones that have been saved locally. |
Describe the Bug
P1S finish print successfully reported as candled in OctoPrint, Bambu printer reports print successfully finished.
Expected Behavior
Successful finished print should be reported as successful
Debug Logs
2024-10-25 11:31:15,885 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2024-10-25 11:35:06,944 - octoprint.util.comm - INFO - Changing monitoring state from "Printing from SD" to "Cancelling"
2024-10-25 11:35:06,948 - octoprint.printer.standard.job - INFO - Print job cancelled - origin: sdcard, path: Paddle box .3mf, owner: None, user: None, fileposition: 1, position: {'y': None, 'f': None, 't': None, 'x': None, 'e': None, 'z': None}
2024-10-25 11:35:06,965 - octoprint.plugins.bambu_printer.BambuPrinter - INFO - command sent successfully
2024-10-25 11:35:07,022 - octoprint.access.users - INFO - Cleaning up user session 4BC3AF038A8E4B038B31B7A6DE089DBD for user
Screenshots
Printer and Plugin Setting Details
Bambulab P1S with AMS, default plugin settings
Yes
Yes
The text was updated successfully, but these errors were encountered: