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.

Polarshield v2.4 compared

I got a pile of boards back from the maker recently: Polarshield v2.4 (https://github.com/euphy/polarshield_hardware). Here it is alongside the 2.2 version (on the left)  to show the progress.

Polarshield v2.4 (compared to 2.2)

Not much right? There’s no revolution, indeed, but a couple of minor changes that makes it easier to build.

  1. More surface mount parts. The tactile switch in the top-left is now surface mount. SMT parts are just quicker to work with.
  2. Moved the microstepping jumper solder pads to the back of the board, and freed up a load of space.
  3. Squished four of the 1k resistors into another 4-row resistor network. This is the smallest part I’ve ever used, 2x1mm, you can barely see them on the picture. There’s one between the two motor driver sockets, and there’s another below the stack of LEDs on the top-left. This makes pick-and-place much faster. I’m not convinced the super-high density was a good idea though – it is far less tolerant of sloppy placing / solder paste application. We’ll see.
  4. Better designed for soldering with hot air, and iron. Some of the traces on the board were sometimes difficult to heat effectively, without also over-heating the component. The electrolytic capacitors were particularly problematic. I’ve routed the traces less efficiently in some cases, so that they have more copper that I can heat with the hot air pencil.
  5. LEDs are all orientated in the same direction. The old board has them pointing everywhere, so I was always spinning the board around. v2.4 has the anode to the right-hand side in every case. It’s to reduce the chance for placing errors.
  6. The holes for the DC power jack are placed off-centre, so the solder tabs are a friction fit. It makes the part self-aligning. Nice work sparkfun!

And the great thing is, it works, ha!

I’ve been taking some time off the Polargraph shop lately, because of work pressures and a couple of other things. It’s been really nice not to have to rush to the workshop every hour of the day to keep on top of things, and I’ve been able to do a little development here and there.

I think I’ll be back eventually, but maybe in a couple of weeks, and I might try a different manufacturing pattern.

Labelling evolution

My manufacturing process is always sometimes evolving. It’s not a complicated one, but there’s enough steps and nuance that I benefit from reminding myself what I’m supposed to be doing.

A run of bad Polarshields last year prompted me to start being a lot more careful about how I assembled and recorded the assembly of them. I started putting little journals on each one, which were just a strip of sticky tape with any story on them. Anybody who bought a Polarshield will have found such a thing.

Quality control labelling on Polargraph gear

I recently kicked myself a couple of times in a row when I thought I’d forgotten to test a certain aspect of the board, and had to open up a pile of sealed parcels to find out. Fortunately in that case, there was no problem, but I made up some new labels to help me not make a mess in the future.

The evolution is in the pic. The QR takes you to Building a Polargraph from a vitamin kit on the wiki. The final version is less handsome, but more useful, and there’s a beauty in that trade-off.

I like seeing these kinds of “work in progress” pics on other makers’ blogs.

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.

 

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

https://github.com/euphy/polargraphcontroller/releases/latest