I noticed some serial communication lag between the Pi3B+ and the printer. Further investigation revealed Tensorflow + OctoPrint on a Pi3B+ is still too much. Printing from SD is just fine, but it's back to sneakernet that OctoPrint is supposed to avoid. Tried a wireless SD, but the "good"  hackable Transcend ones are not to be had. Tried setting processor affinity, spreading out the process a little so it doesn't hammer the thing all at once, launching the script separately. 

I doubted I could run TF on a Pi0, but it wasn't too bad. (I had nightmares of compiling numpy for 8 hrs)

I think it's actually better now, TF runs on the Pi0, as does the stream. It continuously streams, analyses images, and puts the results in a file. Since the Pi0 filesystem is served by the 3B+  it's easy to get the info up on the OctoPrint navbar. I've ran it like this for 12+ hrs of combined prints and so far so good. 

I added the ability to restart the Pi0 from the system menu, so you can bounce the zero even while printing. This uses 

https://github.com/mvp/uhubctl to control the USB power to the Zero. Other configurations may work, but I have the Zero in the bottom USB next to the ethernet jack and the printer in the USB above it. This does not cycle the USB connection to the printer. 

I wrote a little shell script that automates the power cycle, and repeats the rpiboot sending of the file system. OctoPrint seems to req python for everything so the shell script is launched from python. (this should be simplified in the future).

Now that that's out of the way I can get back to "prints that fail on purpose"