In the beginning I was cleaning house, trying to get rid of boxes of stuff I have not opened sense my last move, or before. I stumbled across an old school project from 40+ years ago (1979-80). The project was from a software course learning about programming a "state machine." A state machine is an approach to control some real-world process with software. The concept is that what is done, which routine is run, depends on the current "state" of the process being controlled and what just happened; The program then starts a motor, opens a valve, flips a switch, yells help, changes the "state" and waits for the next thing to happen. Examples would be a processing plant like a refinery or say Three Mile Island. Not having a nuclear reactor to play with we controlled a small model railroad (RR).
The model RR had an oval track, four switches, an "X" in the middle and some sensors to monitor the movement of two locomotives. One train was to go around the oval, the other was to travel a figure-8. The problem was to design a software state machine to start/stop each train and flip the four switches so that the trains travel their assigned route without "meeting on the grass" (running into each other).
The track was divided into eight "zones" or blocks in RR terms. A train in a given block was controlled by turning on/off and changing the polarity of the DC power applied to the block. Each block had a sensor to detect if a train was in (the middle of) that block. We got extra credit if we could avoid stopping the trains by varying their speed. So, we had eight sections of track and four switches to control the path of two trains based on information obtained from eight sensors. In model railroad terms this was an "old school" DC layout where to keep control of things you could only have one train in a block of track because we didn't really control the trains. We controlled the power to the block. That powered all trains in that block. This also models real world absolute block control of trains.
Digging into the grass one train could be on any of the eight blocks going CW or CCW giving 16 possible conditions or states for that train. The second train could then be on any of the other seven blocks also going CW or CCW giving 14 possible conditions. This implies a daunting 224 possible states or a 224 x 8 matrix of states and routines (224 old states X 8 sensors). A little analysis shows there is lots of empty space in that matrix. For example, the train going around the oval can only go CW or CCW around, not both. The train on the oval should never be on the "X" in the middle. Additionally, a train in say block #3 headed for block #4 cannot magically appear in a block other than block #4, unless you believe in divine intervention. And there are some states to be avoided, for example train in block #3 facing the other train coming from block #4!
Not wanting to clean house (any excuse will do), I got to thinking about the old project and some embellishments. Why not a double oval with crossovers so four trains can travel large and small ovals and figure-8s? This though exercise resulted in 16 blocks of track, 12 switches and the one crossover to control. If we had stopped there this might not have been too bad. But of course, being a thought experiment, embellishment don't cost anything. So, instead of just one sensor in the middle of each block why not a sensor at each end of each of the 16 blocks? Or a "bar code reader" so the program doesn't have to remember which train is where?
I remember one of the things I did not like about the old college project was the undefined beginning and ending. So why not have a "parking place" for the trains to start from? Then to start, randomly assign a path to each train. Turns out this was not that hard to add to the simulation I started building. Bolstered by that success what about the other end? If done correctly, the trains should run for ever. But that is a long time and gets boring. So why not having a software stop button? When I get bored watching the trains, I could push the button and the trains would return to the 'parking lot' and stop in their assigned parking/starting location. Turns out this is not as easy.
With a 'parking lot' (staging yard) there are 384 starting conditions: The first train in line can be assigned one of 8 possible tasks, the big oval, small oval, big figure-8 or small figure-8. These four paths can be traveled CW or CCW. The second train in line can then be assigned one of the six remaining tasks, the third train can be assigned one of four tasks and finely the fourth train can be assigned the last path as a task either CW or CCW. (8x6x4x2= 384). After getting started, like we did before, the first train can be on one of 16 blocks of track going CW or CCW, 32 "states." The second train with 15 blocks of track, etc. can be in 30 states and so on. That results in 698,880 possible states for the four trains. Again, lots of blank space in that matrix. To end in the parking lot, would require going from one of the 698,880 random states to one state with the trains parked in the same order as they started. Starting from 384 possible conditions, moving into some portion of half a million states to control so the trains keep moving but don't "meeting on the grass" and then from one of those states to parked in order: Now that starts to sound like something to analyses and simulate with software. Build and run??
I did some internet surfing (always dangerous). I saw some model layouts with red, yellow and green signal lights (aspects in RR lingo). In some real world railroads the aspect of the signal would tell the engineer if they could run their train into the next block (green) or not (red) or they should reduce speed or expect a red aspect ahead (yellow). This sounded fun and after controlling the trains I thought I would already know what to display. While folding clothes I realized that many of the pictures/youtube examples of model RR signals were taken down at the "engineer's" eye level. Well, I an't doin' that! What about semaphore signals so the aspect can be seen from a bird's eye view? Seems that most models are simple up/down red/green semaphores. Modelers like the lights, they are easy to control and inexpensive. I did find some 3-aspect semaphores; Not as easy to control and they are brass...bring your first born as barter.
Then I stumbled onto DCC, Digital Command Control: The network of everything for model railroads. Hardware cost goes up from here but DCC sounds better than the old DC model railroads.
We will see how this document develops. Not sure how I feel about a blog type of thing. HelpNDoc is a tool I have used before for context help for SW applications. Guess this will be more the documentation part of HelpNDoc. Having seen some old family journals this may follow a similar path: 'Page 1, going to write a journal. Today I did...'. 'Page 2, today's weather was nice' (the rest of the pages are blank.)
Note To railroad buffs and modelers: This project in neither; I don't think there is a prototype for this track layout and there will be no scenery. What this is, is a process control software exercise. I needed a "process" to control, and a model railroad works. Model RR has a controllable self-propelled element, locos, and pathways and path controls, track & turnouts, all of which I do not need to design nor build. I chose the Plymouth ML-8 Industrial Switcher for its short wheelbase; price and I could get 4 different colors. I was thinking that the short wheelbase would let me make a smaller/tighter layout. The ML-8 entered the inventory about 1920 so semaphores may happen to be date appropriate. Despite cost, the aspects of semaphores are visible from above.
On the other hand, railroad modelers may find the hardware and software used to control the model train (the process) informative. A large part of the hardware techniques I use were found on the internet. I have tried to give credit for the seed of an idea, or an approach used in whole. When I came across JMRI, DCC++ and the youtube demos I almost stopped, not wanting to reinvent the wheel. With all the features and functions, it was not clear that the scripts could resolve the dynamic overlapping train routes. Stopped looking at this aspect after watching the demos of the N scale layout with 'three none overlapping routes.'