3d print remote status testing

From Pumping Station One
Jump to navigation Jump to search

Cliff Notes

  • It would be super-useful if we could check the status of the 3D printers remotely
  • I explored two options for remote viewing of the status of the 3D printers: OctoSlack and OctoFarm
  • The OctoSlack plug-in fits our use case and is very promising
  • If that doesn't pan out, OctoFarm is a viable alternative
  • I am requesting permission to experiment on one of the Enders as a trial
  • I would also like to install an RPi Camera on the Ender so we can get screenshots

Background

Since getting authorized on the 3D printers, I have driven to the space a couple times only to find all the printers I wanted to use occupied. Naturally, this is a frustrating experience. Once you do find an empty printer, you set your print job and come back hours later to see if the print succeeded. If the print failed, you probably have a mess to clean up and are out time and filament.

If we could remotely view the status of the printers, both of these problems would be significantly reduced. As I thought about this problem, I realized that remote viewing must be a common need for 3D printer owners. I set out to find an existing solution in the community that is low cost and low impact.

Goals and Requirements

  • Remote viewing of print status, bed temperature, estimated time of completion, and so on
  • Easily accessible to all members
  • NO exposure of OctoPrint or other computers to the open internet
  • Low cost / free
  • Authenticated access
  • BONUS: Display images of the print bed
  • BONUS: Remote control (more on this in a bit)

Options Explored

I looked at the various plug-ins and servers available in the community. After some research I chose the OctoSlack plug-in and the OctoFarm server software as the front-runners. Testing was done at home using OctoPrint running a virtual printer on an RPi 4B.

OctoSlack

OctoSlack (https://github.com/fraschetti/Octoslack) is an OctoPrint plug-in that allows you to push printer status to a Slack channel. The plug-in has been around for about 4 years and is open source and MIT licensed. No additional hardware is needed to run the plug-in (assuming the RPi is powerful enough to handle the additional plug-in processing).

Setting up the plug-in is simple. You create a Slack App with the correct scopes (see the first half of this page for details: https://api.slack.com/authentication/basics). Once you install the Slack App to your Slack workspace, you are issued an API token that is entered into the plug-in configuration screen in OctoPrint.

After setting a couple more settings, you are ready to go. OctoSlack will automatically start pushing print status to a channel of your choosing. Users can also direct message the app to query the current status at any time.

If we were to use OctoSlack at PS:One, we would create one Slack App for each printer. We could then configure each printer to post updates to a channel. In my testing with my personal Slack workspace, the plug-in worked very well. Response times were snappy. The messages are clean and presentable.

There are additional cool things about the plug-in. If you have a camera connected to OctoPrint, your status updates will include screenshots of the print. You can choose which notifications you want to send to the channel. In addition, OctoSlack has the (optional) capability of allowing users to pause and stop the printers using Slack messages. This feature could be very useful if an active print is failing. The command feature can be restricted to specific users or left open to any Slack user. At a minimum, I could see the stop print feature being useful for 3D area hosts who notice something is not right with a printer.

The only downside I can tell is the risk of the plug-in interfering with the printer itself. OctoSlack does its work on background threads so as to not interrupt the main OctoPrint thread. However, we still need to perform field testing on a real printer to verify that OctoSlack does not cause intermittent command buffer underrun on the printer. I also want to test that the plug-in behaves gracefully when the internet connection is not working.

If we do take screenshots, we will need somewhere to host them. I recommend we use Azure BLOB storage for this purpose. The hosting costs should be minimal, and we can set a retention period on the BLOB storage container so that images are automatically deleted after a few days.

OctoFarm

OctoFarm (https://github.com/OctoFarm/OctoFarm) is a standalone server for monitoring and controlling multiple printers from a single interface. It has been in development for about 18 months and is open source with an AGPL 3.0 license.

I ran the server on my MacOS desktop under Docker. In production we would run the server on an RPi. The server requires MongoDB and some software dependencies, but these are easy enough to get going. I was able to get a server running in a container and connected to my OctoPrint machine in less than 15 minutes.

Connecting the server to OctoPrint is simple. The primary configuration requirement is to create an API key so OctoFarm can connect to the print server api. Configuration and printer registration is simple and painless.

The user interface of OctoFarm is nice and polished. There are several "views" of your printers that come out of the box. The view I was most interested in was the Panel View, which displays all of your printers with live stats and screenshots in tiles on a single screen. The Panel View is a really nice way to see all the printers at a glance.

One of my requirements is to not directly expose any server to the internet. Thus, we cannot use OctoFarm directly to view the printers from a remote location. The solution I came up with was to take an automated screenshot of the panel view using headless Chrome. This works fairly reliably. I had to fiddle with the command-line settings to ensure the html page was rendered completely, but once I got the settings worked out, the screenshots were clear and reliable.

If we implement OctoFarm, I would put a cron job on the RPi running OctoFarm to take a screenshot every few minutes and upload it to Azure. We could then serve up the latest screenshot and protect it using our AD accounts (I need to double-check with the Tech Team, but I believe this is possible with our current Azure setup). Members could then use their normal network credentials to access the printer status. Hosting and traffic costs for serving a single PNG to the membership would be insignificant. There may also be other ways to host the image (wiki, existing web server in the space, etc).

Recommendation

I really like the OctoSlack plug-in:

  • Simple
  • Does what we need
  • Does not require any additional hardware
  • All members have access to Slack (or can easily register)

I'd like to experiment with OctoSlack on a single printer and collect real-world feedback. One of the Enders would be a good option because those printers are not used as often (if something goes wrong, it is less disruptive). I would also like to add in RPi camera to the Ender so we get screenshots with the notifications. As long as we are going through the effort to connect the printer to Slack, we might as well slap a $25 camera on there and get images as well.

As part of the testing, I would take a backup of the SD card that contains OctoPrint. If something goes wrong, we can always restore to a known good state.

Next Steps

  • GET FEEDBACK from the area hosts and community
  • IF APPROVAL is granted, work with the area hosts to set up an Ender for testing
  • AFTER TESTING is successful, figure out next steps to get the plug-in installed on the other printers and purchase cameras for the other printers


Screenshots

OctoSlack Octoslackexample.png

OctoFarm Octofarmexample1.png

Retrieved from "https://ps1.mywikis.wiki/w/index.php?title=3d_print_remote_status_testing&oldid=44166"