Encapsulate The Concept That Varies

One of my favorite Object-Oriented Design themes is "encapsulate the concept that varies". You may need an algorithm of some kind that needs to process data or run a calculation. There may be several solutions to the problem. The code that needs to make use of the algorithm should not need to know how it's implemented. The way the algorithm is used might be called its "public interface". If the thing we are building is a toaster, the method it uses to make the toast is something we don't know or care about. We just use the public interface by turning the dial and pushing the lever down.

I wrote some time ago that I'll need a robust, compact serial protocol for communications between the host and microcontroller. I'm still looking for something I can use that someone else wrote. In the meantime I need my computers communicating so I'm just using a basic character-based protocol. I intend to replace this later with a binary protocol of some kind hopefully with error checking.

The public interface is pretty simple. Each "request" and "response" consists of a "command" and an "argument" (or parameter depending on your perspective). Both elements are numbers (integers). The command is a number from 1 - 255. The argument is +/- 2 billion. The command may be something like "initialize program" or "set target period". The argument is a value for a set command. The logic on the host and microcontroller each have functions to send and receive this command/argument statement. The implementation of these functions is pretty simple, basically read/write (print) statements on the serial line.

In the future all I will need to change are these 4 functions. The logic that calls these functions will not need to change. What I could have done is issued print statements directly where I needed to in various points in the host software, for example. Then I'd need to find all those points later and rewrite them for the binary protocol. Instead, everything funnels through these functions that won't require an interface (signature) change. This is a pretty simple example of this sort of thing, for sure, but it illustrates the concept.

I wrote a simple shell program so I could type commands into the microcontroller (a benefit of the character-based protocol for development). I managed to string 2 move commands together and the steppers performed a 3-axis coordinated move for the first time. That was awesome. Time to move on to the host path generation software and start sending tool paths!

In my last post I had roughed out the LightManager. This is done now. It has a mode that is in effect when the host is sending a program to run (automatic mode). The up/down in/out lights flash rapidly and alternating like ambulance or snow plow lights. The left/right lights alternate more slowly and out of sync with the other lights like train crossing signals. It's pretty cool. I need to make a video of it.