The bad news is I’ve got no plans to restock. My day job has grown up and I’ve run out of capacity for this project, and I miss building things that aren’t Polargraph machines!

If you’re still in the mood for a drawing machine (and why wouldn’t you be?!) then I have long looked enviously at the work of Bart Dring (inventor of makerslide, buildlog.net, polarcoaster) who was making a beauty a little while back: https://twitter.com/buildlog/status/1131942367974576129 and is active on #plottertwitter and the drawingbots community on discord. Keep your eyes peeled for his work because it’s the best.

I have stopped making machines a few times before, and it hasn’t stuck so I might be back… But I’m not expecting it. I do have a fairly big stock of motor brackets left over, so drop me an email with your address if you’d like some.

I do have other projects that I want to work on and if you’re interested in what else I get up to in the future, please have a spy at my portfolio site at http://uptomuch.co.uk or follow me on twitter (@uptomuch). Of course you can email me any time too. I’m still as interested in drawing machines as I’ve ever been and will be supporting Polargraph for a while longer.

Finally, something that looks like a payoff!

I wrote earlier this week about an experiment that seemed to indicate that my stepper drivers were at fault, and I went to bed happy that I’d at least isolated a problem and identified a way forward.

Something wasn’t right with that, and the next day I ripped out my fancy new multi-tasking code and made it just like the old Polargraph code: synchronous, single-threaded, blocking. I still had lumpy, slow drawing, but it did prove that the new approach wasn’t the problem, and that was the real breakthrough.When I moved to the ESP32, there were a lot of changes due to moving away from UTouch and UTFT, Henning Karlssen’s excellent drawing and touchscreen libraries, and towards TFT_eSPI which is a port of Adafruits GFX libraries, optimised for the ESP32. It uses real SPI and is dead fast.

But it also processes touch differently and critically, the touch sensing includes a delay of a couple of milliseconds. I was checking for touch in a function called runBackgroundProcesses() which took care of a couple of things, including screen redraws and powering down after inactivity. Because of the single-threaded nature of the Arduino MEGA, the old code needed to regularly make a call to runBackgroundProcesses even during a move, so that the screen could continue to be responsive. So the main motor running loop included a call to runBackgroundProcesses. I bisected the code a couple of times and finally, after commenting out the touch-sense section, the motors started stepping at the proper rate, accelerations all worked out well and the HR4988s were singing like birds.I was so happy! My approach with this ESP32 was to move the motor running into a task (ESP32 is a multitasking OS), and then have that task called periodically with an interrupt-driven timer. As long as this task was also processing touch – which included that couple of millisecond delay – it could never get up to the kind of speed I needed and was in constant contention and had some pretty odd results.

So the simple solution is to move these background processes out of the motor running loop and into their own actual background task. Job done, worked great, shipped two working machines to my first beta tester this morning!

Spent the rest of the day building up the next fifteen machines and hope to have half a dozen ready by the end of the week and will send out a message on the mailing list when I’ve got stock ready to move. There’s more good news: The build is reliable. None of this 50% yield nonsense. Every board I built works, so I’m a lot more confident that there might be a reliable flow of machines soon.

Sign up on the mailing list if you’d like me to let you know when that’s moving: http://eepurl.com/dhVafP

I was proud and pleased to get a copy of the 3rd edition of Discovering Drawing by Sallye Mahan-Cox through my letterbox. Not because I need to discover drawing (that ship sailed a long time ago), but because your very own Polargraph is featured as a “non-traditional approach”.

Isn’t that lovely?

The eagle-eyed among us may have noticed things happening in Polargraphland! I have listed some more machines for sale, and they’ll be shipping in the first half of April.

http://polargraph.bigcartel.com/product/polargraph-sd-assembled-tested

That’s good news! I’ve already mostly built most of a batch of 32 machines. One of the things I was pleased to get out the way quite early was printing the sprockets. I’d rebuilt my 3D printer since the last time I did it, so I had some tuning to do to get that perfect print. I didn’t want to do it because I hate the slow pain of trial and error.

Anyway, long story short, I got some settings that I was happy enough with and printed off around 80 sprockets – enough for this batch, plus some discards for quality control.

Well, I didn’t adjust the settings quite enough, because the holes in the middle are about 0.2mm too large. They get printed in batches of 16, and about two out of every batch was ok – and those were the two I tested.

The rest of them were much too loose. It makes them a really easy push-fit onto the motor shaft … and I hoped they’d be good enough, but I was making a how-to video this week and running these new sprockets and got a real sinking feeling… They aren’t good enough. There’s enough play on the shaft that the hole will eventually round out, and it’s a case of when, rather than if, the sprocket loses it’s grip. Even a dab of glue doesn’t solve it.

So it’s time to go through all my partly-packed machines and lever the sprockets off, and also run the 3D printer for the next few days to print replacements.

On one hand, it’s great that I’ve found this out, and am in a position to fix it before I’ve sent any machines out. On the other hand, I wish I had listened to my gut feeling when I printed the first set and they were only just “OK”. I was just so pleased to have fully completed one of my tasks that I dreaded going back to it.

It’s been obvious for a while that the touchscreen on the Polarshield is a bit unreliable. Every now and then, it is just unresponsive to touch, and it’s sometimes hard to coax it back into life.

(I believe this is a static electricity problem, to do with how the board is held when power is applied, the surface it is on, what kind of shoes I’m wearing, and probably the weather…)

I never have this problem while I’m using PolargraphSD machines in practice, because my machines always have a case.

If you bought a Polarshield or a vitamin kit, and you’re having problems with your touch-screen, order one and it’ll probably fix it.

• http://polargraph.bigcartel.com/product/polargraphsd-acrylic-case

I’m selling these at more-or-less cost price.

There’s a new wiki page about it too, with some low quality photographs to guide the way!:

• https://github.com/euphy/polargraph/wiki/The-PolargraphSD-case

Save

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.

Taking advice from the forum, I’ve just added a feature to autorun a file from the SD card.

If autorun.txt is on the SD card, then the machine will play it. I think I’d like a way of belaying the autorun.txt though.

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.

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.

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.

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.

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.