Michael-F-Bryan

I’m Michael Bryan, a software engineer based in Perth, WA, with a passion for building resilient systems and elegant solutions. ## Professional Overview Link to heading I’m currently a Senior Software Engineer at Multiversal Ventures, primarily focused on developing robust web crawlers at scale and leveraging ML to extract information from US healthcare websites. I specialise in writing precise, maintainable code and consider myself an expert in Rust, with extensive experience in Go, TypeScript, React, and GraphQL. I’m particularly passionate about compilers, type-safe code, and designing parsers that gracefully handle errors.

This is the first installation in my Adventures in Motion Control series. At $JOB we build industrial CNC machines, and while developing a simulator for our machines I noticed a distinct lack of online resources on how they work under the hood. Hopefully this series will address the situation. ## The Goal Link to heading The goal for this series is to develop a simulator which will accurately reflect how an embedded motion controller is implemented internally.

As mentioned in the intro article, the first task will be to set up the application’s structure and define how the various components will communicate. ## Multitasking Link to heading Most embedded systems will implement multi-tasking by rapidly polling each system within an infinite loop. rust loop { poll_comms(); poll_motion_planning(); poll_io(); poll_machine_events(); } A motion controller will normally spend most of its time polling, but there are places where polling isn’t appropriate. For example, accurate movement of a stepper motor relies on sending pulses at very precise times. Another scenario is in the handling of communication, where waiting for the next poll to read a byte may result in missing part of a message.

As mentioned in the previous article the next task is to implement our first proper System, the FpsCounter. > A relatively easy, yet important, component is some sort of FPS counter. > Ideally there’ll be a bit of text in the corner showing the number of poll()s per second and the average duration. That way we can get a better > feel for our simulator’s performance characteristics. An FpsCounter has two responsibilities,

## Prelude Link to heading The Communications system is arguably one of the most important parts of our simulator. After all, it’s kinda hard to debug a program when you can’t ask it why something isn’t working. The user will interact with our simulated motion controller via a single Serial Port, which we’ll be modelling as a simple thing which sends and receives bytes. Serial ports are a fairly old technology, and have several drawbacks compared to the Ethernet and TCP protocols that most programmers are familiar with.