v2.2.0 of PolargraphSD3 firmware released

This is a minor version update, but it’s actually just putting a missing feature back in: The pen width test function is back. Pretty dull huh!

And while you’re here, have a quick look at this post from Blackheart Press, producing an edition of penwork with his Polargraph machine:

Servo motor shenanigans!

The PolargraphSD’s pen gondola has a servo motor attached that turns a control horn against the paper, and lifts (or drops) the pen tip against the page.

In the new design, the servo is powered by a 5v supply, but the instructions (the signal to say which position to move to) comes from the ESP32, which is a 3.3v device, and so it’s signals are 3.3v. It turns out this was a bad idea and it causes a lot of twitchy moves.

For two dozen machines, it’s not been a problem that concerned me – indeed I didn’t even find it to be a problem, which is why I didn’t do anything about it.

In retrospect, the mixed voltages seems obviously risky. I recall that it was an open question when I was first designing the new Polarshield 3. Because the old machine was 5v-based, the initial design for the new Polarshield used the same scheme to power the motor. I remember being a bit surprised that it worked fine! I don’t think I even tested it on the 3.3v supply.

However, this week I built a couple of machines in a row that were unacceptably twitchy, and couldn’t ignore it because I knew it’d cause problems for people, and be very hard to work around “in the field”.

The fix for this is pretty simple – cut the 5v line to the servo and link in the 3.3v line instead, but it’s a soldering job, not something I could expect anyone to do themselves.

And after that, what a smooth arc!

Another side-effect is that the machine can now sweep the servo when it’s only powered by USB. Previously that would draw too much power and cause a reset! Nice!


  • Just because it works 24 times, doesn’t mean it’s right
  • Don’t ignore the inklings, you’ll just have to fix it later when it’s harder

The machines that I’ve already sent out since the beginning of September may exhibit this problem and need a fix. I’m really sorry that I didn’t spot this earlier.

I’d be delighted to do the repair if you’d like to send your control box back to me!

If you’d like the fix, please drop me an email and I’ll arrange a collection as quickly as I can.

(You can see a boring video of the actual fix here: https://youtu.be/J56dzZaDV8s .)

How to upload new firmware to the PolargraphSD v3.0

This is for a PolargraphSD v3.0, that’s based on the ESP32 microcontroller.

I’ve switched to using PlatformIO with VSCode as a development environment for PolargraphSD. Although the Arduino IDE is ubiquitous, PlatformIO allows me to use a best-of-breed IDE like VSCode or Atom. I use VSCode because I had a couple of problems with Atom.

PlatformIO is an extension that interfaces with microcontrollers, and manages libraries automatically in a more mature way than Arduino IDE.

There’s a guide to compiling the code using PlatformIO and Arduino IDE in the project wiki: https://github.com/euphy/polargraph_server_polarshield_esp32/wiki/How-to-build-the-firmware

Uploading precompiled binary files

I will periodically include a compiled binary in the project, which you can use if you don’t want to go to the trouble of dealing with IDEs and source code and compiling it yourself.

The project binaries folder (https://github.com/euphy/polargraph_server_polarshield_esp32/tree/master/binaries) contains four files which should be loaded into four memory addresses on the ESP32.

| Address    | File                     |
| 0x1000     | bootloader_dio_40m.bin   |
| 0x8000     | partitions.bin           |
| 0xe000     | boot_app0.bin            |
| 0x10000    | firmware.bin             |

You can upload these files to the ESP32 that’s inside a PolargraphSD machine using a few methods.

ESP32 Flash Download Tool for Windows

The easiest for people on Windows is to use the ESP32 Flash Download tool that looks like:


You might also use esptool, which is a lovely python tool that does the same thing. It’s what most toolchains use because it’s command-line driven, and cross-platform. You’d use it with a command like this:

esptool.py --chip esp32 --port "COM9" --baud 921600 
  --before default_reset --after hard_reset write_flash -z 
  --flash_mode dio --flash_freq 40m --flash_size detect 
  0x1000 bootloader_dio_40m.bin 0x8000 partitions.bin 
  0xe000 boot_app0.bin 0x10000 firmware.bin

all on one line, and once you’ve changed COM9 to the name of your serial port.


When the tool connects, it sends a message to the ESP and waits to be invited in. It prints a little progress bar like this while it does so:

If it gets to the end of the line then it’ll time out. Try that a couple of times, but if it doesn’t take on it’s own, use a cocktail stick to push the little BOOT button next to the micro-USB connector, and it’ll bump it into a upload mode.

Press reset to get back running again!

Well that happened fast

I posted a note out to the mailing list (http://eepurl.com/dhVafP to add yourself) announcing that the first eleven machines were in stock (https://polargraph.bigcartel.com/), and within two hours they had all been claimed!

I was amazed and encouraged and excited, because I was rather expecting that most of you would have given up waiting after getting almost a year’s-worth of “maybe next month” from me… So I’ve got a few left of that first batch still to pack up and post out, and then I need a bit of a pause to wait for some more lasercut parts to come in (congratulations to my lasercutting lady for her new baby – I can’t really complain too much about that delay!).

I got a big shipment of power supplies earlier this week and have half a dozen machines-worth of parts absolutely ready to go, bar acrylic cases. I’ll list those as soon as I can, and send a note out on the mailing list to those who have ticked the “tell me when you have stock” box.

Subscribe to the mailing list to be notified. If you’ve missed out this time around, please be patient. I feel very confident in this new design.

Software updates

The machines are shipping with firmware v2.0.1 onboard. This is more-or-less feature complete, matching what the old MEGA-based PolargraphSD could do. The main thing missing is the Norwegian Pixel style.

I’ve since worked up firmware v2.1.0 which reinstates the Norwegian Pixel style and also adds menus and buttons to the onboard touch interface to change machine size directly. It can also change the page size and position. This doesn’t really do anything yet, but I’m going to put a bit more thought into how the machine gets used in practice, hopefully helped by my beta testers Patrick (Wagner – Blackheart Press) and Chris (Bazant-Hegemark http://www.bazant-hegemark.com/) who will be testing this out in a workshop for The Royal Institute of Art Stockholm soon.


Since starting shipping I’ve already discovered an irritating issue where a 160 second pause randomly appears while drawing. It seems to be limited to USB traffic (I mean it doesn’t happen when drawing from SD card), and it doesn’t actually crash, it just stops to think for a couple of minutes. I’m sure this is a timer overflow or something like that, but these microcontrollers are hard to debug. That’s my number 1 priority because It Is A Stinker.

The future

Current roadmap:

  • Able to set up and specify a machine fully using the touch UI
  • Use millimetres to describe all dimensions (uses an odd mixture of mm and steps at the moment, which makes it very dependent on the physical motor setup)
  • Integrity checking: Emit warnings when the machine that’s specified in the controller doesn’t match the machine that is connected (this mismatch is the source of a lot of problems)
  • Specify and start drawings from raw image format rather than using the controller to build a queue first
    • Bitmap format drawn using norwegian style (for instance)
    • Vector drawing from raw SVG (but how to deal with shading/fill?)
  • Endstops for self-calibration and encoders for reliable long-term drawing

Subscribe for updates: http://eepurl.com/dhVafP

Touchscreen issues

I’ve had a rash of problems with the touchscreens on bare Polarshields!

Over the last six months or so, I’ve noticed an issue where the touchscreen doesn’t work after booting. It looks ok, and updates fine, just no response to tapping.

I solve this by discharging the static from the device, while it is unplugged. I do it by either leaving it for a couple of minutes, unplugged, or by touching the metal USB socket housing, and rubbing an earthed piece of metal (it’s a wall-mounted shelving rack that I know happens to be screwed into the grounded metal studding in the wall). Handle it carefully, by the edges of the board while you’re plugging it back in.

I didn’t write anything about this until now, because until recently I was hoping this was a problem that only I was having! I think the touch IC must be being blocked during it’s boot process, or something like that.

I have handled hundreds of these, and the screens actually breaking down somehow is very rare. Having them rebel against their touch programming happens every day though, and I always fix it this way.

You can test your screen by using the UTFT and UTouch example sketches, but with these updated lines:

UTFT        myGLCD(TFT01_24_8, 38, 39, 40, 41);   
UTouch      myTouch(11, 12, 18, 19, 2);

Good luck!

Polarshield now compiles in Arduino v1.6

what the hell are you doing?

Well, I’m glad you asked.

The drawing above is by Ben Young. I love it.

Released new code bundle. Only code change is that I’ve mended this line about how the crc_check pre-computed value table is defined in polargraph_server_polarshield.ino. The only purpose for this is to allow it to compile in the newest versions of the Arduino IDE (1.6x). If you aren’t using that version, you don’t need to update anything.

Also updated the UTFT library to v2.81, for the same reason (Arduino IDE 1.6 compatibility).


G-Code importing, and a bit of calibration help. Controller v1.2

I am generally filled with forboding about adding features to the Polargraph Controller. I remember it as being a twisted and unstructured wild-west kind of program. However, whenever I actually get into coding in it again, I always regret my fear, because I get something really useful done, in a really short length of time. Last weekend was no different.

Download the result: Polargraph v1.2 code bundle, or read on… If you dare.

G-Code importing

Polargraph exemplar Kongorilla has made a number of not-so-subtle hints about the impediments he runs into in getting stuff prepared for drawing. There’s a workflow that is sometimes fairly tortuous, even if it is logically straightforward. The controller has only been able to import SVG files, so a run through inkscape has always been the last step for most people.


The load vector dialog now allows .gco and .g files too, so anything that emits g-code files is also now a contender. Now, it’s fairly simplistic, understands only G0 and G1 commands, and the Z-axis implementation is rudimentary, but it does mean that it can swallow the output of wonderful things like Dullbits’ beautiful Death-To-Sharpie sketch.

The Z axis automatically makes a choice about when the pen is up or down. The very first Z axis change is ignored, and the second one is used henceforth as the “down” (drawing) position. Any position other than that second position is considered a travel (non-drawing_ position. This is because dullbits has Z1.0 as it’s drawing position and Z0 for travel, whereas inkscape(‘s gcodetools) seems to have Z-0.125000 as it’s drawing position, and moved to Z5.0 for travel. So opposite directions.

Usually the first Z movement is to shift into travel mode, in order to safely get to the start point, and then the second Z movement is to drop the pen / tool. Scripts that have funky stuff going on in their Z movement might need a bit of manual editing to work.

It’s immediately become obvious that .gco is not a standard enough file extension, so I’ll change it to .gcode as well for the next release. For now, just rename the file.

Preview cord offset

A commonly reported problem is that a drawing is short and fat, or tall and thin, or has a curved top or bottom, or it’s sides diverge.

There is a page about this in the Polargraph wiki, but it’s quite hard to diagnose, and hard to explain in words. I added this extra feature to the queue preview that allows me to simulate common calibration errors.

The way I imagine this being used, is:

  1. Draw a shape. Oh no, it’s all wrong!
  2. View the command queue in the controller app. It looks right here!
  3. Adjust the preview cord offset until it the preview matches what happened on the paper.
  4. Look at the value of preview cord offset. If it is:
    1. Positive: Your home point is further from the sprockets than you’ve told the machine. This might mean your home point is actually further down than you’ve measured, or your machine is wider than you’ve measured.
    2. Negative: Your home point is closer to the sprockets than you’ve told it. The home point might be higher up the machine than you have measured, or your machine is actually narrower than you’ve measured.


Polargraph_server_a1 has been updated to v1.2, and while there is no new functionality for UNO owners, I have merged the old MEGA-only features in, and made them configurable at compile time. So you can use polargraph_server_a1 on a MEGA, and get the SD card reading, norwegian pixel, spiral pixel etc. I actually fully expect this to have broken a load of stuff, so please take care, and report bugs.

In other news, I’ve also been working on porting the Controller to Processing 2, but that’s not borne fruit quite yet.

Download the code: Polargraph v1.2 code bundle

How to make a PolargraphSD

Just thought it might be interesting to see the steps that go into making a PolargraphSD. I’m curious about this kind of stuff, and I love work-in-progress pictures. So I assume you do too.


Apply solder paste.

Starting with the PCB mounted in a jig made of other PCBs, I use a plastic stencil, and a card to squeegee on the solder paste. This can be messy, but it’s very fast, takes less than a minute for each one.  I have taken to making up batches of 10 polarshields at a time, it takes a reasonable weekend, or a long day from beginning to end.


Sometimes bits get missing, or I accidentally rub off the paste during placing, and I use a little syringe to do touch-up stuff. Afterwards, there’s these nice little pillows of paste on all the pads.



Pick and place

I’ve got all the parts I need in little boxes, and empty out about the right amount of parts, sort through the pile and turn them over and line them up with a pair of tweezers. I used to use tweezers to place them too, but have recently got a cheap vacuum pickup tool that makes it a bit quicker.



Using magnifiers and good lighting, dealing with these tiny parts is much easier than I thought it would be.


I place most of the ICs with tweezers, because I get a bit more control over their orientation – they have a tendency to swing around a bit on the tip of the vacuum. The really big parts (electrolytic caps and the inductor) are just placed with fingers.

Soldering / reflow

I’ve got a hot air gun (Atten 858D+) that I used to take 8 minutes to melt all the solder paste on each board, and I still use that for touch-up and fixing. The last couple of batches of Polarshields have been soldered with a little home-made reflow oven though. This is a mini oven, retrofitted with a Zallus temperature controller. The temperature controller was a Kickstarter I backed at the end of last year, and it seems to work really well. Though the whole contraption looks like junk – but that’s my fault.


The boards go in two at a time, and cook for 6 minutes, releasing all kinds of (probably deadly) fumes. I only use lead-free solder in all my stuff, so it’s not the nice smell you get out of rosin-fluxed lead solder. I miss that. My old tutor told me that eating plenty of jam would help ward off the poisoning that we would all get off the solder fumes. I like the story.

Now comes the really boring bit.

Through-hole soldering

There doesn’t seem to be any way to short-cut this one, just got to cut lots of parts to length and solder them all in. Using the kind of small iron tip that is useful for touching up SMT work makes this an absolute misery, so use a big clumsy chisel tip instead to whizz through.


There are 156 points of through-holes to solder. During soldering, I sometimes spot things like this:


There’s a solder bridge between the first three pins of the IC. This is irritating, but out of 10 shields, there’s normally four or five bridges like this that need a touch-up. Fix it with some solder braid. In this case, I noticed the IC was a bit skew-whiff on it’s pads too. I am not sure if it is something about the heating profile, but it seems like the parts don’t always get “pulled” onto their pads by the solder tension during flowing. At least, not as straight as I saw when I was using the heat gun. So with this IC, I reflowed it using the heat gun, and just nudged it to straighten it up. Afterwards, I wash the board with Techspray Flux remover to clean it up. Add stepper drivers and LCD, and it’s ready to test.


Upload the latest version of polargraph_server_polarshield and see what happens. Well, I just got a white screen. So I took another look at the board and spotted another solder bridge. Fixed it.

Testing involves plugging in a couple of steppers, a servo and an SD card and running a test script from the card. If the motors move smoothly and quietly, and the servo wiggles, and the LCD responds to touch, then it’s cooked.

IMG_0043_c_pFor full PolargraphSD kits (with the motors and cables), I do another test of the same routine before I pack everything up, to make sure the particular motors and the cables are correctly constructed, and they all work together.


The case is made up of 16 laser cut parts, and is fastened together with six M3 nuts and bolts, tab and slot style. I try to leave as much of the protective film on as possible during assembly.P1050604_c_pI enjoy peeling that stuff off when I buy a new product, so I assume other people like it too. It stops my grubby fingerprints spoiling it too. I’ve got white gloves and everything, for this bit.

So now you know. Tune in next week and I’ll show you something equally as thrilling, how I clean my oven or do the hoovering or something.



Huge Portland Design Week project

It’s great to hear from polargraph people from around the world, and I was especially pleased when it turns out they’ve had zero problems, and have added their own features to the standard kit.

IMG_1725You can see this is a big machine (12ft wide, 8ft tall), drawing some promo stuff for for an agency in Portland. Notice the extra pulleys that have been added to reduce the drop of the counterweights – liking that.

This isn’t merely a really big machine though: The makers, Olivier and Evan spend 55 hours drawing the motorbike above and decided they could do better, and came up with a very sweet little script that will read your optimise the saved command queue and … make it efficient!

motorcycle_originalAbove is what the original pen path looks like. No surprise it took 55 hours really. The path planning has never been efficient, and just draws the file as it reads it, from top to bottom.

Running an exported command queue (previewed above) through this Polargraph Optimizer results in:


Which I think we can agree is much more sane. Evan reckons this is 3 1/2 times faster, and I don’t doubt it. Brilliant!

Thank you to Olivier, Evan and Squishymedia for supporting the project, and for giving back too. I’m going to try and pull those algorithms into the Polargraph controller at some point, but until then, I’d recommend that anyone doing really complex drawings should have a look at this.

Most of the things I end up talking with folks about about are troubleshooting and helping get things working, and I feel endlessly guilty about putting you through all that. It’s really gratifying and refreshing to hear success stories – and when someone cares enough to contribute, it means a lot. Even if it is embarrassing because it shows up all the bits I never got around to finishing…

Source: Polargraph Optimizer on github


Feedback in the controller

The Polargraph machine has always given useful responses, if you know where to look for them.

This last update (v1.10 polarshield, v1.9 _a1, v1.9 of the controller) introduces a machine message log that sits alongside the command queue:

feedback-line-not-on-pageErrors show up in pink. Above is an example of what could otherwise be a pretty opaque piece of non-cooperation if you didn’t know to check the debug console.

The main reason for this is to debug pixel drawing though. The relationship between pixel size, pen size and density is ultimately simple, but it is easy to find yourself in a situation where you expect a wiggle and get a straight line.

So now, when you change pen size, the machine itself replies suggesting the smallest grid you can usefully work with with this pen:
feedback-set-penwidthAnd if you try a smaller grid than recommended (or the exact size – because of rounding that happens during display, this is a bit hit-and-miss), then it draws a simple empty line on your page, and normally you’d scratch your head and wonder where your wiggle went, but now the helpful message is exposed (highlighted at the top of the message log below):


Trying one grid increment larger (9), and the complaint goes away because the pixel is now big enough to hold a wiggle:
feedback-good-sized-gridThere are three kinds of message, DEBUG, INFO and ERROR. Debug (black) should normally be hidden unless you have a verbose/debug switch turned on in your firmware. Or I’ve forgotten to turn it back off before doing the release.

Info (white) are the standard ‘might be useful’ messages. Error (pink) means specifically that something you wanted to happen didn’t happen.

I have not yet added the message prefixes to all the functions in the firmwares, but I will get around to them as required.

The examples above (vector location and pixel debugging) are now in polargraph_server_polarshield and also polargraph_server_a1 in a limited way. Polargraph_server_a1 is too pushed pushed for space to be able to sacrifice much for this, so it will never be as helpful as wasteful old polarshield can be.

Give it a shot by getting the newest code bundle.

3rd August 2014: Little update!

To clarify: This firmware IS suitable for ALL PolargraphSDs and Polarshields, new and old. The source code is configured to run on the most recent version, with the most recent version of the LCD screen.

If you’ve got an older model and you want to compile from source, pay attention to the screen type configuration settings in the main polargraph_server_polarshield.ino file. There are three possible options, the comments there should explain what’s what.