16.12.1 unstable #56
Comments
|
Hi, me too : |
|
At the moment I have not more information than - something non-reproducible goes wrong in your case - 😟 |
|
I use only Simplify3D 3.1.1 (working without any trouble before this new firmware). |
|
I also use S3D 3.1.1. I did not try Cura. I downgraded back to 16.08.2. And it is rock stable again. |
|
Tried both, Cura 2.3.1 and 2.4.Beta (and Beta2). Prints with Octoprint via Serial or SD Card the same behavior. Sometimes the print passes somestimes this error appears, happend with the same gcode, first print success, next try error. Stock Ultimaker 2+ nothing special. |
That's really odd, i have reports that are the exact opposite... Some users had weird issues with 16.08 and are happy again with 16.12... I have nothing changed that could be (directly) related to this. There's no starting point.... |
|
I should point out that I have still other issues with 16.08.2 like the previously reported bugs with the UI like going back to the menu during print and hang in the UI. But when it comes to the actual print it completes successfully and never fails. |
|
There are some small problems with 16.08.2, but the prints works and don't stops by error. |
|
tinkergnome maybe change the path planner lookahead from 16 points to 8 points to see if that helps? Just for information gathering? |
|
I also had issues (with the Tinker-MarlinUltimaker2go-HBK-dual-16.12.1) on the UM2Go om two occasions. Today it suddenly started driving the head into the back of the printer in the middle of printing a robot. I am thinking if it is some scheduling issue that overloads the PSU, or something like what gr5 mentions? It might be that my case is related to EMI though, since the electrical connection for my printer lacks an earth wire at the moment. (Which can be felt if touching metal parts of the printer) |
|
Maybe I'll reduce path planner by 2X and send out copies to whomever wants. Just to collect some info. Who will test it and what version of hardware do you need me to build? |
|
Actually the tinker version does not use more RAM than the standard firmware, but more program memory ofc. I agree, that there is probably a buffer (or integer) overflow somewhere, but I'm afraid, that it's not in an obvious place... |
Maybe it only uses more memory on the stack then. I mean you must have at least one variable somewhere that isn't in the original marlin, right? These strange crashes make me think "stack" as those errors can be very intermittent and very strange. |
|
It has to be something like writing to the wrong ram position, as none of the stop calls that would produce the error-stopped without further information, so it can not be related to a normal printing operation when older firmwares do not trigger anything - ok besides a very erratic safety jumper... (unlikely?) For what it's worth I built a version for me that is printing the amount of free memory to the unused second USART interface - maybe it runs out of memory after all? Otherwise happy hunting for bad pointers :| |
|
I just realized one thing when looking at the failed print: It appears like it failed after completing a layer. I have attached pictures and the gcode for the failed robot. Both robots have printed successfully when trying again with identical settings, the first one probably printed fine 30 times or so. Another thing I realized: If it would make any sense, it is possible that my printer behaved strange for about the time of one layer, banging the head into the back and then the front, then starting to move normally again when it reached next layer. (Just based on the duration of the problem). The first error, when the printer stopped after finishing the robot, was with default settings on the primary extruder by the way |
|
Beware the SD card. Sometimes seems major problems comes from the SD card. |
|
I can second the fact that a faulty SD card can lead to arbitrary head movements - but those errors would not result in a "error - stopped" message on the display? |
|
And this error also happens when printing via OctoPrint (USB), so this is not SD Card related. |
|
I print only with octoprint and get the 'stop' error, too. Is it a good idea to make a factory reset, after flashed the V16.12.1? The older version i used is V16.08.2. |
|
@derbroti a faulty or better a semi faulty or we should talk about a CRC RANDOM faulty SD card can lead at any kind of problem even a corruption of other data depending on the system with which it will interact (software, hardware combinations) it's not a simple problem when you got Random CRC errors (as the case of my SD card) @unixhelden @Turtletrumpet Turtletrumpet indirectly gave the answer to you as the Octoprint have REFRESHABLE memory inside, this mean the same, (alike, similar) chip of a SD card... But take in account that SD card born to be erasable a number of time that is usually Bigger compared to a Flash Memory chip used for firmware (you can find more info on the datasheet of the flashmemory chip manufacturer) BY THE WAY: I believe that TinkerGnome got really a lot of patience reading so many comments... |
|
@andersolsson I see your comment now (posted 10 days ago) This is right what happened to my UM2 (the print head above the printing piece, all shut off except the head fan that it is not controlled by sofware (as it goes ON when you power the UM) and I am almost sure that it is an SD card problem. I suggest to you to copy all your files on a computer and format your SD card (don't make a fast format as it doesn't correct the problem) |
|
@ieol nope, my octoprint stores and loads gcode and timelapses to and from a nfs share. With 16.12.1 i get spontanous Errors like the one described above. Print stops, Nozzle in the Middle of the Print and Display states. "Error - Stopped". So i would rule out SD Card Problems. Same Gcode File runs perfect and the next Print is an Error. pi@umocto:~/.octoprint $ grep 'mnt' config.yaml 192.168.200.250:/volume1/OctoPIUploads/Ultimaker on /mnt/syno/Uploads type nfs I have 3 Octoprint Servers for 3 different Printers, all setup the same with this nfs share. And only this Firmware brings errors. If someone would provide a debug version of that firmware, i could make some tests with serial logging enabled. |
|
@unixhelden - I have the build environment setup the same way UM does and tinkerGnome does. I'd be happy to build a version for you but I don't know about this "debug version". Is there a flag in configuration.h (sorry too lazy to check at t he moment). If there is such a flag and then tell me about it and tell me what configuration I should build for (there's a dozen or so builds) and I'll make you one. |
|
@unixhelden so let resume you use an even more susceptible connection mode for transferring gcode? Really! seems right the correct way to test something new! And see if it is stable and error free... gosh! |
|
The fact that it works on 3 printers for years and "suddenly" stops working when simply upgrading the firmware is good enough for me. It could be a coincidence with something else that happened but considering all the complaints I think there is a bug in this version of the code. Probably not Tinker's bug - probably some bug that is only now showing up. Maybe the interrupt service routine doesn't finish in time. Maybe there is a stack error or initialization error or... something. |
|
@gr5 there are no fact or the problem would already be solved... if you think that change in firmware is a simply upgrade you already write all... have a nice day |
|
@ieol please. calm down. i will summarize that for you: Multiple People experience the same issue when using 16.12.1. Multiple People say this error occurs with different slicers ( i personally tried s3d and cura (2.3 and 2.4beta1-2)). All of them Report when they switch back to the older firmware this error does simply not happen at all. With the same hardware, the same slicer, the same sd card and or serial delivery via Octoprint. All of them say: We can print the same Gcode 2 Times, the first time it's ok, the second time the same gcode on the same sd-card or the same pipeline brings this error up. Next i tell you from my point there is no sd card at all involved. I use this setup on THREE Printers without any issues, i run prints for my hub which are 36-72 hours long without any hickup or fault unless i run 16.12.1 on my um2+. @gr5 i'll come back to you. I have to run several orders till thursday on my um but i think there is a debug option allready in marlin, i will look into it. |
|
Clear & short: There is a problem in 16.12.1. In that Version the pint stops without useable error message. Nevertheless i love the Tinker"ware" ;). I hope the error will be found. I don't know, what i could do, to find the error ... |
|
@unixhelden @Turtletrumpet LOL oh @Turtletrumpet have a nice weekend too ;) |
|
@ieol please start first and write consistent messages, who helps to find the error. At the moment you keep writing, that our feedbacks ARE INCONSISTENT. My opinion: wrong way to solve problems. |
|
I do not speak English sorry ((( |
|
@gr5 Stephan gets this error message after several hours of printing. |
|
Well that sucks. So it seems like the bug is still there in version 17.02. |
|
Yes the bug is still there in 17.02. I also mentioned that there is a ~5mm blob of material where the print stopped, so it seems that the x- and y- movement stopped but it was still extruding for some seconds. After that the printhead had moved into it´s zero-axis corner. |
|
@gr5 Does the Tinker V16.01 works with octoprint? |
|
Ok, after 5 days nonstop printing with Marlin 2.4 no problems at all. I finished 4 long prints and the 5th will be finished in the morning. So I have no hardwareproblem with my motherboard! |
|
16.01 should be fine. That's the most recent version that I trust to be stable. |
|
Ok, but to move forward with this issue: Which Version should I test? Maybe we have to go back to the last stable version an make a new release based on the last stable version? I can print every day always the same big object to test a new release. |
|
Unfortunately a year's worth of changes have been added since the last stable version. It would really suck to have to do that. Instead it would be best if we had a testable theory as to the cause. One theory was that it had to do with power distribution code. That code was improved in version 17.02 only. Another theory is that the machine is running out of stack space memory. That is difficult to test. I think there is a way to blast debug info out the USB port including free memory. We could see if that gets very low during a long print. I'm not sure how to do all that. Also it should be able to simulate a long print in codeblocks and dump free memory to a log file there also. Another theory is that there is some timing issue (e.g. interrupt service routine is entered a second time before it completes the first time?). Or maybe a null pointer bug. I think stack overflow is most likely. |
AFAIK all interrupts are disabled while an ISR is executed. I think this reason can be ruled out. |
|
Yeah I agree. Stupid idea. But if it runs too much the planner has no time to run. Someone should try going here: |
|
Anecdotally but I built up a clone and had problems where the head would roam around randomly during a print then get a stopped error. I ended up putting aluminum ducting tape around the lcd ribbons, tape on the outside of the lcd housing, and a ferrite around the lcd ribbons (I also went crazy and put ferrites on all the motors) ... and the problem went away. I also had a similar issue with a makergear m2 that would do this when using an external lcd / sd card. The wanhao duplicator 6, a blatant clone of the ultimaker also has aluminum ducting tape around the lcd cables stock, maybe this is why. It's cheap to try. |
|
Very interesting. I will try this tomorrow. Thanks! |
|
This might be a solution for some... and I can second that: a bad connection (interference, too long cable, loose connection, etc.) can lead to thos erratic problems but for example SKlasen reported that the problems went away with the original and old firmware - and that is too much of a coincidence that precisely at that time the possible bad connection to the SD card "fixed" itself |
|
If you are getting sporadic movements where the head suddenly moves to the front or left side of the print area and then continues where it left off. Or if you get "print out of area" or something like that. Then it's probably a hardware issue reading the SD card. I had a problem with dust and a hair on mine. But if the printer is crashing and/or locking up the display then it might be software. They may seem like similar symptoms but they are quite different. |
|
Printed another week with OE Firmware and no issue at all. So it is 100% firmware related issue. |
|
When printing, in geek mode, it shows you all kinds of things like temperatures, z position, feedrate, flow rate, time left and so on. In "normal" mode it only shows you I believe time left. I have this (desperate?) theory that geek mode is causing the crashes somehow. |
|
I printed 5 more days my long prints with OE firmware without any issue. From now on I will try 17.02 again and disable Geek mode! |
|
MORE DATA! I have a customer, I think he is "limitedRacing" maybe on the forums. He has the medusa feeder and 16.01 and had a screen freezes but it would finish printing. He couldn't go into tune menu but not a disaster. I suggested he turn off "geek mode" and he has printed 30 hours since then without any screen freezes (tune menu still works). I also had a screen freeze recently on 16.01 (the first I've noticed) and have been doing non geek mode. But it's rare that I pay that much attention the screen after the first few layers are done. |
|
I just realized today that the first UM2 that I bought has been running on 15.12 for quite some time now and I never had any issues on that one. I always used geekmode on it and have been printing similar models compared to the one that made my UM2Go freeze with 16.12.1. So if 16.01 has screen freezing issues, maybe one can find a clue in the changes made when 15.12 became 16.01 ? |
|
I've been using 16.01 for a year and only noticed screen freezing once. I think maybe it's not noticeable unless you actually look at the screen. The problems with 16.01 seem pretty minor compared to later versions which can crash many hours into a long print. Is it possible you had a few screen freezes over the last 18 months Anders but just didn't notice? |
|
Is 16.01 compatible with the + models? (UM2+ in my case) |
|
Sorry for my late reply gr5. |
|
@musyne 16.01 rotates the extruder the wrong way. Personally I would probably install 16.01 for UM2 and then swap two pins on the extruder stepper. But I've done that a few times and may be too scary if you've never swapped pins before. Takes 10 seconds for an expert. Also you have to double steps/mm but with tinkerware that's trivial - it's a menu item. |
|
@gr5 yeah I've touched the board before but I'd rather not switch the pins for a temporary solution. Thanks for the advice I'll try another release and keep you posted if it works. |
|
@gr5 Do you think you can add support for the + to 16.01 branch since it seems to be the last stable version? |
|
Any updates here? I´m using OE firmware for almost half a year now but want to install tinker again. |
|
A few years later using Marlin, I´m testing 16.01 again with long prints. |
Prints seem to fail a lot more often with this than 16.08.2. The error message just says Error Stopped go to ultimaker... Not very descriptive, so I am not sure what is causing this. I am on a UM2E+
Now it also hanged while trying to read the list of files from the sd-card.
The text was updated successfully, but these errors were encountered: