Embedded Systems on Michael-F-Bryan

Implementing ArrayVec Using Const Generics

Fri, 15 Nov 2019 00:57:00 +0800

If you’ve ever done much embedded programming in Rust, you’ve most probably run across the arrayvec crate before. It’s awesome. The main purpose of the crate is to provide the ArrayVec type, which is essentially like Vec<T> from the standard library, but backed by an array instead of some memory on the heap.

One of the problems I ran into while writing the Motion Planning chapter of my Adventures in Motion Control was deciding how far ahead my motion planner should plan.

Initial Motion System

Wed, 18 Sep 2019 20:00:00 +0800

Now we’ve got some simple automation code, lets start a proper Motion system.

Most Motion systems are designed around a “control mode”, a fancy term for “what is the machine doing right now?” Common control modes are:

Idle - the default control mode, machines revert to Idle whenever they’re not doing anything
Automation - running an automation sequence
Recipe - executing a job (a set of instructions for how to execute a job and the motion parameters that should be used is often referred to as a Recipe)
Manual - manual movement, where velocity may be controlled via a handset or the user invokes a “jog to position” function

There are several ways to transition between control modes.

Simple Automation Sequences

Sat, 14 Sep 2019 23:55:00 +0800

Now we can communicate with the outside world, let’s start interacting with the “hardware” attached to our motion controller. This will be the beginning of our Motion system.

The simplest way to interact with the world is by executing a pre-defined routine, and one of the simplest useful routines is to move all axes to the home position.

System Inputs and Outputs Link to heading

From our initial requirements gathering we know that our 3D printer will have three linear axes (X, Y, and Z), with limit switches at the ends of each axis. This gives our new Motion system six inputs to deal with.

The Communications System: Part 1

Fri, 06 Sep 2019 23:00:00 +0800

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.

Top-Level Infrastructure

Mon, 02 Sep 2019 21:22:30 +0800

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.

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.

Announcing Adventures in Motion Control

Sun, 01 Sep 2019 16:27:15 +0800

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.