Random Duet resets

Hi all,

Been lurking for a while with no issues that I couldn't solve with the aid of some googling (mostly landing me here anyway). Today, however, I'm having some strange issues with the Duet on my O1 randomly resetting mid-print. Twice so far - once about 2 hours into a large print, and once 3 hours into a repeat of that print with about 25 layers to go (argh!). The printer simply stops, the web interface times out (ajax error or some such) and then it comes back showing that the axes are not homed and the bed/hot end are inactive. Looks like someone has had a similar issue before, so I ran the M112 command someone suggested and got this:

Last reset 00:50:32 ago, cause: watchdog
Last software reset code & available RAM: 0x0003, 10916
Spinning module during software reset: GCodes
Last message before reset: q+{үozError status: 0

What could cause this? I haven't turned on/off any power supplies, any lightswitches (not that they've affected the printer before), or moved any new equipment anywhere near the printer, so as far as I can see nothing has changed physically. Could something be overheating on the Duet? some of my stepper motor currents are 1000mA but this has never caused a problem before.

I did upgrade to dc42's 1.09p-alpha last night from 0.78. I've made all the necessary tool numbering changes, added the pause/resume.g and rebuilt my config.g using the example one in dc42's repo.

The other noteworthy thing is that I was testing a 24V E3D v6 hot end with a 24V power supply over the last few days (I canned it last night because I just couldn't get rid of the stringing no matter how much retraction/coast I gave it, plus I think the temp sensor was off as the layer adhesion was very poor). This afternoon I reconfigured the heated bed contacts (its 12 and 24V compatible) and swapped back to the stock hot end, and removed the line in my config.g for the Semitec thermistor on the E3D end. I reconnected the ATX power supply and printed a small clip as a test piece with no issues.

I put the first reset down to bad luck, a cosmic ray perhaps! The second reset has unfortunately got me a little more worried. I did have a drill battery charger connected to the same extension lead as the printer, but there's no battery in it currently so it was sitting idle. I have removed it anyway just in case it was pulling the ATX power supply down momentarily for some reason. The only other thing that comes to mind is that the ATX supply could be on its way out, perhaps it's time I replaced it with a proper 12V supply? I did see if I could adjust the voltage on my 24V supply down far enough but it only goes as low as 19.5V.

I'll try rolling back to 1.09o tomorrow in case its a firmware issue. Any suggestions greatly appreciated

EDIT: just remembered, I also tightened down the power cable between the ATX breakout board and the Duet after the first reset, it's plenty tight so shouldn't be the issue.

Edited 1 time(s). Last edit at 01/12/2016 07:54PM by static65.

i would guess its an software issue, because the Printer got reset by the watchdog - basically that is a component on the CPU which regulary checks if it still reacts to input and if not (possibly because it hangs) resets the Machine

what did you print?

That's the first watchdog reset I have seen in many months. Please roll back to firmware 1.09m because there are issues in 1.09o that cause problems for some users, especially but not exclusively when both the web interface and USB are connected. I have withdrawn 1.09o.

Edited 1 time(s). Last edit at 01/13/2016 08:59AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Yes, a watchdog timeout is an indication that the firmware has crashed, and while that can be caused by bad hardware (typically bad RAM), or by induced noise in the electronics, it is far more likely to be the result of a firmware bug when it occurs on a proven hardware design.

When it is very infrequent, seemingly random and not reproducible, it is possibly caused by an interrupt changing a memory value in between lines of code that assume that the value will remain static, which can be very difficult to debug because the code in question looks perfectly sound, and of course usually works flawlessly unless a particular interrupt happens to occur during that very short critical time period. And while you can usually assume that a new bug was introduced by the last change made to the code, a bug of that nature may not be directly related to the change, but a bug that has always been present in an interrupt routine is manifesting itself far more frequently due to the change having increased the frequency or length of the critical time period.

Dave

Thanks all. I've uploaded the 1.09m firmware and set the print going going again. Now we play the waiting game.

If there's any info I can provide to help track down the firmware issue (assuming that is the case) then I'll be happy to do so.