I have a bizarre new behavior effecting my printer over the last few days.
Whenever a print finishes or is cancelled, Octo starts running through the file again. It isn't actually printing, but the print time and print left values are incrementing rapidly. It's almost like it is simulating printing it. The cancel button is greyed out, so the only way to start a new print is to restart Octoprint.
The bed and hot end are not heated, and there is no movement, so there is no particular safety issue, but it's a pretty big hassle to have to restart every time.
Running in Safe Mode does seem to prevent the problem, so I assume it is plug in related, but the only plug in that I remember updating recently is PrintTime Genius, and disabling it does not seem to have addressed he issue.
Any hints?
Thanks!
(I hope this is not an FAQ. I scrolled through the last couple weeks of posts, but I can't for the life of me think of any search terms to track down threads on this.)
That is even more weird. It never would have occurred to me it was a slicer issue. I do slice with Cura, and I have the OctoPrint connection installed, but I never use it and just upload the files manually and print from the Octo interface. But disabling the Octo connection plug in seems to have fixed it
Version 4.1 of Cura, version 3.2.2 of OctoPrint Connection.
Yeah, it makes no sense to me, either, and I didn't even write it, so I can understand your confusion. I am still a bit dubious that that was the cause of the problem, despite my quick tests suggesting it fixed it.
I have been testing with really small files (5-10 minute prints), but the ones where I have noticed it previously were multi-hour prints, so there is some chance that the small files are hiding the problem. I can run some long prints tomorrow to see if the problem recurs.
I think you mean version 3.5.2 of the OctoPrint Connection, because I don't think a 3.2.2 version exists and if it did it would simply not load in Cura 4.1.
If you don't use the plugin, I suggest you either uninstall it or at least update it to a newer version.
I see. That version predates my specific checks for compatible versions. Still, if you don't use the plugin, I suggest you either uninstall it or at least update it to a newer version. As is, this old version is copied over from Cura version to Cura version on your system. It may start causing crashes in Cura at some point if you don't uninstall or update it.
The API version specified in that version of the plugin should stop the plugin from loading in Cura 4.1. So I don't see how "enabling" this version of the plugin in Cura 4.1 can cause any duplication of gcode.
Ok, I haven't used the printer in the last couple days, but I just finished a print and see the problem is back, this time with the OctoPrint Connector disabled. I have just now enabled Serial Logging, so I will post those next time I see the problem, but I thought I would toss out an update in the meatime.
I took me a while to find the time to troubleshoot this further, but I have finally figured it out. I recently switched browsers, and it turns out the problem is due to an oddity of the Brave Browser.
Unlike Chrome, Brave caches any UI updates if the web page is open but in the background, then it "plays them back" once the page is moved to the foreground again. For a multi-hour print that has been in the background that whole time, it will take quite a while to catch up.
Fortunately, there is a fairly easy solution: Just reload the web page. That flushes the backlog and gives you the fresh, current page.
If anyone knows of a setting in Brave to change it's behavior to the standard Chrome behavior, I would appreciate it, but if not I can live with the problem is it is now.
You should take this to the Brave browser repository, open a bug and describe how potentially dangerous this is when monitoring manufacturing equipment.
