sandy

About sandy

Designer and builder of Polargraph machines, software etc.

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

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:

Polargraph, back in action

Without much fanfare, I reopened for business last month! I had a waiting list, so gave those people first dibs before announcing it widely.

But the first dozen machines are delivered now, and I’ve just listed the next ten in the usual place:

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

In an embarrassing twist, I accepted the challenge of making some videos to show what the machine is, and how it goes together.

Oh, er, there’s more of my gurning fizzgog:

And just when you’d had enough … more:

Sorry about that.

Quality control is frustrating

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.

The holes in all these sprockets is 0.2mm too large.

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.