I'm new here and tinkering around with octoprint (OctoPrint 1.3.12 running on OctoPi 0.16.0). Right now mit MMU2s is giving me an load/unload failure headache and while trouble shooting I stumbled upon this lines in the log:
2019-12-29 20:55:59,878 - octoprint.plugins.softwareupdate - ERROR - Error while retrieving update information from plugin mmu2filamentselect
Traceback (most recent call last):
File "/home/pi/oprint/lib/python2.7/site-packages/octoprint/plugins/softwareupdate/init.py", line 127, in _get_configured_checks
hook_checks = hook()
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_mmu2filamentselect/init.py", line 108, in get_update_information
displayName=self._plugin_name,
NameError: global name 'self' is not defined
I doubt this is the reason for my MMU2 headache. Especially since it did what advertised in the single material prints. Nontheless, something seems not quite right. Any ideas?
Thanks for your input! But yes, everything is fine there. As a first step I'm only worried about this error.
A second step will be figuring out, why the octoprint server sometimes seems to shut down while waiting for me to fix MMU issues (line 160 in the log). But I'll try to reproduce this error first in safe mode and post in a different topic. Lastly I'll have to sort out (the obviously common) stringing/jamming filament problems...
Have you found anything further out about the issue you mentioned with Octoprint shutting down while waiting on MMU issues? I've experienced this a few times recently, but haven't isolated it in my logs yet. I have been using the filament selector plugin as well, but haven't noticed any issues with it. I have been using the MMU (2S) for a while with Octoprint. The "number of extruders" issue caught me a few month back after an upgrade, but I have been successfully printing both single and multi filament jobs since then. I think that some recent update changed something, though, and my most recent issue was a 19 hr single filament print that had an MMU fail in the 18th hour (end of a roll of filament hung on the spool) but rather than pausing, Octoprint somehow considered the job complete (and my recovery attempts by modding the gcode all failed ) . I'll start a separate thread on this if I can replicate it and get the relevant logs, but maybe you'll have found and solved it first.
Unfortunately there wasn't any progress in this. I temporarily stopped using octoprint and am trying to sort out my mmu2 jam troubles with simple printing from the sd card.
However, the original issue was identical to yours: mmu2 required repeated tinkering, initially subsequent printing went on fine, then all off a sudden there was no more input from octoprint.
Moreover, I observed similar behavior also while not printing:
The raspberry pi/octoprint isn't used for a longer period of time. When switching back to the octoprint tab on my desktop there is a banner informing me, that octoprint has gone offline.
Interestingly, according to the log, the server has been up an running right to the point, when I went to my desktop and realized that it's down:
2020-01-05 21:30:02,245 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-01-05 21:35:18,273 - octoprint.server.util.sockjs - INFO - Client connection closed: ::ffff:192.168.178.20
2020-01-05 21:35:18,504 - octoprint.server - INFO - Shutting down...
2020-01-05 21:35:19,398 - octoprint.events - INFO - Processing shutdown event, this will be our last event
2020-01-05 21:35:19,402 - octoprint.events - INFO - Event loop shut down
2020-01-05 21:35:19,406 - octoprint.server - INFO - Goodbye!
The first entry shows, that everything was find before I returned back to the octoprint browser tab.
21:35 I saw the banner telling me that octoprint is offline and only then server actually seems to be shutting down.
As if my checking on it with the browser caused the shutdown in the first place. Does that make any sense?
I don’t think my Raspberry Pi is turning off, or at least it’s up and running every time I check. I had recently upgraded to a Pi 4 with a better power supply because of worries that would happen with my previous Pi 3 and under voltage warnings.
I had another print failure because of this Octoprint issue last night. I was trying a multi-filament print with the MMU. When I checked this morning the printer had run for a bit and then stopped at the first color change, only rather than an MMU error waiting patiently for me as I would normally expect, Octoprint shows the job completed (and the MMU is green rather than flashing red, and it retracted filament but didn’t change filament colours). The web interface acts as if the job ran for 9 + hrs and completed successfully, when it probably only ran for 30-40 minutes. I double checked and my printer profile (only one in Octoprint) has 5 extrudes via 1 nozzle set.
Again, sorry to attach this to your thread, but I can’t start a new post (and expect any help) without the relevant logs and mine all aged off the terminal window overnight. I don’t know if the moderators will only accept the Gcode of the failed print.
There is another post mentioning issues with long pauses on a Prusa. I’m not sure if this is related.
Frustrating, since this was all working fine for ages, and now something between Octoprint updates and PrusaSlicer updates has broken it. Back to SD card printing for me too, I guess.
Apologies, but I was wrong in my last post. When I reprinted the same Gcode using the SD card instead of Octoprint, I realised that the failed job via Octoprint had actually completely ignored a number of filament change commands. It printed only one color and appeared to just arbitrarily stop and say the job was complete after a dozen or so layers (maybe 10%). It had ignored the pieces that were supposed to be printed using the second filament altogether.
I’m curious now whether Octoprint is working for MMUs at all anymore.
) . I'll start a separate thread on this if I can replicate it and get the relevant logs, but maybe you'll have found and solved it first.