Well, you could try enabling Settings->Serial Connection->log communications to serial.log. It has a warning about performance, but didn’t seem to affect a couple of test prints I did. If you ssh into the pi and “tail -f ~/.octoprint/logs/serial.log” you should see all the serial being logged at debug log level in serial.log.
This will generate a very large set of serial log files quickly though, so I’m not sure it is going to work for you over several hours of printing required to reproduce this failure. To get around this, you could try mounting an external network NAS drive, and then sending all of the octoprint logs there I suppose. This should work…
How to send octoprint logs to a network attached storage
-
Check cifs-utils is installed:
sudo apt-get install cifs-utils(I think it already is on octopi image) -
Make a directory on the octopi to mount to a NAS shared folder:
mkdir -p /home/pi/NAS/share -
Add share to fstab:
sudo nano /etc/fstaband add a line for your NAS, something like (where “OctoPrint is a shared folder on the NAS drive”:
//NAS/OctoPrint /home/pi/NAS/share cifs username=your_username,password=your_password,workgroup=your_workgroup,users,auto,user_xattr 0 0 -
Go to the directory:
cd ~/NAS/share -
Doesn’t hurt to test it by
a. Mounting the NAS drive:sudo mount -a
b. Create a file:touch test
c. Make sure you can see the “test” file on the NAS directory. -
Change octoprint to log there under settings->folders->Logs folder to /home/pi/NAS/share
-
Restart octoprint with System->Restart OctoPrint
You should now see the serial.log (and other logs) on the NAS shared folder instead of the local pi file system. This hopefully could provide some info as to what happens just prior to the failure. Good luck!