Made up a new code bundle, wrapping up a couple of recent changes.

• Firmwares are now all buildable in Arduino IDE v1.6.6+.
• The polargraph_server_polarshield firmware now uses the same kind of communications protocol as the _a1 variation. This is a little experimental, so let’s give it a shot.
• The controller console is back! In a bit of a reduced form anyway. We’ll see if it’s worth anything. Ctrl-C.
• There’s a posterisation option for the pixel density preview. You might use this to visualise how a compressed dynamic range will affect your drawing. You get a compressed dynamic range when you use very small grid size, or a big pen. It’s not linked to pen size yet, but that’s the obvious thing to do next.

https://github.com/euphy/polargraphcontroller/releases/tag/v2.2.2

Given recent discoveries, I wonder if the spate of recent touchscreen problems (see http://www.polargraph.co.uk/2015/10/touchscreen-issues/) are to do with the weird startup problem that I described in that post, OR to do with the base stupidity I displayed by including a in-development version of the polargraph_server_polarshield firmware.

It actually had USE_LCD turned off in it.

So that’ll make sense.

I’ve fixed it, rebuilt it and repackaged it and apologise if this made you mad.

https://github.com/euphy/polargraphcontroller/releases/tag/2015-11-10-23-07

An interesting discovery is that the newest version of Arduino IDE (1.6.6 – it’s only a week or two old) CANNOT compile Polargraph firmware. So, thanks Arduino dudes, for breaking everything again – it looks like two can play that game.

So use Arduino IDE v1.6.5. Until I figure out what’s screwed.

Update 19th Sept 2014!

Thanks to billc and rincey12 on the forum for finding that penlift commands without height parameters didn’t work (https://github.com/euphy/polargraph_server_a1/issues/2). This was a leftover bug from the switch from Strings to char-arrays.

Code updated, and software bundle re-bundled.

My country is voting for independence, or not, right now. Quite exciting.

Update 18th Sept 2014!

There was a silly bug in the controller that broke vector drawing for most of you. Silly bug! Quickly fixed, sorry about that. (forum link)

Hello, after chatting on the forum, and working with jhndrx, I have made a fairly minor but important change to the UNO version of the Polargraph server firmware.

Short version:

The Adafruit Motorshield v2 is now usable in a sensible way, you don’t have to sacrifice features, or chop bits of the code out to use it. If you have a motorshield v2 (AFMS2), then please try the new polarshield_a1 code and see how it works out for you. I have tested that it compiles and runs, but I don’t currently have an UNO with a AFMS2 on it.

There is a very small change in the controller to support this minor change in the comms protocol (more on that later), so grab that too

• source code
• precompiled binaries (bundle)

(This is significant ONLY for folks who are using Adafruit Motorshield v2 on UNO. It all already worked for you other guys. The stylistic changes will eventually filter through to the polarshield branch too.)

What’s changed

It is more memory efficient

It uses and reuses one char array for the incoming command instead of a load of Strings scattered throughout the program. This means less SRAM (the volatile run-time memory) is needed and wasted.

No more checksums

Funny story. The checksum is a number added to the end of each polargraph command by the controller. It was added back in the day because commands were getting mangled during transmission, and I needed a way to make sure the command had finished properly. Totally did that, and made the system pretty robust, but in the process it gobbled up a lump of memory.

Well, looking back at this code, with the benefit of great troubleshooting and some pointers by jhndrx from offof the forum (thank you so much), there was one critical problem: The firmware looped through the incoming chars in the serial buffer, adding each character into it’s command buffer, and considered the command complete when when it got either 1) a termination character (10 / 13) OR 2) the buffer was empty. Well, this made the timing of the buffer pretty critical because if I took characters off the buffer faster than the controller could load them on, then the command was prematurely ended, and so I added a 1ms delay into the loop to make sure the queue never starved. I never really understood why it was necessary until now, and it means the reading is slower than it needs to be too.

Ah, turns out the controller NEVER actually sent a termination character, and the queue running dry was the ONLY way a command ever actually got terminated. I had assumed that a Serialport.writeln(…) did it. Maybe it does. But I was using a write(..) in the controller. Maximum Duh. So this has been a serious flaw for as long as there has been Polargraph, and I’m really happy to have found it. A bit embarrassed, but hey ho. The fix to the controller has been pushed to the controller repo.

What else

Learned a load of new stuff about the built in C functions for dealing with strings (lower-case “s”).

There’s been a bit of discussion on the forum about the adaptations required to run the Polargraph firmware on RAMPS. The good news is it’s easy. I’ve just committed some changes to the polargraph_server_polarshield firmware that should make it easier to run on different hardware other than the Polarshield.

There is a little chunk of code like this in the main polargraph_server_polarshield.ino file:

#ifndef MOTHERBOARD
#define MOTHERBOARD POLARSHIELD
//#define MOTHERBOARD RAMPS14
#endif

Comment out the POLARSHIELD line and comment in the RAMPS14 line, and your machine will be rigged for RAMPS. See this Polargraph wiki article wot I wrote up.

So I’ve finally been able to step away from the new installation that I’ve been building to be presented as part of the Edinburgh Science Festival, in the Grand Gallery in the National Museum of Scotland. It’s pretty swish.

A little PC inside uses a webcam to detect faces in the crowd, and the faces that stay still are snapped, cropped, converted to line art and then drawn out on one of the two drawing machines either side.

The machines themselves are a new prototype breed of Polargraph, with Teensy 3s at their hearts, and Easy Drivers doing the moving. The guts of them are laid out as on an dissection table.

The drive chain consists of a stepper motor and an optical encoder, coupled by the beaded cord. The encoder keeps track of the true position of the cord, and so these machines are wonderfully robust. They can hop and skip, get pulled around and abused and they do not lose position.

Small magnets sewn onto the cord, and reed switches above the encoder wheel make self-homing trivial.

The pen lift is half a lolly stick, hot-glued onto a servo motor, blu-tacked onto the gondola.

The controller is a Python Flask web app, publishing its interface as a web page. It is very simple at the moment, but is pretty extensible. Part of the app is a core class that encapsulates the communications, queueing and commands. Writing this in Python rather than Processing / Java has been a resoundingly positive experience (less so actually installing Python and it’s libraries on Windows – but you win some, you lose some).

The firmware is a stripped-back version of the standard Polargraph firmware, using a couple of nice Teensy features – namely the IntervalTimer library to deal with serial concurrent serial comms.

• Code for Polarweb (the controller web application).
• Firmware for Teensy3 Polargraph

The Making It exhibition runs from the 5th to the 20th of April, in the Grand Gallery of the National Museum of Scotland. It is presented by the Edinburgh International Science Festival. You should go and see it!

It was grand to see one of our gondolas pop up while out on safari:

Dan of Maniacal Labs has put together a nice drawbot with a Go / Pi based control system. There’s still a microcontroller in the mix, and a couple of Brian Schmalz’s BigEasyDrivers.

Enter the Polar Giraffe!

Happy New Years Polargraphers!

So I got a recent report from a soul who was impeded by an SD card not reading in his new PolargraphSD machine… And these are cards that I’d supplied along with the kit mind, so you’d expect them to work right?

Well, I did too. I could replicate his issue perfectly – New 4GB Kingston SDHC card (from this giant batch I’d patted myself on the back for getting such a good price on, and so many!…), that shows up during the Polargraph boot sequence as having no usable partition. Oh. Yet try the same card in an older machine kit and it shows up fine. Huh. What’s that, ah the touchscreen (which incorporates the SD reader, and I buy as a discrete unit) is now v1.3 rather than v1.2. Hm. I hadn’t noticed that.

Yet the 4GB cards work fine in everything else I put them in, they read and write and format fine on a computer. So that’s a problem. Luckily for me (and the next couple of orders) I _do_ have some spare 2Gb cards that work fine, so it’ll not slow delivery, and of course I’ll be sending a replacement out to anybody who has got one of these 4Gb cards late in December. That was obviously a goof.

Furthermore, the 4GB card works ok when powered over USB, but not if a higher-voltage supply is connected as well (or instead of). It’s a power supply or signal level issue.

In software, this kind of regression testing is second nature, in hardware, I suppose it should be an even higher priority because the stakes are even higher. In software, unit tests can be rattled out in an afternoon, and can be messed up a hundred times with only a time penalty. In hardware mistakes are expensive, and making up test jigs is another venue for mistakes to occur in.

None of that is an excuse, it’s just a convenient explanation that I’d give to the pointy-haired boss (which in this case .. is myself …  that’s frightening). It sounds comically like the same excuses I’d give to bosses in bygone times about why it wasn’t worth doing unit testing in software, ha. Embarrassing.

The devil here, if we must have one, is in the detail lost during the commoditisation, homogenisation of resources and products – On paper, v1.2 and v1.3 of the reader are identical, and the SD cards also are identical. No reason to think they wouldn’t work together.

So, the takeaway is that if you ordered a PolargraphSD and got an SD card that isn’t working in it, and I haven’t already been in touch with you, drop me a line, or buy a replacement 2GB SD card and bill me!

The reason I’m dwelling on these issues of delays and problems so much, is not [just] because I’m a masochist, it’s because I think it might be useful for other folks who are venturing down this same kind of path as I am. Not helpful directly, but I admit I always found the war stories inspiring.

Ha, so the good news is that I got the fixed v1.5 Polarshields back, and so far they are looking good.

Not properly tested the motors yet, but so far, so good.

I’m going to be away for a week though so I am not going to have much time to work on this.  One of the things I’ll being doing next Sunday is showing a different project at a Hack Circus event in London.

Linear Clock is like a circular clock, but unrolled.  It’s a project from a while ago that I recently revived, and I’ll be doing a show and tell.

That’s Sunday, 6th of October, between 2 in the afternoon and 6 o’clock in the evening. It’s in the back bar of the Star of Kings pub, Kings Cross, London.  Tickets can only be bought ahead of time at this site, and I think it’ll be a lot of funny, as well as jolly interesting.

Please come along and see what happens, if you like technology, speculation, funny things, theremins, the phenomenal Sarah Angliss, or chat with brainy folks.  It will be lovely to meet you.

• Tickets
• Website
• Newsletter

Today I am very pleased to report on a great looking and useful setup guide by forum member Gontiki.  He’s had lots of challenging questions and useful suggestions on the forum, and has written up and illustrated his experiences with a PolargraphSD vitamin kit.

Great, clear photographs (they make the kit look rather pro!), and good descriptions.  I know it’s shameful to be pointing people to other sites instead of updating my own documentation and things, but there it is.

But wait!

What’s that? Another setup blog?! Yes, Julio Terra has a couple of great posts on his blog too:

He’s setting up a drawing machine at The Lab (an interaction design team, part of a big architecture firm) in New York.  Great to see his thoughts, and I am dead keen to see what kind of stuff they get up to with it.

I’m actually really pleased (and relieved) that Gontiki and Julio are having good experiences with their kits.  It’s easy for me to send machines off into the wild in their boxes and fear the worst – that they sit half-assembled in a drawer, amongst the dust of other disappointments and failed projects.  So this kind of positive feedback does me so much good, as well as being great for the project – the more people there are showing exactly how simple (and exactly how complicated) it is to set up a machine, the better.

So thank you for the therapy.

• Julio Terra’s blog
• Gontiki’s site

Of course it does.  Long time Polargraph supporter Wes Nijssen let me know about a project where he used his Polargraph machine as a large format plotter for drawing out the parts for a giant piece of papercraft (cardboardcraft) for his agency’s office.

Here’s the link to the blog post about it.

I often thought large format papercraft would be a great use of the machine, and I’m impressed that it was precise enough to do the job. Great stuff, thanks Wes!