Close

Software overview

A project log for Microfluidics control system

An all-in-one solution for controlling microfluidic chips

Craig WatsonCraig Watson 10/13/2017 at 15:240 Comments

In parallel with the PCB design (or rather, while waiting for the boards to arrive), I worked on the software design.

Here is roughly what the overall software architecture looks like:

Basically, the idea is to have a GUI that allows manual control of each electromechanical component, displays the status of each component (e.g on/off for the pumps, open/closed for the valves), and can store sequences of actions ("routines", in the diagram) as a way to automate experiments.

For each action, e.g "open valve 12", the PC sends a command to the microcontroller which executes it, then sends back the component's new value. The microcontroller also sends the current recorded pressures at regular intervals, whether or not the setpoints have changed.

I decided to have the PC side handle routines, as that would make it easier for end-users to work with them (no need to reprogram the microcontroller to modify an experiment) and to simplify the serial communication. This means that there is a fairly small number of things that can be sent over serial. The PC can request:

And the microcontroller can send the current status of a component.

I'm sure there are many ways of doing this; I wanted to make the communication as fast as possible while still being somewhat human-readable and easy to modify. 

The way I settled on was to send two bytes for each command: the first byte designates the component, and the second byte the value. The same values can be used by the PC to request a component change, and by the microcontroller to indicate a component's current status. This way, I would transmit a very small amount of data each time, and keep processing times low -- at least compared to something like parsing a JSON request.

For readability, a file defines a list of constants, defining e.g VALVE12, PUMP2 and so on. Of course, this file has to be on both the microcontroller and PC side, which means there is an extra step if these values need to be modified, but I felt that this was a low price to pay for speed.

In the next log, we'll take a closer look at the microcontroller side of things.

Discussions