You'll need a good plan, first! Yeah, I jumped the gun and ordered the computer/electrical stuff quickly, but I've been doing model railroading for many years and already had a plan. ...but I DID construct a track plan, benchwork, and trackage before I bought the electronics, and you should too. Sorry that it's out of proper order, here.

Your first electrical task is to drive the relay boards that control the various track sections known as blocks. We'll also show how to set up the main electrical relays for choosing the two power packs' off/on status. Then, for each block, we'll set up a set of three relays: one each single pole, double throw (SPDT) relay to choose power off/on status and power pack choice, plus a double pole, double throw (DP/DT) relay for direction. My layout is limited to eight of these blocks by the available number of relays. There are spare SPDT relays, several of which get used for electrically connecting sidings to the blocks they are joined to. ...clear as mud, huh? You'll see. It's pretty straightforward, once you "get down in the weeds" and look at the details.

Click here to see the details about adding, setting up, and testing relay boards.

Then click here to see details about Layout Design and Electrical Design/Connections/Testing

This part gets a bit involved. Hell- - it gets REAL involved. Skip through the details, looking mainly at the structure. I've tried to keep it general for the most part, but there must be (of necessity) some array items specific to my model railroad layout. I'll try to moderate that and add comments where appropriate.

1. First, look at the overall structure. Keep in mind what's happening programmatically: how the interface is built in GLADE, how the C program incorporates the GLADE file, how "messaging" works, how arrays of pointers are used to access various user-specified input information, and how the information is displayed.

2. You'll see two types of buffers: one for the information that is displayed directly, and is checks to see that power & direction relays are set up properly, using information from user inputs via the graphical display interface (which is fairly static). You'll also see one for the dynamic information from the position detector cards (which must be "de-bounced" and is time-sensitive).

3. You'll see how to build a "Status" screen which checks that power and direction controls are set properly, and shows block occupancy. This is independent (for the most part) from the earlier code which displays relay setting information showing whether it is safe or not to cross from one track block to the next.

Click here to start reading the details about building the graphical interface.

The relay cards were driven by output signals from the graphical interface. Here' though, we need information from the position detector boards, which input information from the layout and display it in the graphic interface.

1. The electronics are described, including how they are hooked up to the RasPi expansion boards. Commercial detector boards are described, as are the commercially-supplied voltage converter boards that change 12-volt signals to the 5-volt signals needed by the expansion boards.

2. Here, we add C code to read the position detector signals and interpret them. Train position changes with time, so we need time signals. Trains vary in length, so we need multiple detector signals. Detector input is done via phototransistors positioned at electrical gaps in the track (electrical blocks), so we need to know where they are located.

3. There's also a speed estimation which has to be calculated by knowing where the train is and how long it takes to travel from one detector to the next.

I was once in charge of rolling out Artificial Intelligence for portions of a large multi-national chemical company. "Back in the day," as the phrase goes, everyone in industry was looking at it and trying to see how it could make amazing amounts of money. Unfortunately, for large companies, you get a two-year shot at new technology and if it's not making so much money that they want to get into that particular business, management "pulls the plug." Usually that comes with the phrase, "That's not what our main business is." ...sour grapes? Maybe, but if your management doesn't want to try new things, your business will die. ...which is exactly what that company did. They hired McKinsey & Associates to provide "a unique solution" (just like everybody else's, usually), which later resulted in breaking a vertically-integrated corporation into nine separate "silos" and selling each one off. As it followed, several of the separate entities either went bankrupt and were sold for scrap or continued selling to each other through middle men, who were the ones ultimately making the profits. For a good understanding, see the Broadway play, later a motion picture starring Danny Devito, called "Other People's Money." (His character was called "Larry the Liquidator.") in the process, they selectively promoted a few token women and minorities early, laid off or forced to retire a considerable number of employees (including their most experienced ones), cut reinvestment severely, and paid high management lots of "golden parachute" money.

...sound familiar? The entire oil and chemical industry industry went through this process worldwide. What companies are left are considerably weaker. See also other heavy industries- - steel, mining, textiles, oil exploration, to name a few. I'll venture to say that Amoco and Halliburton both underwent that process, got rid of their experienced employees, and a much leaner Amoco sold out to British Petroleum. The inexperienced people left "fumbled the ball," resulting in the Deep Water Horizon oil spill.

Okay, enough of my rant and back to Artificial Intelligence (AI). We built a number of so-called "expert systems," computer code that was fairly easy to put together given template tools, which captured the knowledge of experienced people to troubleshoot various manufacturing processes. I took over a program in the former Fibers & Film Division of Hoechst Celanese. We quantified the benefits of getting employee groups together, laying out the problems, and figuring out solutions. Savings were considerable, although minor compared with the sales revenue from the products involved. Add to that the issue that, once a problem was solved and codified, we were done and didn't need the expert system. Nearly all were "put on the shelf" for a future day when the experienced folks were gone and the problem recurred.

"...not our business." The effort came to a halt within two years. Another five years saw the whole multi-national corporation being busted up. The "bloom was off the rose" across industry. AI was pretty much placed o the shelf. But years later, a new breed of so-called AI came on the scene, based on the idea that any operation sufficiently detailed and frequently occurring and repetitive was a good application for computers, allegedly AI. Another good example is optimization- - given several options, which one maximizes profit while remaining inside various constraints. (This is traditionally called "Operations Research" in the world of mathematics.)

An illustration of this type of logistics planning-and-scheduling problems that I worked on in my later years: given a series of orders, how do you make sure that all the materials arrive and are available when and where needed, when is equipment available, and how much can you ram through (or how far can you cut back and still remain profitable). A specialty polymer that we were making on equipment with only limited capacity and availability is a good example. Another, which I worked on as a consultant, involved assembling supplies for a Bill of Materials, getting it to the right location at the right time (or last minute), and building and shipping or warehousing product to fill a wide variety of anticipated, existing, or overdue orders.

So, what does this have to do with model railroading? Well, if you've read this far, you realize that there are occupancy, power supply, direction, turnout alignment decisions to be made, and electrical equipment to be set appropriately. There are origins and destinations to set There are collisions to avoid. There are train "consists" to assemble, transport, and distribute. That's what real railroads do, and we modelers should do it too. We don't have to reinvent the wheel, but we do have to be innovative in how we accomplish these tasks.

So, for our AI application, we will build an expert system that replaces some of the hard-coded logic that we've used so far, so we can say, for example:

"IF there exists a train at a location to be found which is approaching a track block boundary and it's short enough to fit in the next block and there's a turnout location which needs to be corrected, THEN...[some action is taken here]"

A series of hopefully easy-to-code rules of this form checks to see that all rules "in the conflict set" (terminology for the set of all rules that need to be considered at the moment) get satisfied (and thus removed from the conflict set). This process continues until all rules are satisfied and the conflict set is empty, at which the system waits in its' loop until more rules are presented. Typically, the system works through a set of supposed delivery orders, identifies appropriate train cars at various locations, assembles them into a train, dispatches the train to drop off the cars at appropriate locations, then goes back to "home base." An auxiliary program specified by the modeler generates various orders at various times. The AI system generates appropriate reports.

As you can see, you can spend an inordinate amount of time (substitute the word "entertainment"?) building a computerized system like this. At the end, though, maybe you can sell it to Union Pacific or Amtrak or somebody. It's fun to think about, anyway.

So, read on. There's plenty of suggestions and example code in the sub-pages.

to be written

to be written

to be written