If you know my blog, or by just having a look in the archive you will quickly find out that I am a fan of printrbot. My very first 3D printer has been a Simple Metal. This has been a great starting point into 3D printing. But it had its caveat that forced me to write down a blog post on how to fix the little issues that I had when I first got that printer. But I loved it for its simple yet effective design and it’s gorgeous print quality.
Last year in November I released my Mac Application Copper (http://www.copper-app.com). It’s a companion application for Eagle CAD that fills the gaps where Eagle fails. I tried to advertise it
using typical methods like buying Ads at Facebook and Twitter. That did not really work as this product is a niche product which is hard to market in these channels. I had a lot of costly clicks from Windows users that were interested if this application is available for Windows, too. It’s not! So I had to find different ways of getting some traffic on Copper.
I looked around in my office and found my Little Helper (http://www.appfruits.com/2015/12/little- helper/). It’s one of my earlier electronics project that is a great helper in my lab. I always thought about doing a Kickstarter for it, but did not as baking so many projects at Kickstarter I knew: It’s hard to get a polished project in time. So I decided to release it to the public under open source. I got quite a lot of traffic on this and Copper sales increased dramatically. By giving something back to the community that helped me to learn electronics faster than I thought I got a lot of traffic and free advertisement for my products and webpage. If you consider doing the same: Do it! You will likely gain more than with a failed Kickstarter!
Product Development done right
You may ask: What the hell is the point here? So, let’s get started: The other day I noticed in a Copper sales report that someone with a @printrbot.com email address bought Copper. Being a fan of them I sent them an email thanking them for purchasing Copper and telling them I loved their Simple Metal. This changed everything! We got in contact and Mick told me he learned about Copper by reading my blog post about Little Helper (http://www.appfruits.com/2015/12/little- helper/), which he noticed in a blog post on hackaday.com (http://hackaday.com/2015/12/25/little- helper-open-source-hardware-hacker-multitool/). He also told me he uses Copper to quickly checkout pin numbers and signals when working on the firmware for their printers.
A few days later I had a Skype chat together with Mick and Brook Drumm (founder and CEO of printrbot) and they asked me if it would be possible to use Little Helper as a display and input system for their printers. A year ago most 3D printers used a tiny LCD screen with a rotating input wheel (rotary encoder) and a SD card slot for printer control. Little Helper seemed like a good fit and a step forward.
So, after one Skype chat we started the project to create a LCD display for the next generation of printrbot products. This is awesome. I don’t think a lot of CEOs in Germany would start things like that. This is visionary and full of risks. They are in the US, I am in Germany. We have a time difference of 8-9 hours. There are so many things that could go wrong. In Germany you would rather want to hire someone around you. You want to be able to control what he/she is doing. Brook just has been confident that it will work out. I am running a German internet company full time (4players.de (http://www.4players.de)). These projects and Copper are filling my spare time that I need to fill with creativity and product development to be healthy and happy ;-). This has been a great chance for me to do something with a little more impact than working in my lab for myself or the open source community.
Finding the right shape
After our Skype call I had written down a document describing the details of Little Helper and some issues with that design that came to my mind and a few alternatives. This is what German people do, they structure stuff ;-). While I was structuring stuff, Brook and Mick thought about the product as a whole. After some more eMail discussions the final product quickly got a rough shape. This is a quote from of one of our first discussions:
Anyway, if we all agree a touchscreen + teensy is a viable path, let’s set that in stone. I realize it won’t leverage much of the little helper, but I want to make the right decision and it seems it will reduce cost, complexity and future proof the UI
Does it make any sense to put the esp and Sd card on the same board?
If you want to run a business or want to succeed in product development you just learned what is essential: Have the courage to decide on things. We discussed a few days and already had a clear roadmap what we wanted to develop. Today there are more options than you can count, for each and every component on the board. Of course we had a look at other things, too. For example we looked at Photons for WiFi connection but due to some restrictions in their business model and some technical aspects kept us sticking with the good old ESP8266.
You may ask why we opted for two MCUs on one board, the ESP could have run the display, too. Why adding the Teensy? Well, I knew from some tests before that Paul (Teensy developer) created a very, very fast display driver for ILI9341 based displays that has been way faster than any other MCU. And the overall support for high quality code and drivers for Teensy promised fast development opportunities. Talking to the web is an asynchronous task, while handling
touches, running a display and controlling a printer is a synchronous task. I think it’s been the right decision to let ESP talk to the web, while Teensy handles the rest.
This is the final specification that we had set in stone before I even launched EAGLE or my development IDE:
- Teensy MCU (3.1)
- ESP8266
- ILI9341 based 2.8 inch display microSD card slot
- Capacitive touch
To give you an idea of the time frame: I had the first contact with Mick on January 5th, and we decided creating it with the final specifications on January 11th! Deciding early and sticking to that makes it way easier for larger teams to work on the same product. If you always change specifications and details you always reset your team. That kills motivation. Not in this project. I don’t think I ever slept less than during the last few months, but it’s been such a great adventure and journey!
Technology described
Arduino and Teensy made it so much easier to create products like this, but it’s still a lot of work, especially if you want to build professional products. People are used to a very high standard for touch screen based displays. They want animation, fast refresh rates and a very responsive experience. The software that is needed to run a user interface on such a limited device has not been available and so we had to develop it. Communicating with the ESP8266 module is easy, just use UART connection available on nearly every MCU. But it’s not easy if your host MCU has to get other things done while ESP8266 is downloading content. As you can see we had to develop a lot of software.
In our very first call Brook made clear that he wanted to Open Source everything that we would develop. The good news for you: We made that true today. You can have a look in every detail of our display system and core technology. In the next serious of documents I will try to explain how everything works together and in detail.
Hardware and PCB
Compared to the time spent on software development, hardware development was peanuts. The first PCB I developed worked great and we had a good development platform to work on software. Overall we had four revisions of the hardware.
Read more about the process of getting the final hardware for the display and learn why about the details of the PCB and how you can make use of it in your own projects.
Display system
The Display system (http://www.appfruits.com/2016/11/printrbot-simple-2016-display-system- explained/) built upon the amazing and very fast display driver developed by Paul J. Stoffregen (Teensy creator). Although it uses SPI (which is not the fastest method to connect to a display) it’s very fast and just works great. We have written our own driver for the FT6206 touch controller we use, although it’s been heavily influenced by the driver from Adafruit.
Displays have a memory area and small pixels are connected to this memory (not in a circuit kind of way but you get the idea). When you change the bytes in that memory area the display reflects that. You modify this memory area using SPI to write data in specific memory regions. That takes time. And as the display immediately reflects any changes you can see the display building up the final user interface. Worst, you cannot just first fill a rectangle and then draw some text on it, as it would result in flickering. Animation is practically impossible although Paul did a very good job of making it as fast as possible.
There is a very easy way of fixing that: a back buffer. You store a memory area in your MCU that mimics that memory area of the display. You make changes there, you can overwrite data multiple times. And when everything is composed you send the whole area to the display. This does not allow for fast animations, too. But you get a nice, polished look and feel. But, Teensy does not have enough memory to store a back buffer!
We had to develop a whole new way of handling the pixels of a small display. And we managed to do that. Our display system is versatile, fast, easy to use and very flexible. It permits very large scrollable areas without eating a lot of memory and while keeping very fast refresh rates and responsiveness. It’s an amazing system and you should learn how it works (http://www.appfruits.com/2016/11/printrbot-simple-2016-display-system-explained/) and how you can use it yourself in your next project.
CommStack
Another system we have built from scratch is CommStack. It’s a request/response based asynchronous non-blocking full duplex communication system based on UART. It is the robust communication stack permitting the main MCU (Teensy) talking to ESP8266 without getting blocked or loosing data while doing other things. It also allows ESP to talk to the Teensy at the same time.
This is another amazing technology that we built and that made our lives so much easier. Once we had CommStack up and running it’s been very easy to implement new features as we just could use the MCU that is best used for the case and use CommStack to coordinate task management.
Read more in our CommStack documentation to learn how it works and how you can use it yourself.
Over the air firmware updates and flashing Teensy
This is huge: When we decided to use two MCUs on one board (ESP8266 and MK20DX256LHV7) we also needed a way to flash firmware on them. On a dev board it’s easy. We added a FTDI header for flashing ESP8266 and we added the amazing PJRC Teensy bootloader chip that permitted us to flash Teensy firmware using USB. But in the final system we wanted over the air updates. We wanted a printer that does not need to be connected to a PC/Mac. And we want to be able to add features to the printer, which only makes sense if customers can update the firmware easily.
As Teensy does not support over the air updates, we had to develop it ourselves. Read on and learn how you can add over the air updates to your own Teensy based projects by just adding a ESP8266 module!
Final words
Looking back I think it has been very important to write down the components we wanted to use and to stick with them. Every core technology described above had its hard days. Days where we have been frustrated and didn’t make any progress. Those days are very hard. And if your company culture is to find ways around issues than solving them (I think there are quite a lot of companies working like that) you never get finished with things. We could have exchanged the Teensy MCU with a more powerful one with more RAM, with more pins to connect the display via parallel (faster) connection we could have worked around that. But perhaps we had a hard time to get over the air updates up and running with this new MCU. Who knows.
I think it’s our job as a product developer to solve these issues and so did the whole team. The whole team forced me and motivated me to solve these issues. And we were so excited when things finally worked. That is what you need: Backup for hard times and party when it finally works :-).
Time difference has been good and bad at the same time. Due to 8-9 hours time difference we only had a short window for chatting each day. It forced us to organize our work but modern tools like Github and Skype allowed us to do that very easily. For me time difference has been great as this project never collided with my full time job. While I have been working my daily job the printrbot guys have been sleeping, and once they started their day I already had finished my daily job and were able to work on this project. Time difference had been an issue in the last weeks of polishing the product. It required us to package all that little pieces we developed in the past months and it’s been frustrating as the team testing the printers sometimes had to wait a day until I have been able to fix the issue.
If you ever have the chance to work with Printrbot: Do it! You will not regret it. You will learn a ton, you will have a lot of fun and you will have new friends after that. This sounds like a final conclusion, but think about that like a season 1 final: We just got started!
