OK when I pause it this is what I see in terminal..
Regards,
-Joemac
** EDIT.. Seems I have reached my limit on this topic so I am doing an update via an EDIT **
My take from all of this is that I have to delve into the wonderful world of firmware for my printer. It has become painfully obvious that mine is woefully out of date. I will have to step back and learn how to do this without blowing up all the configuration but the time has come.
Once again, thanks for all the help folks, much appreciated.
Regards,
-Joemac
There are instructions on how to downgrade contained within the FAQ.
As for the upgrade, foosel only has a limited amount of resources and can't possibly test every single printer and server hardware combination. Release candidates are released and tested by the community, and if all goes well then the final version is released. If more people with "weird" or custom setups would test those release candidates then perhaps more issues would be seen earlier and be able to be looked into before the final version is released.
The other issue is that there is literally no standard for 3d printers. There's a loosely agreed on way to communicate with them, there's a few guidelines that some firmware manufacturers follow in terms of responses to temperature requests and the position information request, but a LOT of the cheaper printers from over seas are using firmware versions from many MANY years ago that still contain bugs and malformed responses, and others just go completely off on a tangent and do their own thing with their own custom responses, that their own software is designed to look for, but then breaks every other host out there.
What works for the latest version of a particular firmware might break on older versions, so any new features added to OctoPrint have the potential to fail on older or broken firmware. This is NOT OctoPrint's fault, it is up to the printer manufacturers to keep on top of mainstream firmware bug fixes and protocol updates, and then merge the up stream changes with their own versions. You wouldn't expect some car manufacturer today to still be making cars based on the Model T specifications, yet 3d printer manufacturers are still making printers based on control boards and firmware versions that equate to the same thing.
That being said, upgrading ANY major part of a work flow is a risk. Businesses don't just run out and buy the latest version of a particular piece of software just because there's been some update. They'll wait a while, they might implement it on some sort of test system and run a bunch of stability tests, or test whether new features conflict with old practices. If you're making money off 3d printing, or worried about losing your own money because of wasted filament then you should
- Be subscribed to the release candidate channel so you can help weed out bugs if you have an odd or custom setup. Especially if you have an older printer, or a cheap one that may have broken firmware. And have a spare SD card set up JUST for testing that you can swap out with your main version whenever a new update is released.
- Have octoprint run through a bunch of dry runs after upgrading (dry runs run a printer through the motions without actually outputting any filament).
If you're not willing to test out the pre-release versions and help make it better, then you can help improve it by posting logs from failed prints. Detailed logs. Not just "I upgraded and now it doesn't work", that helps absolutely no one.
1 Like
Let me add that screenshots of text are terrible.
1 Like
@PythonAteMyPerl & @tedder42 Thank you both, I couldn't have said it better.
This release was in RC mode for three weeks. All errors reported during that phase I fixed. I didn't get reports on cancelling problems and I didn't see any myself during testing against the hardware and firmware that I have access to. If people are now running into errors I'd say, maybe take that as a hint to participate in RC testing, apparently your specific hardware/firmware combination isn't represented enough yet.
Always expecting others to magically weed out bugs that don't reproduce for them is a recipe for problems like this. Participate, don't just consume.
Finally, something specifically for you, @Will_N. I've been doing this project for over five years now, four of those full time. It has completely taken over my life. I pour everything that I have into it, just hoping that enough in donations and Patreon subscriptions comes back that I can afford to continue to do that. There are definitely other models of work that would be less risky, less complicated, more healthy and less stressful. So the next time you think telling someone "Shame on you" who works their ass off so that others may have an open source tool to control their 3d printers is a good idea, maybe take a moment to think about how entitled you are coming off when doing that and how such words might be affecting the motivation of open source maintainers to keep on maintaining.
5 Likes
I experienced the same problems with cancelling on 1.3.8. After deactivating a few plugins (email notifier, additional buttons, file manager) the problem was gone.
just a wild guess: to me it looks like a performance-problem on my raspberry pi2. I will look further into this.
I have the same issue on 1.3.8! I'm running a Raspberry Pi 3 Model B so performance shouldn't be an issue. Hmm.
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.
1 Like
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.
2 Likes
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.
1 Like
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?