News nobody is surprised by: Polargraph building on hiatus!

Things have changed for me in since 2012 when I first started making Polargraph machines. My day job has changed and takes a lot more of my mental energy now. I miss having time to develop new aspects of Polargraph, and to work on new projects. I spend more time now looking after myself, getting my piano practice in, or running complaining about sore legs.

When I finished the most recent batch of Polargraph machines in June, I was collecting interest, and suggesting “July probably” for the next batch. That turned into “maybe August”, then “could be September or October”, and now I’m going with “perhaps 2017”.

The scale of each batch has increased each time, and led to a build becoming a fairly intense, time consuming process that disrupted, rather than complemented my life. At the same time, I’ve streamlined it to get more done in less time, and that’s led to it becoming more mechanical. Pleasurable in a way, but numbing in another way.

I’ve been able to do other projects in between, like my circuit portrait screen prints, and a bit of research and development on Polargraph hardware features like endstops, and the odd enhancement to the software. I’ve dared to play Rocket League recently, the wastefulness of which would have had me collapsed in paroxysms of guilt this time last year.

So if you’re waiting for a machine, then you might have to wait a long time. That said, I have got a new batch of PCBs on their way, and having those in stock usually prompts some activity in that direction. On the other hand, I’ve also got a Sinclair Spectrum Issue One circuitboard to print, and a TB-303 to trace, and a Gameboy and a NES to strip and scan, so there’s competition for attention.

Last of the current batch!

So in April I decided to start making Polargraph machines in batches, optimising for throughput rather than flexibility. Previously they were made up one by one, in response to individual orders.

That batch was 20 machines, and I’ve just posted the last one today. I’ll do another in the future, so drop me a line if you’d like to be part of the next batch in July.

In the meantime, I’m going to do some more Circuit Portraits.

Build automation

To assemble a Polarshield, I need to cut these strips of pin headers into strips of 8 pins. I would usually count out 8 pins, then cut with a knife, then use that resulting piece as a gauge to cut the rest of the strip. It took attention.

Just this afternoon, I took (probably less than) five minutes to make a little cutting guide out of cardboard. Bingo: An onerous job that required me to concentrate AND count (!) became something that creates a much lower cognitive load.

DSC_0362[1]

14.5 seconds to cut a full strip before, and 8 seconds to cut the strip with the guide, so it’s much faster too.

This building process is full of lessons very like this:

  • Use the right tool for the job. Example – put a fresh scalpel blade in, remember how good life can feel.
  • Make helpers for fiddly tasks. Example – this cutting jig, which is nothing more than a slot cut in some card, and some arrows drawn on.

In summary: When you’re positive that you’re cutting the right tree down, then stop to sharpen the axe.

Why did I not do this earlier?

I have never formalised my workflow. It has always been more important to me that I retained my agility to be able to make changes to the design, so building jigs and bulk-buying pre-cut parts has seemed dangerous.

Recently, I’ve made a decision to be a bit more efficient with my time, to optimise for throughput rather than flexibility, so this has led to me working on a big batch of twenty Polarshields at once, rather than just making them up in response to orders as I used to.

DSC_0364[1]There are particular bits of the build process that are fiddly and error-prone, but tolerable when I’m building only one or two of these devices. Or rather, the cost and risk of developing a jig to help is disproportionate if it is only going to be used on one circuit-board.

When it comes to adding the same part twenty times, then suddenly the cost of the jig doesn’t seem too outrageous given the benefits. In fact it seems stupid not to build a jig.

The risk is something else, and by risk I mean that I could spend an afternoon modelling a 3d printable (or laser cuttable) set of templates in order to hold the part just so, and allow me to clamp the PCB on, and then get super-accurate, repeatable solder-joints. And it’s all wasted if I mis-measure one tiny thing, or get my part thickness slightly wrong.

I have made the assumption in the past that jigs would naturally have to be super functional and professional to be worth having, they’d have to tick multiple boxes of precision, speed of use and robustness.

DSC_0363[1]

But in this case, I just used cardboard. It won’t last forever, and it’ll degrade with use, but the cost is essentially zero, and it was designed using a pencil and a ruler, not hours in front of a 3D modelling tool. It’s the 80%, and past here, there’s diminishing returns.

More obvious lessons from Polargraph.

Geomerative Polygonizer

polygonizer_lengthHave just uploaded a new code bundle, featuring:

  • A bug fix to the polargraph_server_polarshield firmware. The command to set the pen lift height wasn’t working properly. (v1.3.1)
  • New feature in Polargraph Controller, the polygonizer can now be swapped between two styles, ADAPTATIVE (0) and UNIFORMLENGTH (1) by clicking CYCLE POLYGONIZER. The latter one has a parameter too, to actually set the length (POLYGONIZER LENGTH). The pic above is shows changing the length, so you get some pretty tasty effects from it. The polygonizer is part of Geomerative, which is a beautiful library.
  • Also in Polargraph Controller, the zoom works better now. (v2.4.0)

The polygonizer work was prompted by some excellent troubleshooting by Visualbyte and DaniK on two threads in the forum:

I’m not convinced it will point-blank solve your problems, but gives you an extra tool to experiment with.

This bundle (2016-03-29-10-23) contains the updates

(But here’s a link to the most recent release to help this post stay relevant in the future.)

 

Let us try again

Sigh…

Polargraph controller 2.3.0

  • Added: Density preview is now posterized by default, and is linked to the
    pen width setting. So should be able to use this to better visualise the link
    between pen width and grid size.
  • Fixed: Queue preview bug: http://www.polargraph.co.uk/forum/polargraphs-group2/code-software-forum2/updated-controller-thread504.0/#postid-2938
    thanks jbscribble.
  • Fixed: Slight improvement in pixel rendering speed.

Experiments in the controller, and now buildable in Arduino v1.6.6+

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

Updated firmware for Polarshield v1.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.

 

Significant changes to UNO firmware – please help test!

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

(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”).

Running Polargraph on RAMPS

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.