We recently acquired a MakerBot Replicator 2 here at Truth Labs. He is affectionately known as Arnold of Villanova II (Arnold for short). In the maker spirit, we rolled our own chrome extension to let us know what Arnold is up to. We used some cool tech – s3g Protocol, Raspberry Pi, Node.js and of course, Google Chrome Extensions. Here’s how we did it.
The Problem: Location Location Location
Arnold isn’t centrally located, which requires us to take a trip to check on the status of print jobs, and many times, to our dismay, we find Arnold errored-out in a pile of his own filament. Print jobs take anywhere from 30 minutes for simple models all the way up to a couple hours for complex ones, so the walk to and from Arnold over the span of a day gets tedious.
The Solution: Self-Aware MakerBots
Well, not exactly self-aware MakerBots, but it’s a start. A conventional MakerBot Replicator 2 does not have the capability to connect to the internet, but with a little help from a Raspberry Pi, all things are possible. Taking a page out of the Internet of Things playbook, I set out to connect Arnold to the internet, and run a simple notification system. There are a couple pieces to the puzzle, I’ll explain how they fit together below. Also you can checkout the makerbot-status repo for example code to get you started. The repo shows you how to use the s3g Protocol to query info from a MakerBot connected via USB.
Pieces of the Puzzle
MakerBot Replicator 2 – Running firmware capable of serial communication through the USB connector.
Raspberry Pi – Running a simple Node.js application responsible for communicating with the MakerBot over the s3g protocol.
Pidora 18 (Raspberry Pi Fedora Remix) – A Linux Distro available for the Pi. It is based on Fedora, my distro of choice.
Node.js (compiled from source) – Compile Node.js from source to ensure node-gyp worked correctly on the Raspberry Pi, and played nice with the node-serialport package.
Windows Azure – Created a cloud based endpoint for Arnold to send information to. The Azure website also hosts a bayeux server to manage any clients listening for new information.
Google Chrome (Extensions) – Chrome, through its Extensions, hooks into desktop notifications easily.
The Highlights
This particular combination of tech offered up some unique challenges. Here are the highlights:
Building Node.js from source on Raspberry Pi
Due to the necessity of node-gyp, and low level communications via serial drivers I had to build node from source on the Raspberry Pi. It is a straightforward process as long as your environment is set up correctly. First you’ll need to install a linux distro, you can find them on the Raspberry Pi website. Also note that the instructions listed below were completed using Pidora. Milage may vary.
Build Environment Setup
There are a couple of things that you have to do before building Node.js from source. Also note that some commands require elevated privileges, and depending on your distro, you may need to use su or sudo commands.
The first thing we will do is set the system clock. Some strange build errors occur when the system clock is wrong.
$ date --set="18 NOV 2013 18:00:00"
Once the date and time are correct, you will also need to update the package manager, and all installed packages, Yum Package Manager is the package manager installed on Pidora. A full system update can be performed by executing the following:
$ yum update
Once your system is up-to-date we need to make sure Python (2.6 or 2.7), GCC 4.2 or newer and GNU Make 3.81 or newer are installed. Python should already be installed, to install gcc and make execute the commands below:
$ yum install gcc-c++.armv6hl $ yum install make.armv6hl
Download and Build Node.js
Now that we have our build environment ready to go, we need to download, build and install Node.js. Follow the steps below:
- Download node-v0.10.18.tar.gz source files or equivalent
- Extract files to a directory, then change directory to the extracted directory
$ tar xvfz node-v0.10.18.tar.gz $ cd node-v0.10.18
- Run ./configure script
$ ./configure
- Execute make command (this will take a while)
$ make
- Execute make install command (this will also take a while)
$ make install
- Finished – If everything goes well you should be able to execute the following command:
$ node --version
Talking to Arnold over s3g Protocol using Node.js
The s3g Protocol is a serial protocol that is used by MakerWare and similar software to communicate with MakerBots. MakerBot Industries provides a Python implementation of the protocol here. Using the Python protocol as a reference, I implemented a small subset of the protocol in Node.js, you can find the source on github.
s3g Protocol Queries
Using ArrayBuffer and Buffer objects, I implemented a simple query builder that creates well formed s3g packets to send to the MakerBot via the serial port. The interface currently supports three s3g queries:
- Get Build Name
- Get Build Stats
- Get Toolhead Temp
Serial Communication via node-serialport
The node-serialport package provides a simple serial interface to communicate with the MakerBot. I wrote a wrapper around the serial interface to support command/response parsing.
Broadcasting Status to Azure
The node application on the Raspberry Pi queries the MakerBot every 20 seconds. When a change in status is detected a POST to a Windows Azure Node.js service is performed. Windows Azure is used to avoid having to provide an externally accessible IP address for the Raspberry Pi, and to offload the responsibility of servicing clients.
Chrome Extensions and Notifications
Chrome supports parts of the W3C Web Notifications draft standard. I initially looked at implementing notifications using the standard, but felt there are still shortcomings. Specifically the user must give permission for notifications, and you would have to navigate to the site to receive notifications. To get around these limitations, I decided to implement a Chrome Extension. I created a simple popup that shows the current status of the MakerBot, Figure 5. is the extension popup in action. To allow notifications when the popup was inactive I used a background page, which will be explained below.
Background Pages
A Background page is a collection of scripts that have a longer lifecycle than the popup that is displayed when you click on an extension’s icon. This allows updates to be received and notifications to be displayed once chrome starts. To define a background page, you need to add an entry to your extension’s manifest file. It should also include any dependencies your background page will utilize.
"background": { "scripts": ["jquery.min.1.10.2.js", "faye-browser-min.js", "background.js"] }, "content_security_policy": "script-src 'self' https://makerstatus.azurewebsites.net; object-src 'self'"
Faye Publish-Subscribe Messaging System
You’ll notice that the background page entry in the manifest includes faye-browser-min.js. We use Faye to establish a connection to the Windows Azure Node.js service. Faye is used to broadcast updates from Arnold. To get Faye functional in the extension’s sandbox we need to add an entry to loosen the Content Security Policy of the extension. This allows for JSON-P callback-polling, which is a transport mechanism used by Faye. It is necessary here because the extension and the Azure service are not on the same domain.
Notifications
To enable notifications, it is necessary to include a line in the permissions section of the manifest file. Since we use an icon with our notification, we also need to add it as a web accessible resource.
"permissions": [ "notifications" ], "web_accessible_resources": [ "makerbot.logo.notify.png" ]
Once all of the scripts are in place, and the rest of the manifest file entires, when we receive an update we create a simple notification like the one pictured below.
Wrapping it all up
In this post we went through some of the steps to connect a MakerBot to the interwebs. Now that we have the base implemented, some interesting additions may include adding build complete percentage, or even a live stream of build progress via WebRTC.
Happy Making!
ADVERTISEMENT