Ultimaker2Marlin
Ultimaker2Marlin copied to clipboard
TinkerGnome
16.12.1 unstable
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.
Hi, me too :
with the new firmware (16.12.1) I got the same error "Error Stopped", this happen nearly everytime for long prints (for now, more than 1h), with stock SD card and Octoprint also. So I'll wait a correction because I double check my feeder, nozzle, temp and all in my 3D printer : I don't find any trouble.
I've an Ultimaker 2+ and a Bondtech extruder in 1.75mm (with 1.75mm Matchless Nozzle), I need the new firmware because I have to reverse the E axe to make the Bondtech working in the right way. With the stock extruder and the previous firmware (16.08.2) I never had this error before.
Please @TinkerGnome find what's going. But indeed, thank's for all your time developing this great potential firmware <3
At the moment I have not more information than - something non-reproducible goes wrong in your case - :worried: Let's try to find out, what's different: which slicer? version? in case of Cura- any post-processing scripts? Issues only for specific gcode files? A different behavior, if the printer is re-started before every print?
I use only Simplify3D 3.1.1 (working without any trouble before this new firmware). I always restart the printer before print, and also here because I need to (after the ERROR - STOPPED, we can't do anything at the screen, but in Octoprint it's working). I've upload a zip with 2 gcode with the "ERROR - STOPPED" appear randomly, the config for Simplify3D and the .stl file. Error Stopped.zip I'll try with a new big 3D print file, but this one always bug on the new firmware, so you can try it to see the bug (I hope).
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.
I downgraded back to 16.08.2. And it is rock stable again.
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.
The V16.12.x stops print after round about an hour with errors, that i haven't ever before:
And that's the reason, why I use V16.08.2, untils 16.12.x is working. The stock firmware isn't an alternate for me ;). I love the tinker firmware!
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.
Two weeks ago I just found it like this after a print:
It worked fine next time I printed though, same file and same settings.
Today it suddenly started driving the head into the back of the printer in the middle of printing a robot. It continued pushing the head towards the back of the printer for maybe 5 seconds, then drove the head into the front of the printer for about one second, and then continued printing in the air at that spot. I printed the file once again now though and then it worked fine.
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... None of these problems were ever reproducible with my machine/settings, there has to be a difference, but where...? @gr5 Any encouragement is welcome.
Actually the tinker version does not use more RAM than the standard firmware
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. So it looks like both incidents on my machine happened when (or very close to) moving the Z-axis.
I have attached pictures and the gcode for the failed robot. It is not the same gcode as the one where the printer stopped just after printing, that one is stuck on the SD-card at the moment.
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 The mid-print issue happened with the second extruder at 370 steps/mm, 1.75 mm diameter and 600mA extruder current.
UM2G_41_infill_UltimakerRobot.zip
Beware the SD card. Sometimes seems major problems comes from the SD card. Yesterday I got a failure printing a new project after 4 hours the print stop, the screen goes black, Led shut off and even heating of bed and hot end goes off I thought was the new Firmware installed a day before (16.12.1) so I downgraded to 16.08.2 and restarted the print but... the job ended exactly in the same point and with the same problems (all shut off led,heating,display..) I tried to simulate a resume and the printer stop at the same point 74.70 mm.. I took out the sd card, made a scandisk but no problems comes out even if Scandisk sucks I know so... I made a copy of the entire SD Card and.. surprise! not all file were readable and the file I had in print take long to be copied... so after many tries I copied them all and formatted de SD Card (but not fast format, I made a complete instead) Copied again on the SD card and inserted on UM2, my print comes out perfect without any problems made a second print of 8 hours and NO problems comes out So... take care that the SD card is in good condition before attribute any failure to the firmware Cheers to all and Thank again for this nice Firmware
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) When I tried to read it trough a 7 doors USB HUB it was merely unreadable, so, I connected it to the frontal USB door and it go back to be readable (well with some retry during copy process)
@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... SO thank you again for this Nice Firmware
@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. BTW, i never had any hickups with 16.08.2 or the original Ultimaker Firmware.
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 timelapse: /mnt/syno/Timelapse timelapse_tmp: /mnt/syno/Timelapse/UMtmp uploads: /mnt/syno/Uploads watched: /mnt/syno/Uploads
192.168.200.250:/volume1/OctoPIUploads/Ultimaker on /mnt/syno/Uploads type nfs 192.168.200.250:/volume1/Timelapse on /mnt/syno/Timelapse 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 ... @ieol take a deep breath, be friendly and have a nice weekend ;)
@unixhelden @Turtletrumpet LOL I never write 16.12.1 is flawless, I just point out the way you are all begging for a flawless firmware but just write down information that ARE INCONSISTENT for who is developing it! (UPPERCASE is just for underlining not shouting... I prefer instead of uppercase)
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.