mcu shutdown Timer too close - Octopus, Pi4, Vcore3, 500
So many discussions about this but nowhere can I find a systematic process to debug the issue
Trial and error is not a method when its so intermittent and waits until 2 days into a print to occur.
I've looked at klippy.log using the graph display method at https://sineos.github.io/
MCU is running fine.
Disc: I had just 1.5 GB free space on SD card - could the file system be slowing down?
RAM: Moonraker reports just 29548KB in use, so not that.
Overheating - I havent seen thgis before in real time - dont know how to check for it in debug data
Unstable voltage - doubt it - seperate 5v to RasPi
USB cable was new when RR built.
Other observations:
Using ssh->top I do see a suspicious ffmpeg process, (part of timelapse?) however its there whilst in current error state. Should'nt be running until the print finishes right?
I use Obico to watch the prints - do additional clients windows watching the machine/webcam on my PC use more RasPi resources?
And finbal observation, I found a thread which said the issue is due to an incorrect clock reference (8->12) in the kiuah update script - but do we have that on a RatOS install?
3 Replies
I found another observation in the logs:
Looks like it hit host buffer 100% just before shutdown (and earlier in the print ) - how to resolve? Can the buffer size be increased for example?
Okay turns out I have a RasPi3B, which should still be suitable, but perhaps some tweaks are needed - can I run Obico and webcam service, for example?
Ive noticed there is a ffmpeg process consuming lots of cpu cycles - 43%, if I stop and restart my webcamd ( which uses mjpeg-streamer) then the big FFMPEG process disappears
