sandy

About sandy

Designer and builder of Polargraph machines, software etc.

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!

Conclusions:

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

Polargraph Stockholm

Patrick Wagner designed, organised and ran a workshop at the Royal Institute of Art Stockholm, using Polargraph machines to create beautiful marks on flat surfaces. Two brand new PolargraphSD v3.0 machines joined their lineup, and it was co-hosted by Christian Bazant-Hegemark.

You’ll know Chris from the Polargraph forum and also from his documentary series On Doubt. Patrick is a printmaker and has ran workshops with the Polargraph at the Royal Institute of Art Stockholm a couple of times already, but this was the most focussed so far. They are both creative visual artists in their own right.

Explaining the magic

This was a session for an international crowd of people who are practicing artists or also educators in the fine art field, to learn about what a drawing machine could bring to their process, and they had a great time making some wonderful marks. I was so pleased and excited to see the pictures coming out of that week long session, and glad to see that two fresh PolargraphSD v3.0s worked great, alongside a cast of existing machines. Seeing what happens when the tool is recognised for what it is, and put into the hands of people who value the act and the process as well as the outcome is absolutely thrilling!

Drawing with bleach onto fabric

Discussing the workshop with Chris and Patrick was also seriously enlightening, it collapsed a lot of waves and really clarifies my thinking. When I don’t talk to people much, my mind runs away into little cul-de-sacs where I’m making decisions without much information. I used to be the customer myself, after all, I built the machine for myself to do my own work as part of my own process. Now however, I don’t use the machine much for creative work, and so I’m easily disconnected from “the user”. Workshops like this, along with the advocacy from experts like Patrick and Chris are so useful. I had ideas for a bunch of features that I’m not going to take further, and learned ideas for a bunch I will. Unglamorous stuff like “longer power cables” or “a pause button that works”.

One of the things that often introduces a tension into my thought is imagining that buyers just want a plotter, or just want something quick, or just want something easy to understand. It’s easy to get into that thought pattern, but it does you all a disservice, and it runs quite counter to the ethos of the Polargraph. It’s a luxury to have an principled stance in commerce, but I think that’s really one of the things that makes Polargraph different to other kits. I’m simply not that interested in Polargraph being a general-purpose, high volume, fast and perfect machine that does repeatable, sharp, registered editions. It’s never going to be that. It is simply the wrong process if that’s your goal.

The lines in between are the interesting bit

While this sounds like making excuses for sloppy engineering, it isn’t. Entirely. The truth is that the quintessential Polargraph artwork is full of characteristic squiggles, blobs and patterns. It doesn’t need to be brilliantly engineered. Like Chris wonderfully summarised:

“… these artists are OK with a process taking time, with fine-tuning sometimes going wrong, with stuff not working right away. While it can be frustrating as well, artists also often benefit from such mistakes (a pen drying up during an overnight print; a badly-positioned gondola resulting in the drawing not being perfect on the paper, etc).
So I think that while every artist would always say “make the tool perfect!”, this isn’t actually what would benefit them.”

Getting news of this workshop was such a terrific validation and a glorious piece of news that really helped my bring my full enthusiasm to the launch of the new PolargraphSD v3, which I’m finally getting some reliable stock on (see here for that: https://polargraph.bigcartel.com/product/polargraphsd-v3-0-full-assembled-kit).

Patrick Wagner is blackheartpress on most social media sites:

Christian Bazant-Hegemark just has his own name across the internet:

Chris also creates the On Doubt series of interviews and vlogs, which I love, they look at the process and background for a load of really interesting and exciting creative people:

Thank you very much to Patrick and Chris for running such a good event, and thank you extra very much for the folks who attended and helped inspire me to keep building the Polargraph.

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:

esptool

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.

Connecting…_____….._____

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.

Problems

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

A good day at the office

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

Motor stepper driver surprise

Edit: A week later! I solved the problem I discovered here. Nothing to do with the stepper drivers. Everything to do with not thinking clearly enough. Software problem! – read about it here: http://www.polargraph.co.uk/2018/09/a-good-day-at-the-office/.

I had a good Saturday, trying to get to the bottom of my bumpy stepper issue.  There was some weird quantisation going on, and microstepping was really unreliable. Each full step seemed accurate, so dimensional accuracy was sound, but travelling was far from smooth.

It was also quite noisy. So my hypothesis was that the new circuits in the Polarshield v3 were different somehow, and so I wanted to do a bit more digging before deciding these boards were ready. I rigged an old PolargraphSD machine to use the stepping circuits in the new board and found the exact same problem. My heart sank.

Much as I enjoy these kinds of hacking expeditions, it makes a mess! Here’s a view of the workshop. I meant to highlight the explosion of parts on the desk, but actually it blends in perfectly with the rest of the workshop. Ok, the whole place is a mess. That’s characteristic of an research and development phase of the build. I’m sticking with that explanation.

I did a bit more testing and tried a few more things. Breathed a sigh of relief when I tried moving the stepper drivers from the old board into the new one. The machine hummed into life and delivered that buttery smooth sound I was hoping for.

I took a closer look at the stepper drivers that were in the old machine (that worked great) and the new ones. The old ones had sense resistors labelled R200 (0.2 ohms) and Allegro A4988 chips. The new ones had sense resistors labelled R10 (0.1 ohms) and a HR4988SQ chip onboard. The HR4988SQ is a near-clone of the Allegro part made by Heroic Technology (http://www.heroic.com.cn/en/products_show.asp?id=143http://www.heroic.com.cn/uploadfile/1602/05133625.PDF).

Now weirdly I’d never noticed that this was not an actual Allegro part. In old Polargraph machines it has behaved exactly as a regular Allegro part. Looking more closely at it, the HR4988SQ drivers microstep all the way up to 1/128, whereas the Allegro part only goes up to 1/16. Now although the wiring of the Polarshield configures both drivers to run at 1/8 microstepping mode, there’s obviously something else different between the way the two different boards interact with the chip. (A bit of further reading – https://www.reddit.com/r/3Dprinting/comments/75w22r/psa_hr4988_drivers_cause_noise_and_vibration/ makes me think I might try to get it up to 128 stepping instead!)

So the really good news is that I figured out a way to solve the problem. The neither-good-nor-bad news is that I still don’t really understand the issue. The bad news is that I’ve got a hundred of these HR4988 based drivers and now I don’t know if I can use them. Boo!

This morning I also beat my half-marathon time by almost two minutes. Overall, I call this a good weekend even if it is going to cost me another couple of hundred quid.

The case fits

I got some nice lasercut parts through today from nice-cuts. Nice cuts!

The case looks pretty good. I added 0.1mm to all the slots for tabs to go into. It does make for a slightly looser fit, but overall I’d rather a loose fit than a tight fit that will lead to cracking.

This is the second iteration of the case, and has a few extra hooks and holes to give mounting options. It’s getting quite close! Very exciting!

Case prototypes in cardboard

One of the challenging and exciting parts about Polargraph is trying to avoid changing things while still progressing the project. Changing things is easy enough when it comes to code (though requires re-testing), but it gets harder and more expensive (and much slower) when it’s a physical item, like the PCB or the case.

The last case was lasercut acrylic. This new one will be too, but I don’t have a laser cutter nearby, so I prototype in cardboard.

This is just the shapes printed out and stuck to the a sheet of corrugated cardboard, and cut out with a scalpel. There’s limits to what degree of realism I can achieve with this low-fidelity mockup, but I can test the major interactions.

I discovered I’d completely forgotten to put a set of tabs in on the end plates. Other than that, a bit of misalignment here and there. The files are off to the laser cutter!

In other news, I have had some good results with the new firmware (https://github.com/euphy/polargraph_server_polarshield_esp32) which has got high stepping rates, along with good responsiveness from the screen. Happy with it so far… But I haven’t tested it properly yet! Eeek!

Polarshield v3.0

The new Polarshield v3.0 is a refreshed version of the core Polargraph hardware. It has been re-designed from scratch and snips out a few of the snaggles that the old machine had.

It allows integration of:

  • Espressif ESP-32 based microcontroller
  • 2x A3988 stepper drivers
  • LCD and touchscreen
  • SD card for stored command queues
  • Servo for a pen lift

So the only real difference is the controller, which is a fast, 32-bit, dual-core device, with a real-time operating system (RTOS), oodles of memory AND built in bluetooth and wifi features. There is a working Arduino-based toolchain for this ESP-32 device, but it also has the horsepower and memory to run micropython.

I’ve ported the standard polargraph_server_polarshield code to target this platform (in a branch – https://github.com/euphy/polargraph_server_polarshield/tree/esp32) and it works great … in principle. There’s a couple of bits don’t work yet, and I haven’t done any long drawings with it.

On the Polarshield itself, the hardware design is simplified because the ESP-32 is a 3.3v device and so are the stepper drivers, touchscreen and SD card, so there’s no need for level shifting. The LCDs are of a more modern and widely supported design too, so I expect to have fewer problems with them.

There are spare pins I’ve broken out for:

  • 2x motor shaft encoders for close-loop positioning
  • End stops for automatic calibration

I haven’t yet implemented any features around the encoders, endstops, wifi or bluetooth, and might never do that.

Why the change?

The Polarshield v2 has never been a reliable build. The straw that broke the camel’s back was earlier this year when I was building a batch and I ordered 20 boards, built them and only got six working Polargraph machines out of them. The LCD that it uses is growing to be somewhat esoteric in that configuration, and so it’s hard to debug. It uses a kind of simulated SPI which just isn’t reliable enough, or has too many odd interactions with other parts of the circuit.

The new 5v step-down power supply is an economic choice. I’m using a little off-the-shelf mini-assembly with a MP2307 and an inductor on it, rather than building the supply right onto the board itself. Amazingly, the little assembly is available to buy (ready-made) for less money than it costs me to buy a single MP2307 chip on it’s own.

The ESP-32 is a little cheaper than a good Arduino Mega-2560 clone. The current Arduino toolchain is a bit of a dog to set up, but dedicated developers has done an amazing job porting libraries to it. It’s dead fast and has a good small footprint. Mega-2560s are huge. Natively running at 3.3v is a bonus and performance with SPI-based touchscreens is phenomenal.

What’s next

This is a platform that could easily take us into PolargraphPro territory, with encoders and endstops to make for a safe and reliable continuous drawing experience. The MCU is powerful and the wireless features are very tempting.

However, I have no immediate plans to implement any new features and will focus on getting old ones ported and re-worked where necessary. I’ll probably take this opportunity to dump a few lesser-used features too.

Mailing list

If you want to be alerted when these reach stock, or you’re interested in email updates about the project, you can sign up to my mailing list and choose what kind of things you want to hear about: