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?
No description
No description
No description
3 Replies
SimonSolar2C
SimonSolar2C14mo ago
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?
No description
SimonSolar2C
SimonSolar2C14mo ago
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?
SimonSolar2C
SimonSolar2C14mo ago
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
No description
No description
Want results from more Discord servers?
Add your server