TTC after webcam install

[3dcase]

Basic Information:

Printer Model: Voron V2.4
MCU / Printerboard:Spider V1.1
Host / SBC: Raspberry pi4b V1.1
klippy.log
klippy.zip (1.2 MB)

Describe your issue:

Printer was fine till I installed a webcam yesterday to monitor the print when I am away and to let an AI look at it to detect issues when I am absent.
Started ok and connected with octoeverywhere fine as well.
Shared the video link with my brother in the Netherlands just for fun, also went ok. This btw is not something that klipper has to worry about, it is done by octoeverywhere.

So I went to bed and woke up with an error message that MCU had shutdown due to a TTC.
I tried reading the klippy.log but I cannot determine if anything happened that was out of the ordinairy. Probably because I do not yet know what would be out of the ordinairy.
There were no reported temperature errors, both MCU and host temps were fine.
Print was perfect till the moment of the shutdown.
SYSLOAD does not look too high either, so what could have caused this?
Webcam is a logitech brio100
Set at 1080p/30fps (1920x1080 pixels) but it could also handle 720p/30fps (1280x720 pixels).
The webcam is only 2Mp and according to spec it needs:
(2GB RAM or more needed for 1080p video streaming and 1GB RAM is typically needed for streaming 720p).

In the moonraker log it reported:
2024-07-03 00:34:58,589 [update_manager.py:_handle_auto_refresh()] - Klippy is printing, auto refresh aborted
2024-07-03 01:34:58,591 [update_manager.py:_handle_auto_refresh()] - Klippy is printing, auto refresh aborted
2024-07-03 02:34:58,591 [update_manager.py:_handle_auto_refresh()] - Klippy is printing, auto refresh aborted
2024-07-03 02:42:43,091 [klippy_connection.py:_process_status_update()] - Klippy has shutdown
2024-07-03 02:42:43,139 [proc_stats.py:_handle_shutdown()] -

So, is this the problem and should I try the 720p at 15fps?
Or is my problem something else?

I noticed my firmware says dirty! I should update it but I was scared off by the many reports of trouble after updates. One stated it is possible that it will not work anymore and you would have to flash something. This is totally outside of my comfort zone so I have not yet attempted any updates.

Background of this machine is that my father bought it second hand and after he lost interest he gave it to me. It is my first klipper machine.

Would appreciate it if I had somebody more knowledgeable looking into this and at least point me in the right direction. Failing that I will retry with the webcam on the lower settings and if it fails again I will try the same gcode without the webcam.

[Sineos]

There are two topics

• You are using inoffical 3rd party modifications to Klipper:

Git version: 'v0.12.0-75-g94719fe3-dirty'
Untracked files: klippy/extras/beacon.py, klippy/extras/gcode_shell_command.py, klippy/extras/linear_movement_vibrations.py, klippy/extras/ratos_homing.py
Branch: master
Remote: origin
Tracked URL: https://github.com/Klipper3d/klipper.git
CPU: 4 core ?
Python: '3.9.2 (default, Feb 28 2021, 17:03:44) \n[GCC 10.2.1 20210110]'

• Webcams are notorious for causing TTC errors. Most likely because they somehow “hog” the USB bus. This leads to delays in the transmission of data between the RPi and the printer board and this leads to TTC

Potentially also the above mentioned modifications have a negative impact on Klipper’s timing and in combination with the webcam the error is created. This is almost impossible to diagnose.

Possible solutions:

• Revert the modifications - If it gets better or is solved then they are contributing
• Remove the webcam
• Play with the stream’s bitrate, resolution etc if it yields an improvement

That’s about it. Not much more you could do.

[3dcase]

Hi Sineos,

Thank you for looking at this, no matter the outcome it is much appreciated.

With regards to the unofficial 3rd party modifications, you mean those untracked url’s from ratOS?

What would you advise if I told you that I did not build this system and the person that did used a RatOS as base from which to modify until the Voron worked.

I know it all sounds rather convoluted, but that is the history. Also at one point it was working with Fluidd, but the person doing the mods did not know Fluidd and rather changed it to Mainsail.

So, should I simply get myself another sd card and start fresh, or is this somehow salvageable? I do have a second pi to work with so I don’t have to stop this machine working.

With regards to the webcam, yes I will remove it first and try my gcode without the webcam. If that works then I am certain it is not something in the gcode.
After that I can try the webcam on a lower resolution perhaps.

[Sineos]

Really difficult to say. You have numerous modifications from different sources and it is not clear if they are “just installed” or needed for operation.

I would start wit a new SD / new RPi and see where you end up. It will anyway come the day where you need to think about updating.

[3dcase]

With regards to the camera problem, the printer seems to now happily print and show me a video at the same time without crashing on me after 10 hours or so.

I halved the resolution and I halved the FPS as well. Not the best image but good enough to see if it is worth worrying about it or let it continue. The AI also states all looks good so we will see where that ships strands. Maybe one day I will attempt a deliberate spaghetti monster and see if it picks it up.

With regards to your evaluation of the modifications of numerous sources, I believe they are remnants of the OS that was used as a base to build this machine, and partly left over from when the machine got changed to mainsail from fluidd.

I will yank my other SBC out of my unfinished project and attempt to build a klipper from scratch.
Not looking forward to it but probably the best way forwards and a good way to learn the hard way.

Thanks for your time again, I will close this thread now as solved.
If, or rather “when” I will run into trouble doing the new build, I will open a new discussion.