I use octoprint to manage my printer. When I can, I batch print. I will literally print things back to back. But I also love the timelapse and we have all seen it….
But I have more robot stuff to print!!!!
Settle down there smart guy.
Nobody asked you!
Ok, interruptions aside. Running octoprint on an original pi is a little slow.
Did you say apple pi?
I don’t like this guy.
I said ORIGINAL pi. Yes, old school slow.
So what happens if you try to print again while it’s rending a timelapse… well, you get a lot of stalls on the print, meaning the head sits over the print causing some unnecessary melting.
So how do you fix it if you are so smart?
Well, you would offload it. I have a linux box that handles all sorts of random tasks. It could do it.
So here is how I offload it.
- setup an NFS share to a nas/other server
192.168.X.XX:/mnt/vol/dataset1 /home/pi/fs nfs nouser,atime,auto,rw,dev,exec,suid 0 0
- Configure octoprint to store the timelapse pics on this NFS share.
- All that is doing is changing the location of the timelapse, not offloading jerk.
I KNOW!!! I’m not done!
So now we need to setup the exact same share on the other linux box. If I had thought about it early on I would have changed the path on the pi to be something like /media/share/ instead of /home/pi/fs
So we put the same path on the other linux box.
- Now the fun stuff.
I created a small shell script on the PI.
#!/bin/bash ssh firstname.lastname@example.org.X.X "ffmpeg $@" if [ $? -eq 0 ] then # everything was good exit 0 else exit 1 fi
- Set up your pi to be able to login with no password (using keys instead) so that the ssh connection will not hold anything up.
- Configure octoprint to use this new script as your ffmpeg path.
So let me walk you though it.
Are you being nice all of the sudden?
Anyway. So octoprint is now setup to store your timelapse images on the network somewhere. Linux box is setup to have the exact same path. When your print is done octoprint executes the timelapse.sh script thinking that is ffmpeg. So it runs it waiting for it to exit with a success or failure. So in the script, we ssh to the linux box, tell it to run the ffmpeg with the $@ which means everything octoprint wanted to pass to ffmpeg locally we are passing to the remote ffmpeg. The other box does all the heavy lifting and returns an exit code, we pass that exit code back to octoprint. It’s none the wiser.
The cpu is next to nothing because we are just waiting for the ssh command to finish. So I have started additional prints with minimal issues.
I have noticed that if you keep your filenames short and sweet it helps.
Is this a great solution or what?
No. Buy a better pie.
Don’t you mean a “pi?” Haha. Jerk.