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