Technical Ramblings of a Retired Chemical Engineer

= featuring =

< Computer Applications in Model Railroading >

< Sausage Making Information >

Model Railroading with Raspberry Pi: Adding EXPANSION BOARDS


As far back as I can remember, I've been interested in model railroading. Birthdays and Christmases, I received Lionel O-27 gauge items. I grew up in a railroad town in Arkansas, home of the Cotton Belt Shops (actually the St. Louis & Southwestern, now part of Southern Pacific). They actually build real steam locomotives there, "back in the day."

Both the Cotton Belt and the Missouri Pacific ran trains through the town, and downtown streets were often blocked by passing trains. It was such a common occurrence that our local Episcopal minister developed an uncanny knack for punctuating his sermons with the roar of locomotives. Afterwards, we kids would all go outside and retrieve our flattened pennies from the rails, rewards for patience while sitting through interminable Sunday morning church services.

Dad was a cotton farmer, trained in mechanical engineering. I was practically raised to study engineering, too. I'll never forget a 4th-grade "career day," when we had to write down what we wanted to be and they invited grownups from the community to come in and give group presentations. I wrote down "engineer." Come Career Day, one other kid and I were sent to a classroom where a man came in and talked to us about the Cotton Belt railroad and the jobs that their employees did. The other kid was interested in music, and had written down "conductor." Our presenter emphasized the role of railroad engineers and railroad conductors in rail transportation. So much for Career Day in a railroad town.

Through my early years, I went through a series of Lionel O-27 gauge and HO gauge layouts. I had withdrawal symptoms when I went off to study chemical engineering in college. After marrying, a month out of college, I build a small N-scale layout which would slide under our bed, to my wife's chagrin. Parts of that layout are still incorporated in my current layout, over 50 years later.

So, what does any of that have to do with computers and model railroading? Well, one of my areas of expertise during my chemical engineering career was application of computers to chemicals and plastics production. There were applications galore in production logistics, yield accounting, automatic process control, laboratory automation, chemical process simulation, and optimization. I like to think that I was a leader in applying everything from four-function calculators to scientific calculators to mainframes to minicomputers to PCs to microcomputers. Now that I'm retired, I tinker with 'em still.

...enter my latest fave, the Raspberry Pi, which I guess is a microcomputer. This little guy runs full-blown Linux, something I would have killed for just a few years back. What's even more amazing, though, is that it's very inexpensive and its components and accessories are widely available. The latest rage among the high school and college geek set (of which I am a proud alumnus) is robotics. Model railroading is an old man's hobby, my wife tells me, any maybe she's right, but it's a lifelong hobby and I love it.

But enough about me. I assume that you're here because you have an interest in using small computers to interface to the rest of the world, and I hope what I write will be useful to you. I'll run rough-shod across the field of automating a model railroad. Hopefully you'll find something of use.

- - - -

Early Problems

This first section discusses some of the problems I had while starting out. The AB Electronics folks, Andrew in particular, were quite helpful in getting this old self-taught guy started in the world of Raspberry Pi and their expansion boards.

There is enough information for you to hopefully get things right the first time and not make some of the bone-headed mistakes that I made, such as hooking up the power backward and frying the expansion boards, and trying to work on the RasPi while it was on, accidentally grounding the 3-volt bus and frying the main board.

Take it from me- - make all your electrical changes with the whole thing powered down. Color-code all your wiring (especially the power wiring). Triple-check your wiring before powering up. The traditional "smoke test" technique doesn't work with low-voltage wiring and today's dinky components like it did back in the old high-power days. "Trust me."

Click here to see the details about buying and setting up the RasPi and its expansion boards, titled "Adding Expansion Boards"..

Adding RELAY BOARDS (plus design considerations & C testing code)

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

GRAPHICAL INTERFACE C Code (Learn to love Linux graphics)

(...und you VILL enjoy ziss, ja?)

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.

Special Case: Sidings & Crossovers

As you'll see, there are no turnout "switch machines" on the layout. ...not yet, anyway. We'll use manual "switch stands" for now. Stay Tuned, as they say. Here, we'll use a "permission" system to line up sidings.

  1. We describe, here, the wiring needed to provide power to the various sidings, so we can "spot" railcars and locomotives there.

  2. We'll add GLADE entries and supporting code to check that things are lined up properly, electrically, but we'll have to trust you on the turnout alignment for now.

Adding Artificial Intelligence

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.

Speed and Power Indication

to be written

Motor Regulation and Control

to be written

Turnout Position and Operation

to be written