Please. Share. Logs. All of them. Especially serial.log (needs to be enabled first!).
"It doesn't work" won't get this solved. Sharing logs and information on printer, firmware, etc will in all likelihood. Until this kind of information is shared my hands are completely and utterly bound.
First off I want to apologize for my post. I was very frustrated at the time with being a new user, using what seemed to be a viable method of monitoring my printer when traveling. Being as new as I am with octoprint and 3ds printing as a whole, i had no idea of how to even post a log otherwise I would have certainly done that. I also considered participating with testing when i received a request for testers and would have if I had more experienced but felt my knowledge of it all would not be helpful to anyone and when not if something went wrong while testing a beta i would have no idea how to fix it so i stay away form that and it just wasn't a viable option yet. I had no idea how to even go about fixing the problem caused by the upgrade let alone be fixing problems that occur if i was helping out as a tester so I was completely frustrated and out of line with my comment. I definitely found out the hard way not to rely on free software if you don't know what your doing in the event something goes wrong and I certainly don't so I had better just pay for a viable service and support when needed. Again I apologize for my post and it won't happen again especially knowing what I know now about all your hard work with limited resources. Maybe after I gain much needed experience with this type of software I could possibly help out with testing in order to help others but for now I better just apologize and regret for my post and hope you can forgive me for it and move on. Good luck with your software and hopefully you don't give up on it because of an idiot like me that is new to it all and posted a comment from the peanut gallery that was reflective of frustration stemming from lack of experience to know what to do to fix it after spending 3 months setting up a brand new printer and upgrading it in order to get it and everything else running flawlessly before i upgraded the software and thought all the time I spent was wasted. As an FYI...The hot fix did fix the issues i had in common with everyone else that posted logs and constructive posts after the 1.3.7 upgrade so feel good and be proud about that!! I actually thought it would be weeks or even months before any kind of fix came out so that was completely amazing work! Take care.
A short update on this...
Thanks to logs provided in this ticket I was able to identify a race condition which could affect both pausing and cancelling in a way that communication got "stuck". Until I'm able to push out 1.3.9 (which I'm currently not due to travelling and lacking a proper test environment) two possible workarounds are available.
The first is disabling pause/cancel position logging altogether:
This has the downside that if you have a resume script that depends on the pause position, that will no longer work since OctoPrint will no longer record the pause position. Same goes for any kind of print recovery plugins relying on position logging.
The other option is clicking the "Fake Acknowledgement" button if things become stuck:
That will basically do manually what the fix for the above race condition will do automatically and should make things going again if your printer is otherwise producing valid position reports. If this doesn't work for you, you'll need to go with the first option. If so, please provide the response of your printer to an M114 here so that I can see if there's a possibility to make things work after all by adapting OctoPrint to also be able to parse your printer's position report.
Good luck with your software and hopefully you don't give up on it because of an idiot like me that is new to it all and posted a comment from the peanut gallery that was reflective of frustration stemming from lack of experience to know what to do to fix it after spending 3 months setting up a brand new printer and upgrading it in order to get it and everything else running flawlessly before i upgraded the software and thought all the time I spent was wasted.
Please stick around. Ask questions. If you are trying, we'll try to help. For instance, if you said "I don't know how to find the logs", we can help with that.
Perhaps a Plugin like "Emergency Stop", which I also had, can conflict with the new cancelling function.
I on my side was helped by removing plugins, including the emergency stop, only for another erroneous behaviour.
Checking the influence of plugins on your setup can be a good idea.
Cheers,
Leo.
Ironically, I started getting this today. doh! I knew I'd seen this thread, just hadn't had the problem.
Since this keeps coming up it now has its own FAQ entry:
Just for general amusement: I still haven't been able to trigger it myself during normal operation, only with a development version modified in such a way that made the occurrence more likely.
I am currently running 1.3.8 and I've seen this now... twice (stuck on Cancelling). Was just watching the #16 blog video and learned about the work-arounds. Thanks.
I don't think this race condition is related to the Type B USB cable in my case since my printer has a shielded/short cable for this. (I did sometimes have more problems on my separate development rig which is a new RAMPS board and a Raspberry Pi 3 so I bought a shorter cable for that one.)
If it will make you feel any better, I witnessed a 3D printer manufacturer go through the motions of QA testing with a roomful of people per version over a period of a week and yet... all around you see no control of the things that they're testing. They were testing a new fan shroud design to fix a runaway heater problem... only there wasn't a single person in the room who had left on the logo'd cover over the assembly; they were testing something that wasn't reality for the consumer.
I'm running 1.3.8 on 0.15.1 with the dreaded Anet A8, and have had no issues cancelling the same stupid ABS print that only works every other try
I click the cancel button, and the "Are You SURE ?" button pops up, I tell it that I am absolutely certain that I wish, in no uncertain terms, for it to cancel, then it either cancels almost immediately, or it waits, sometimes up to 45 seconds (probably a buffer thing) then it stops and my controls light up again
So, it seems to be working properly for me, under those circumstances
For me this has gone back to 1.3.6 or so.
Tevo Tornado which uses an MKS GEN/Base board running Marlin 1.16
Multiple Pause/Resumes causes it
Canceling never works, Hotend/bed temps stay active. The easiest fix is to restart octoprint, forcing the printer to reconnect.
Serial.log doesn't show the problem. You see "monitoring state from Printing to Canceling"
And then nothing. if it was paused you see temperature responses
I've had this happen to me a few times on both 1.3.7 and 1.3.8 running OctoPrint on RPi with a Prusa i3 MK2S with the latest firmware (Nov 2017 I think). The Fake Acknowledgement does work, just remembering where it is hidden was the trick for me ;-)--that's why I can in here, so I thought I'd add the Prusa to the list of printers--if that helps.
How does one get to the Fake Acknowledgement button when the software is hung?
Thanks, but I know where it is.
I can't click it though because the entire UI is unresponsive when it hangs on cancel.
Oh, I see.
There were two work-arounds in the FAQ on this. Both of those were reactive from what I saw. The more proactive one was pressing the Disconnect/Connect in the Connection side panel widget.
And then—if you've seen this more than once—you might just want to take one of those work-arounds as a precautionary step. (I get this one from time to time but not often enough to take any Settings-based measures yet.)
I tried the first workaround - switching off the event based position logging. Hasn't helped.
Unless others are seeing completely different "hang on cancel" behavior from OctoPrint's web interface, I think the second workaround is bogus, as you can't click that button or anything else when it hangs.
They are. Your UI lock-up isn't the normal behaviour at all and it sounds like something else is going on here, otherwise both workarounds would work just fine. The issue described here is contained within OctoPrint's backend and doesn't affect the UI in any way, that remains completely responsive. If you UI is hanging, it has other reasons and you'll need to dig up some logs so that can be investigated further and possibly turned into a bug report.
I think the second workaround is bogus
I'm not in the habit of offering up "bogus workarounds".
For what its worth, this happens to me as well although not every time. Octoprint 1.3.8, marlin 1.1. Tevo tarantula, Rpi 3, windows 10, chrome 65.xxx. I'm not as technologically advanced as most so I really do not know how I can contribute but if any is needed from me just say and if I dont know it or how I'll be sure to ask. Thanks
Had same issue with new CR-10S. I used the Fake Ack and it worked every time after pausing and resuming.
I'm curious where/if this is being sorted out/tested? I don't mind testing for you.
As a note I am running OP 1.3.8.
Foosel indicates that the race condition will be worked on in v1.3.9, for what it's worth.
