Duet Maestro Resetting and Stopping print, HELP! (Thanks!)

dc42

Unfortunately the hard fault reported had the "imprecise" flag set, which means the stack data was not valid. This makes the fault hard to diagnose.

So please can you send me further M122 reports. If this type of fault repeats, then I will make a special firmware build that will make it easier to track down.

As you are the only user reporting this problem, it could be that you are using the Duet in an unusual way. Please tell me:

Are you printing the GCode file from the built-in SD card? If not, are you printing via USB? or external SD card? or some other way?
What type of display (if any) is connected to the Duet? If it is a PanelDue, what M575 P1 line do you have in config.g?
What sort of printer is it?
What power supply does it have?

bluecrayfish

@dc42 said in Duet Maestro Resetting and Stopping print, HELP! (Thanks!):

Thanks for your reports.

The last M122 report cotains this:

Last software reset at 1970-01-01 00:00, reason: deliberate Hard fault

The "deliberate" means that RRF executed a special M122 command to test the crash handler. These commands have P parameters in the range P1001 to P1006. Have you any idea how that command could have got sent to the Duet?

Your earlier report was a not-deliberate hard fault. I will look into it now. Meanwhile, if you get any more instances, please capture and post the M122 report again.

I do not have any idea how that command was sent. Each time, the printer is printing normally, until about 1 hour in, when it just stops. I've restarted the print many times, five at least, and it always stops about an hour in but at a random place.

Thanks for helping! I really have no idea what to do to make this work again.

bluecrayfish

@dc42 said in Duet Maestro Resetting and Stopping print, HELP! (Thanks!):

Unfortunately the hard fault reported had the "imprecise" flag set, which means the stack data was not valid. This makes the fault hard to diagnose.

So please can you send me further M122 reports. If this type of fault repeats, then I will make a special firmware build that will make it easier to track down.

I will keep running this print and sending the M122

As you are the only user reporting this problem, it could be that you are using the Duet in an unusual way. Please tell me:

Are you printing the GCode file from the built-in SD card? If not, are you printing via USB? or external SD card? or some other way?

From the built-in SD, in the normal way as far as I am aware

What type of display (if any) is connected to the Duet? If it is a PanelDue, what M575 P1 line do you have in config.g?

I have the stock CR-10s lcd display plugged in and working, as it has been since I installed this Duet several months ago.

What sort of printer is it?

It is a Creality CR-10s, with a Bondtech direct drive replacement, and the Duet Maestro running it. It has a 120v bed heater run with a SSR.

What power supply does it have?

Meanwell LPV 150 12

This may be a red herring, but this is how this started:

-I drew a large part in Fusion 360
-I split the part into 2 parts for printing
-The first part was only 1.5 inches in height and printed fine.
-The second was nearly (397 of 400mm) too tall for the print volume, but it sliced.

When I tried printing this, it seemed to work, but there was an anomaly: On the print status page, where it normally shows "line x of 23334456" nothing was shown, there was no total or tally of layers. Aso, in the time-prediction windows below, some were blank since it had no layer information.

When the print repeatedly failed, I went back to F360 and split the large part into two parts. I tried slicing the smaller parts, and this time when loading the STL into DWC, all the layer and other info was shown correctly.

However, this print still failed in the same way, resetting for no apparent reason. Like I said, this could be totally unrelated, but ever since something loaded with no layer information, I've been having this problem.

I'm running the print again now, history indicates I will have a M122 for you in about an hour.

Thank you!

bluecrayfish

Hello,

The print quit less than an hour in- Here is the report text file:

console (2).txt

I hope this helps "us" narrow it down! Thank you!

bluecrayfish

I tried a new print, something made in Fusion 360 but not the same file, and in fact I've printed this file successfully before.

It still stopped about an our in.

Here is the M122 report:

console (3).txt

I'm trying now with a file that was not made with F360 just to see if that somehow works.

Thanks for looking at this.

dc42

Thanks! For the future, it will help if you can save the M122 output in a way that preserves the line endings.

The distinct crash reports I can see in console3.txt are:

Last software reset at 2020-06-11 16:06, reason: Hard fault, spinning module Platform, available RAM 16920 bytes (slot 1)
Software reset code 0x0030 HFSR 0x40000000 CFSR 0x00010000 ICSR 0x04427803 BFAR 0xe000ed38 SP 0x20000fcc Task 0x5754454e
Stack: 00405851 00405e74 41000000 2000849c a5a5a501 a5a5a5a5 20008498 00000001 20001000 00000000 a5a5a5a5 a5a5a5a5 00405851 2000849c e000ed01 20001c0c a5a5a5a5 a5a5a5a5 00000001 200083a0 6e8622ab 00000000 004094a5

Last software reset at 2020-06-11 11:14, reason: Hard fault, spinning module Platform, available RAM 16920 bytes (slot 0)
Software reset code 0x0030 HFSR 0x40000000 CFSR 0x00020000 ICSR 0x04427803 BFAR 0xe000ed38 SP 0x20000fc4 Task 0x5754454e
Stack: 004042fd 20008600 00000200 20008600 00405e85 2000849c a5a5a501 a5a5a5a5 20008498 00000001 20001000 00000000 a5a5a5a5 a5a5a5a5 00405845 2000849c e000ed01 20001c0c a5a5a5a5 a5a5a5a5 00000001 200083a0 498825e8

Last software reset at 1970-01-01 00:00, reason: deliberate Hard fault, spinning module Platform, available RAM 16760 bytes (slot 3)
Software reset code 0xc030 HFSR 0x40000000 CFSR 0x00008200 ICSR 0x0400f003 BFAR 0xa24a395b SP 0x2001ff54 Task 0x88004556
Stack: 0041793f 00417952 a1000027 20001c0c 00000004 0044350d 20016810 20016810 40010000 200013e0 200006fc 20000684 004180c9 b9e9d8fc 00000000 00000004 0041a1f9 b9e9d8fc 01904a01 00000002 00000004 200013e4 40010000

Last software reset at 2020-06-09 02:49, reason: Hard fault, spinning module FilamentSensors, available RAM 16920 bytes (slot 1)
Software reset code 0x003d HFSR 0x40000000 CFSR 0x00000400 ICSR 0x04427803 BFAR 0xe000ed38 SP 0x20003b1c Task 0x4e49414d
Stack: 0044c7fd 00434750 01000000 00000001 00000000 00000000 a5a5a5a5 a5a5a5a5 a5a5a5a5 20001b78 00423acd 20010b08 20001c0c 00000000 a5a5a5a5 dee9ada8 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 0043fe23 20001c34 40010001

The last two are the ones you reported previously.

These are all different. That suggests strongly that the problem is either a faulty microcontroller (rare), or the microcontroller is overheating (which I would have thought unlikely, and the readings in the M122 report are good), or a transient or static discharge is causing the problem. So I would like to explore the possibility of a transient or static discharge causing the problem. Here are some suggestions:

Make sure that you don't have a USB cable connected to the Maestro (of if you do, see the wiki page on USB ground loops)
Make sure that all of the following are grounded: bed plate (very important when using an AC mains bed heater), negative output of the PSU, all stepper motor bodies (possibly through the printer metalwork, but if you are relying on this, check using a multuimeter)
Preferably, ground the hot end metalwork too

Just in case it is related to MCU heating, please keep an eye on the MCU temperature reading during your next print.

bluecrayfish

@dc42 said in Duet Maestro Resetting and Stopping print, HELP! (Thanks!):

Thanks! For the future, it will help if you can save the M122 output in a way that preserves the line endings.

I saved it as CSV this time, hopefully that works as it is the only other option I can see:

console.csv

This report will have several failures and successes. For example, I drew a 3" diameter 6" tall cylinder in Sketchup, and one in F360. and sliced both in vase mode with identical setttings. The SU one completed, the F360 has failed twice so far. I was advised to make a perfectly identical model, i.e. make a 24 sided figure in F360 to exactly match Sketchup's 24 side circles, so I did.

I printed that model, and it also failed. Always the same thing, spinning module something or other and reset.

These are all different. That suggests strongly that the problem is either a faulty microcontroller (rare), or the microcontroller is overheating (which I would have thought unlikely, and the readings in the M122 report are good), or a transient or static discharge is causing the problem. So I would like to explore the possibility of a transient or static discharge causing the problem. Here are some suggestions:

Make sure that you don't have a USB cable connected to the Maestro (of if you do, see the wiki page on USB ground loops)

I disconnected the USB first thing, so all the subsequent prints (and failures) have been without it.

Make sure that all of the following are grounded: bed plate (very important when using an AC mains bed heater), negative output of the PSU, all stepper motor bodies (possibly through the printer metalwork, but if you are relying on this, check using a multuimeter)

Preferably, ground the hot end metalwork too

I made a harness just now and grounded all of these things, checked with my meter. The 24 side F360 cylinder is printing again now, we willl see if it succeeds fuinally.

Just in case it is related to MCU heating, please keep an eye on the MCU temperature reading during your next print.

I have watched it, I have never seen it go above about 32.4

I will keep making prints and collect more data.

bluecrayfish

UPDATE:

Possible Solution-

After grounding the items you specified, the next print of the large saw adapter part has reached 78% and has been printing all night, 10 hours at this point.

Hate to speak too soon, but I see no reason that it would fail at this point, the mystery errors always happened relatively soon in the print.

I will keep printing and remove the grounds one by one until I find the one that matters, which I suspect is the grounding of the power supply itself.

The Meanwell LPV-150-12 PSU I'm using actually does not have a ground connector, it is double insulated and meant to be installed inline. It has been suggested to me that this is the source of the problem. It has no ground connector, but connecting the PSU negative output to the power cord ground conductor may have done the trick.

Thanks, DC42 for sticking with me through this troubleshooting. I'll report back when I track down exactly what was causing this, initial indications are that grounding was in fact the issue.

Thanks again!

bluecrayfish

Further update:

The print above finished, and I was able to print another part of the same assembly from F360.

As far as I can tell, grounding the negative output of the PSU fixed the issue.

I will report back to this thread if the software reset occurs again, but if I never do- assume the problem is fixed.

Thanks again, Folks!

dc42

@bluecrayfish, I'm glad we seem to have fond a solution. Please keep us informed.