To be done

I considered using an expert system to monitor various items and, using built-in rules, either advise on settings or set them itself. This would require a bit of support code overhead in order to put the information into a more chatty, if you will, form. Since we're trying to control a physical system in real time, speed is necessary, so why add the chatty overhead? After all, the machine can make most of the judgments based on real-time data.

We'll still use AI techniques, but they'll be search strategy related. Instead of linked lists for data representation, we'll just use good ol' tried-and-true array processing. This will speed things up, at the expense of elegance and flexibility. Admittedly it will make fixed-data (for example, track layout structure) more difficult to store and retrieve from a file, but then, I'm not trying to develop a universal application here. ...just showing how it's done. You'll have to make plenty of changes to the code, especially the layout information, in order to fit your own layout. Sure, I'd love to develop a track diagram editor, but I'd rather get the doggone thing running trains instead of developing a commercial-grade product. ...so, "deal with it," okay? (NOTE: It is now possible to edit all of this information, including the track diagram, externally, then load it at run time. The search technique still operates on the same data, but it's stored in dynamic arrays; only the loading and output of the data are different. Rather than hack the code to alter the data, you can alter an external file with a text editor. "We call that progress.")

The "holy grail" of my project's "smarts," if you will, is having the computer run two trains in opposite directions. Automating working off a switching list is probably beyond the system's capability. We'll see, though.

Where is the AI?

Look for AI application in three areas. One is the 300 ms interrupt, which handles real-time train position information. We discuss that part in "POSITION DETECTOR Boards," in the "Detector Software" section.

A second area is the setting of gap indicators. These are located wherever any two track blocks (which differ in electrical options, such as direction, power supply, turnout setting, and occupancy) meet. The code checks to see that the two adjacent blocks match, which gives a green indication. Otherwise, they indicate red. These indications are posted when generated, but the display is not updated until done so via the 5-second interrupt.

A third area involves warnings. If there is a problem, a yellow or red indication is shown. This section is not very well developed, to be honest, and is at three overall levels- - ALARM, CAUTION, or NORMAL. I encourage you to have a look at the code and add or delete whatever you want. These indications are posted to a buffer as generated, and indications are shown via the 5-second interrupt.

A fourth area indicates various power assignments, and communicates via color-codes on the track diagram. Two power packs are available, and their assignments (or no connection) are shown there. Much of this decision-making is done via clicking on the appropriate spots on the diagram, with code responding to the generated message and setting the color on the diagram. These indications are posted to a buffer as generated, and indications are shown via the 5-second interrupt.

A fifth area is under development. This approach stems from my chemical plant process control experience. On the fundamental level, a hardware controller operates a basic function such as an off-on control of a flow controller. Next level up, a level controller (which is a relatively slow-changing signal) might sense level and adjust the setting of the (rapid-response) flow controller to achieve the much-more-important level control. Imagine a bunch of these setups, arrayed through a chemical plant. Then think of power control in a model railroad, an off-on switch for a power pack, a power-pack selection switch, followed by off-on switches for the various track blocks, plus a direction switch for each block... You see where I'm headed. The higher levels are called supervisory controls. We've covered most of these in our four-level approach, so far. But these are all from the perspective of the individual items, up through the track block. What about the train?

Well, in the chemical plants, we had an overall control layer to tweak the supervisory control layer. It was based on a mathematical model of the whole process, and was slowest-acting of all, so as "not to destroy and rebuild the world for dime." In our model railroad, this would be the layer that, from the railroad engineer's and traffic controller's standpoint, effectively "rides in the cab" and ensures that the train gets there safely and on time, avoiding collisions, speed restrictions, derailments... You get the idea.

We don't have that quite yet, but I hope to get there before long. Keep that objective in mind, please.

Click here to see the details about Motor Regulation