Running shaper_calibrate causes MCU to shutdown.

[johncotten]

running shaper_calibrate in the console runs for a period of time through various frequencies, my last run was to 9hz before Klipper shutdown with the following error:

Klipper reports: SHUTDOWN

MCU 'mcu' shutdown: Timer too close This often indicates the host computer is overloaded. Check for other processes consuming excessive CPU time, high swap usage, disk errors, overheating, unstable voltage, or similar system problems on the host computer. Once the underlying issue is corrected, use the "FIRMWARE_RESTART" command to reset the firmware, reload the config, and restart the host software. Printer is shutdown

[xblax]

Hm, I did run this multiple times without issues already. Did this happen multiple times for you or just once?

That "MCU 'mcu' shutdown: Timer too close" could happen when the system is overloaded, but afaik it can also happen sporadically in Klipper to more or less unknown reasons - might as well be a bug in Klipper.

Have you had anything running in background on the Linux console?

[johncotten]

Weird, it did it twice in a row. But after doing a full power down and back up, this ran fine. Nothing was running in the console, in fact I wasn't even connected to the Linux side of things.

[Tiwatz]

I had the same error message yesterday but while in middle of a print. Going to do some more testing today.

[consp]

I had the same error message yesterday but while in middle of a print. Going to do some more testing today.

Did it slow down a lot before stopping?

[johncotten]

Maybe we should be running Top or something to monitor the Linux processes. Might have something running away...

[xblax]

I had this error once during printing as well (was a 9h print, and happened mid print). See https://github.com/xblax/flashforge_adm5_klipper_mod/discussions/19#discussioncomment-8666934

In my case I think that was due do excessive M106 commands created by the Slicer (Prusa Slicer). Klipper seems to not handle these very well. After I changed settings, it didn't occur again for me.

[Tiwatz]

I tried the same print twice today and it stops just after starting the second layer both times. Same thing yesterday. No execessive M106 commands in g-code. Sliced in Orca. Going to try to print the same file with stock firmware now.

[xblax]

Yes, probably a good idea. Remember that it needs other start/end GCode, but other Slicer settings should be kept the same. Are you running the KlipperScreen variant of the mod or the "lite" variant?

[Tiwatz]

Yes, probably a good idea. Remember that it needs other start/end GCode, but other Slicer settings should be kept the same. Are you running the KlipperScreen variant of the mod or the "lite" variant?

I run without the KlipperScreen. Forgot to mention, no slowing down att all before the stop. I was watching the cpu/mem usage in Mainsail and memory was around 70% (it normally is) but the cpu usage was rising and was at 67% when it stopped.

[consp]

but the cpu usage was rising and was at 67% when it stopped.

sounds like some process is eating the cpu, was it klipper?

[Tiwatz]

but the cpu usage was rising and was at 67% when it stopped.

sounds like some process is eating the cpu, was it klipper?

I'm not sure how to determine what process is using all the cpu power.

Running the same g-code on stock firmware right now and it has been going for a couple of hours. Just modified the start and end code so everthing else is the same.

[consp]

I'm not sure how to determine what process is using all the cpu power.

Open a ssh connection to the machine, run top. It auto sorts by cpu usage.

[Tiwatz]

Yes it was Klipper that was eating the cpu. I feel really stupid now but I suddenly remebered something. I had changed the [gcode_arcs] resolution: 1.0 setting to 0.1. Changed it back to 1.0 and now everything works fine.

[mallison01]

I had this happen the first time i tried to run the shaper, i did have the mainsail webgui open, rebooted and was able to run it.

fresh install with AD5M and FF Factory camera

[consp]

Most likely numpy eating all the free memory available causing it to fail. It happens during the calculation phase and monitoring it I can see it eating all free memory and running out before the swap is used. Should be investigated (see #105 forgot about this one).

Running it twice does not result in the same error.

[thhdragon]

when i ran it, it started testing the Y frequencies before it was done calculating the X results. when i ran shaper_calibrate axis=x and shaper_calibrate axis=y separately and let X finish calculating first it worked fine

[consp]

it started testing the Y frequencies before it was done calculating the X results

That's a very useful observation! That will likely result in a timeout.