MCU 'mcu' shutdown: Timer too close - OctoEverywhere Triggered

General Discussion
1

Basic Information:

Printer Model: Anycubic Kobra Neo
MCU / Printerboard: TriGorilla V_3.0.6 (and Raspberry Pi Zero 2 W)
klippy.log (6.7 MB)
(Klippy log has had some information during the start of printing and after the fault removed to meet file size requirements for posting here, if any relevant information is missing please let me know)

Describe your issue:

I switched over to Klipper (Mainsail on Raspberry Pi Zero 2 W) a couple of weeks ago and have been having a great time with the firmware, so far everything has been going very smoothly and Iā€™ve been getting much faster and higher quality prints.

With my basic setup all done I decided to add a webcam, mostly for the purposes of remote monitoring. I opted for a Pi Camera (V3), which I managed to get setup and configured with Crowsnest/Mainsail after a bit of messing around. I was considering setting up my own VPN tunnel to handle the webcam, but after seeing the functionality of OctoEverywhere I decided to use that for remote monitoring/control instead.

Now my issue has occurred now four times: the ā€œMCU ā€˜mcuā€™ shutdown: Timer too closeā€ error occurs only occasionally, but always when I am viewing the webcam stream using OctoEverywhere and I am not connected to my home network. Sometimes I can check on the stream 15 or 20 times during a print and there are no issues, but rarely it seems to be overloading the Pi and the print fails. My last print failure happened 7 hours and 39 minutes into a 9 hour print, and although I wasnā€™t looking at the webcam during the crash, no more than 10 minutes after I had left my home network did the crash occur, again leading me to believe this is an Octoprint/webcam overloading issue. (The log included is for this most recent faliure)

My understanding of this issue is that the Pi failed to communicate with the MCU within the designated timeframe required; this could be due to the Pi being overloaded, overheated, undervolted, or the SD card not being able to keep up with data transfer requirements.

  • I have been logging the temperature of my Pi, and it rarely exceeds 51C with the average temp being between 46C and 48C, so I donā€™t believe this to be the cause.
  • I am using a high quality 2.5A 5V power supply, and I doubt that between the Pi Cam and Pi there is enough current draw to significantly drop the voltage.
  • The SD card I am using is a SanDisk Extreme 64Gb, V30 A2 rated card, which I would have thought would not be causing a data transfer bottleneck (I have not tested the performance of this card though)
  • When running some rudimentary tests (using Mainsailā€™s monitoring of CPU usage), I have found that although the Pi is normally only using between 2% and 25% of the CPU, when I connect to the OctoEverywhere client remotely, there can be spikes where the CPU using can hit the 95%+. This is what I personally believe to be the cause of my issue.

The Pi Camera ws calibrated using Crowsnest to use the ā€œcamera-streamerā€ option which uses the Piā€™s GPU to hardware encode the webcam into h.246 format video for streaming rather than the ā€œtraditionalā€ mjpg protocol. The resolution is set quite low at 640x480 and I have the framerate limited to 5 fps. For my last print I switched over to mjpg protocol with the same camera resolution and framerate, however the issue still occurred.

  1. Has anyone else experienced this error with such a high level of intermittence and if so, how did you go about troubleshooting it?
  2. Can anyone gather any important information from my Klippy log which might help identify the cause of the problem?
  3. Does anyone have some general advice on this issue, or suggestions on how I might be able to mitigate it?
2

Hello,

I agree that it is weird that whenever you look at the webcam it is spiking the CPU usage. However webcams are a separate function from Klipper entirely. When you preform a firmware restart, you will notice that the Klipper control panel is unusable, however, the webcam is still streaming. I mean this by saying it is most certainty Octoeverywhere sort of ā€œdistractingā€ Klipper, what makes Klipper fail. Not Octoeverywhere actually just causing the print to fail. It is more of a cause than a direct problem. I hope thatā€™s a good example. :slight_smile:

This thread had a similar issue with Obico: MCU shutdown with BTT CB1 - #16 by Nem0815. There is also the board that you are using, a Pi Zero 2 W. It has about 20% less cpuā€™ness than the Raspberry Pi 3B. Meaning that it could hit 95 percent load when a 3B would only hit 75 or so under the same conditions.

You can also try to update the Crowsnest err. . . file? Anyway, it is described how to do it here: Upgrade from v3 to v4 - Crowsnest This may help as well.

I had a very similar issue where my print would randomly stop. And I always got the same ā€œTimer Too Closeā€ error. Usually a timer too close error means that something has gone wrong with the communication between the mainboard and the klipper host (Raspberry Pi or other). I would try to update the mcu fw as this is what solved it for me.

Hope This Helps,
Blake

Ps: I use Octoeverywhere with no issues whatsoever, so It must be able to be solved.

3

What is the host you use in the your system?

It seems to me that thereā€™s a certain computation threshold that needs to be met for streaming cameras to work in a Klipper system without any problems.

4

It is known that webcams can cause issues with Klipper. Probably due to:

  • Hogging the USB port if not carefully implemented in the cameraā€™s firmware / hardware
  • Overloading the host

Also refer to: Timer too close

5

Hello,

I Use a BTT CB1 which is slightly better (more cpuā€™ness) than a PI 3B as @Sineos said in the thread I linked above. However, in that thread, the person having problems with both Octoeverywhere and Obico also used a CB1. Sooooo. . .

I donā€™t really know if that is the issue. It seems like an issue that only arises in very certain cases. Perhaps it only happens when someone has a high resolution webcam or something like that which pulls too much bandwidth.

Happy Printing,
Blake

6

Reading other forums, it sounds like the CB1 isnā€™t as efficient in terms of itā€™s USB implementation and cannot stream video as well as the rPi. The CB1ā€™s lack of a working DSI port which could be used by a camera puts it a further disadvantage.

I just did a quick check and while rPi 4B modules are available at good prices, the CM4s are hard to get and cost twice as much as the rPi (Grrr).

7

Hello,

I agree, the CM4 is definitely better than the CB1. It it sort of a question if you want to spend the money on the PI or if you want to spend your money on something else. You will have a lot left over if you use the CB1.

Sidenote: I Use the CB1 for my CR-10 V2 and it works great. The USB camera works amazing g. Personally I would never hook up a DSI camera as I am not a fan of long, easy to break ribbon cables. I would only use that port for Klipperscreen

I had some issues with the USB camera on the CB1, however, the solution was to update crowsnest to v4 and that did the trick. It works great now. It also has a nice stable stream.

My point being that for the price, not being able to use a DSI camera isnā€™t an issue for me as Iā€™ll never use it anyway.

Happy Printing,
Blake

1 Like