Monthly Archives: September 2018

A good day at the office

Posted on by

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

Posted on by

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: https://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=143 – http://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.