That is good idea but i trust that Calmato67 has to restart from the begining firstly. So, yes, after the benchy was printed and that he shared the pictures, that will help to know if there is an issue with that. This benchy has to be fine (first layer, bridges, surfaces, etc). If not, that will be easy to guest the issue, if it is, we will upscale the difficulty.
You can just use df -h which is included in every linux distro I’ve ever used
1 Like
A benchy print, fast version would be nice to see.
My first thought is this might be to little tention on the x/y axis? I tried the frequency adjustment on mine, but found it to still be to loose.
I also used calipers to adjust the gantry position making sure they are spot on. You can some what diagnose that on homing. If the x-carriage dosent silent hit the end, or you see it shift even a tiny bit, you should address this.
Don’t loose hope, we should be able to get your printer in shape with abit of tinkering and troubleshooting 
Blockquote
32 GB Makerbase EMMC module and USB “dongle” $18us on AliExpress (this "shop)
If you live in the US hurry, more and more vendors are goin to
Every day
To echo and expand on the good advice already provided, I’d definitely try to get back to basics and start trying to get the SV08 printing small prints and then gradually troubleshoot, repair and build confidence in the reliability before trying large complex prints that will only serve to frustrate and demotivate. For mystery errors such as aborting a print midway, with or without a cryptic Klipper error message, I’d first try to make it as easy as possible on the host and MCU processors.
It’s good to know how much free space you have on the EMMC memory but I’d probably not even bother to ssh into the printer and would simply use the Mainsail web interface to delete the prior G code files and any time lapse videos. I disabled time lapse videos because I don’t use them and they add extra work for the host processor and they fill up the EMMC memory, both of which reduce reliability.
It sounds like you’re managing your SV08 with the Obico user interface. You might try commenting out all references to Obico in printer.cfg and trying to use the web interface on a computer to see if Obico could be contributing to your SV08’s problems. Obico definitely requires some processing on the host and could overload it if the host was at the edge of being overtaxed and some combination of asynchronous events pushed the host over its processing capacity.
Are you using a 0.4 mm nozzle? I had some fatal Klipper errors that caused SV08 prints to abort midway through the print when I was using a 0.8 mm nozzle and (I think maybe) a STEP file instead of an STL fed into OrcaSlicer. That may have caused OrcaSlicer to generate more complex G code, at least for part of the print, because the print seemed to stop at the same place. I should have taken the time to fully diagnose the problem for the benefit of others but I seem to remember switching back to a 0.4 mm nozzle and an STL file at the same time and the problem disappeared. I still use STEP files for parts that are mostly curves, and it doesn’t cause a problem with the 0.4 mm nozzle, so the problem may have been too many extruder steps trying to get the most speed out of a 0.8 mm nozzle, or trying to move in X and Y fast enough when the print speed is no longer limited by extrusion speed.