print.job stops randomly even with sd card printing and logs don't help much
first off, despite difficulties, i love the FW. especially the color mixing features. if you get this problem solved, i'll send in another donation, promise.
my problem:
print jobs sometimes just stop completely at random times. sometimes i get a finished part, but usually it will stop somewhere within 20 minutes. This is on a workhorse printer that ran marlin perfectly....
1. i just got latest FW working, but this printer has hundreds of hrs. of running perfectly with marlin FW.
2. just to re-test the hardware, i re flashed it with marlin today and printed the exact same print files, and no problems at all.
3. i have tried printing over usb, printing with sd card only, and printing w/sd card and debugging log on.
4. the actual printing has no visible issues, no pauses or abnormal behavior.
after the stoppage, here is what the logs say:
1. no particular g code command preceded the stoppage, not a temp update, nor tool change
2. there were no errors, warnings at all in the log, not even any comm. resends
3. the commands recieved the ack perfectly, and there were no pauses or delays or large buffer under runs
4. according to log, at the stopping point, it says "reset was detected" probably the watchdog at work
other info you may need:
printer:: delta. with. diamond hot end
controller: mega2560 w/ RAMPS 1.4 and step expander ( for 3rd extruder)
display: discount reprap 4 line text only
software: repetier host,
slicer: slic3r or cura w/no difference between them
color use: stoppage happens using one extruder, or all w/ no difference
probing: no difference whether probing was done or not.
If i do say so myself, this is a really bad a$$ machine and its stupid that just a firmware change can make it useless. Marlin works, but it can't handle multiple extruders, so here i am. asking for help.
thanks in advanceo
my problem:
print jobs sometimes just stop completely at random times. sometimes i get a finished part, but usually it will stop somewhere within 20 minutes. This is on a workhorse printer that ran marlin perfectly....
1. i just got latest FW working, but this printer has hundreds of hrs. of running perfectly with marlin FW.
2. just to re-test the hardware, i re flashed it with marlin today and printed the exact same print files, and no problems at all.
3. i have tried printing over usb, printing with sd card only, and printing w/sd card and debugging log on.
4. the actual printing has no visible issues, no pauses or abnormal behavior.
after the stoppage, here is what the logs say:
1. no particular g code command preceded the stoppage, not a temp update, nor tool change
2. there were no errors, warnings at all in the log, not even any comm. resends
3. the commands recieved the ack perfectly, and there were no pauses or delays or large buffer under runs
4. according to log, at the stopping point, it says "reset was detected" probably the watchdog at work
other info you may need:
printer:: delta. with. diamond hot end
controller: mega2560 w/ RAMPS 1.4 and step expander ( for 3rd extruder)
display: discount reprap 4 line text only
software: repetier host,
slicer: slic3r or cura w/no difference between them
color use: stoppage happens using one extruder, or all w/ no difference
probing: no difference whether probing was done or not.
If i do say so myself, this is a really bad a$$ machine and its stupid that just a firmware change can make it useless. Marlin works, but it can't handle multiple extruders, so here i am. asking for help.
thanks in advanceo
Comments
to see response after watchdog reset. I'm quite sure that would give a different restart reason. So for now I would assume it really did a reset.The question is why and where does it reset.
First i would try printing in dry run to see if it is extruder control that causes reset. In that case question would be if serial print then also resets after a while.
Unfortunately errors that only happen sometimes after hours are incredible hard to find and debug. So first step is always to find the part of software that is responsible and then to find the conditions to trigger the error. As soon as you are down to a small test it is possible to find the problem. Or it needs to be run from a hardware debugger but that means it need to know what will cause a reset.