I am using the v4.2.2 board with the silent steeper motors.
Please read:
In short, Marlin bugfix has had a lot of serial issues over the last few days, this is not OctoPrint's problem but instead Marlin's, they are working hard to fix it and from what I can see the issues are mostly solved. You have some options:
- Don't use Marlin bugfix and instead use the stable release
- If you must use Marlin bugfix, understand that it is not for production use and while it is usually stable, it sometimes is not and if you encounter issues report them to the Marlin firmware community so that they can be fixed.
- Just live with the issues and risks that running a development build entails.
I recommend updating your firmware, since it is now outdated.
4 Likes
Brilliant thank you. I will look at using an earlier version. This was must first attempt and building a new firmware for the printer.
2 Likes
Just to let you know I've recompiled using version 2.0.7.2 and the Octoprint connection is stable again and temperatures are all being read and shown
3 Likes
I have had many issues with Marlin Firmware on ANY of my control boards. The biggest issues are related to bad performance of firmware. Usually they show up as printer movement is intermittently interrupted, or communications to the host being interrupted (and then usually resumes). After messing around with many versions of Marlin Firmware I could not get any of them to work properly and perfectly.
I like to support Marlin since they are Open Source, but the firmware is just too buggy and community is usually unable to help with these types of technical issues. Unfortunately at this point I have had to given up on the entire project. I'm sure that some integrators and retailers are able to successfully integrate Marlin in their device and ship working systems to customers, but basically if you are upgrading the firmware yourself and trying to configure it, you will most likely run into firmware issues. I would suggest you to go back to Marlin community and report to them and hope that someone can clean up the code and fix the bugs at some point. Otherwise you got to go through the spaghetti code yourself and figure out what module is making the microcontroller laggy and fix it yourself.
Currently all my printers are running the Repetier Firmware and I have had exactly zero (0) issues with any of the printers. It is not ideal (since it is not Open-Source), but the printers work perfectly and I have not had to do any fiddling around for a long time. This is how firmware should work, just configure it and dial all the right settings in, and once it is in the machine, you basically forget it since it just works and operates the hardware properly.
For what its worth, this was broken between 28th Jan and 1st Feb 2021. There are no known issues outside of this date range.
@CRCinAU - good to see you around here. Assuming you operate the site https://marlin.crc.id.au?
We do have a request/strong suggestion, this has been discussed at length recently, due to the issues mentioned on this post and elsewhere
Our request is to either provide the equivalent of a 'stable build' on that site, currently Marlin 2.0.7.2, or specifically point out that these are development nightly builds, and may not always be stable. It's a great site, and we fully support the idea but when it all goes wrong (as it did a couple days ago) it causes a significant amount of overhead when so many people are running bugfix branches of Marlin, which are frequently changed.
On part of the problem is this:
- The site targets those who do not want to build their own firmware, so they are less inclined to know what problems are, how to report them and how to change to a different build.
- The bugfix branch is usually quite stable, and doesn't have many issues. This seems to have created a false sense of security with what is essentially a development branch.
It has taken quite a lot of effort over the last few days to field these problems, especially when people seem to forget how to read in some replies. I appreciate these prebuilt firmware probably eliminate a lot of the 'build is not working' issues people have with Marlin, so this is a kind of 'compromise' we have thought of.
2 Likes
Its a catch 22. The most popular features just aren't available in stable builds.
As an example, MeatPack - which is a new binary wire level protocol that has an OctoPrint plugin - fixes the issue of low bandwidth to the printer which in turn fixes a ton of print issues won't be in any stable build for months. But its available now in bugfix - and it effectively doubles the throughput of the serial port.
What I normally try to do (which I didn't get to do this time - my bad) is put something in the Known Issues section of the download pages when something becomes known.
That was one of the points that came up - it was a perfect storm, no tagged release for a while, new Meatpack plugin was announced to all users and then the serial issues - but there were still cases of people not realising that these builds were not necessarily going to be stable at all times.
Yep - 100% agreed - which is why the site keeps at least 7 days of prior builds (currently expanding to 14) - as we don't seem to have breakage lasting for that long.
I guess the key part for me is that I need to do an improvement to the site that allows me to set an announcement similar to the announcement in the forum software here that can persist on all pages.
Currently, its a manual editing of the firmware details on each page - and I just didn't get time to do that this time around. Having this in a single place would allow me to be much more efficient in this area.
I would actually say that the majority of cases we have seen the past few days were from people who didn't care about meatpack or new features in general and just needed a build that isn't whatever came stock with their printer (because stock Creality firmware tends to have severe issues).
Please do not underestimate the amount of your users who are completely new in the game and just need a verified stable build to learn on. Nightly builds are not what you want to drop on a newbie, problems like these will happen again.
So please do not only consider an announcement feature (from our experience here, it will not have the desired effect - people don't read) but rather a prominent "stable" category as well. Seven days of builds don't help a user who has absolutely no idea of what they need to click on (and we literally had this discussion on here with a completely frustrated newbie who just wanted to print and didn't care about current development features at least twice just in the past few days).
ETA As also just mentioned in my initial requests in your feature request section:
I agree that the current quite support intense situation came from a perfect storm that coincided with the meatpack release, but the meatpack release wasn't the cause. The cause was a refactoring of the serial communication inside Marlin that broke some stuff temporarily - totally valid for a development branch, not uncommon to happen during development and all the more reason to offer stable builds as well to people are completely out of the depth when it comes to building firmware and/or don't want to flash anew every other day but rather just want something that is tested and works. Most of these people currently don't even know they are running potentially unstable development builds.
3 Likes
@CRCinAU - in a perfect world, being able to point new users to a stable, reliable build would be great. Right now I can't point people to any one source, certainly not to Creality to get it.
Having a freely available "Ender 3 Stable OctoPrint Ready" base* firmware that would allow people to print SD, display and connect OctoPrint would be appreciated. Yeah, I know it doesn't help sales in the front.
- And yes, I understand how Creality has made a mess of things with v1.1.x/4.2.2/4.2.7, 8 vs 32-bit, silent vs not silent boards. Makes me want to force feed Surströmming to the people at Creality that do this.
2 Likes
Hi. A very interisting topic.
Let's give my input on this, especially for the Marlin-users, not only on Creality printers.
I've been using and testing it now for a couple of days on an Anet ET4 as was listed on Anet's site.
And: yes it is "standard" going to the bugfix-version and it works fine when printing from micro-SD, but also connection-problems when trying to print from USB.
Because I have read about this topic here, it is fine.
But: there is something in the name 'bugfix'. Maybe for newbies and non-English people? It seems to be the version that fixes the bugs in 2.0 instead of beeing a 'try it out and report' version.
Why not mention it on the startscreen of the printer. A short warning that 'this is a test-version, please report bugs' would be sufficient to warn a lot of users.
I still love both Octoprint (6 running, most not connected on internet but only internal network) and Marlin!
Its kinnda ironic that the bugfix version of Marlin is the most likely to have bugs.
1 Like
I strongly suggest you request this on the Marlin bugtracker. The only thing we can do from OctoPrint's side, show such a warning in OctoPrint, has already been implemented in the bundled FirmwareCheck plugin for preceisely this reason.
Hi Gina.
Yes I did request it there.
On reading on issues posted here in the logfiles I also keep on reading that the firmware-check has been disabled.
Is it possible to give an extra warning in Octoprint, for example when someone is changing the printersettings while firmware-check is disabled?
I really get the feeling that at the moment this is really the biggest problem since Octoprint is pretty stable and working well!
On some other forums on facebook I have read also that Octoprint was giving problems and these are mostly starting after the firmware-update with Marlin. Users just download some file, put it on sd-card and start the printer thinking that 'all is well now' but instead creating problems for themselves and then blaming octoprint 
I can't stop people from disabling the firmwarecheck, that's their right that I won't take away from them. OctoPrint warns you if you disable it, tells you why it's a bad idea. If you still do it, well, ok. I have already spent way too much time on trying to keep people from shooting themselves in the foot with broken printers and firmware, and having the plugin warn them of the risks if they decide to disable it, I have to draw the line somewhere and that is at constantly nagging them when they disable against all prior warning. There will always be people who find a new exciting way to shoot themselves in the foot after I've closed off one way to do so.
I can only lead people to water, I can't make them drink.
4 Likes
Just a reference point. I'm running what claims to be 2.0.8. (There don't appear to be any differences from 2.0.7, but I'm not doing a compare on every file, so who knows?) I'm watching a temperature tower now. The temperature is a solid line, except at the steps. Then it's a quickly-damped sine wave down to the new temperature. (I found this version on github, when I was looking for CR10 configs. It's running on a BigTreeTech SKR Mini E3 V2.) It helps to set the PID properly, too.
But Octoprint? As soon as I (finally) got it talking to the printer, it's solid. No complaints yet.
I completely agree on explaining the bugfix a little better. I'm a newbie and have just built my printer from almost the ground up. I got a broken Anycubic and literally upgraded everything and added some extras. Anyway in my mind the bugfix version was the version that had the bugs already worked out. I tried using the 2.1xxx bugfix and starting having issues with heating and my X,Y,Z axis was acting all crazy. Plus because of this my homing feature wasn't quite homing correctly lol. Anyway I after three days of confirming my building and wiring skills I thought possibly it was the code. Flashed over a fresh version of the 2.1.2.1 (no bug fix) and it works perfectly now. With all that said...your absolutely right on a newbie thinking bug fix is an actual bug fixed version lol. Now I know.
Yeah, Marlin is a little different in that sense. The bugfix branch is more like their development branch where things are getting updated/merged in, but definitely have the higher risk of stability. I tend to always go with the latest stable version that's been released, and then if there's a problem look to see if it has been solved in bugfix by searching through issues, etc.