Technical Ramblings of a Retired Chemical Engineer

=  featuring  =

< Computer Applications in Model Railroading >

< Sausage Making Information >

Here's Where to Start (plus an upcoming revision warning!)

Okay, so you're interested in doing it, perhaps the hard way? Here's how to dig through the website's material.

Start off with buying a Raspberry Pi (RasPi) computer, a small, single-board machine which runs just about anything in the Linux world that fits in its memory. As you'll see, as your code grows, eventually you may have to write your code in multiple pieces, then combine 'em, but that's really not that hard. (This has been my approach if not all of it is used at run time. An example: code to assemble a data array which describes your model railroad layout.) Just keep a modular approach in mind.

NOTE that I have just discovered an article, "How to set up Remote-Control Operations," in the February 2021 issue of Model Railroader magazine. This outlines the use of Digital Command Control (DCC) with a Personal Computer (PC) running the Java Model Railroad Interface (JMRI), using a digital panel developed in Crandic Automated Traffic System (CATS) overlaid on JMRI. This has enough acronyms and abbreviations to be intimidating by itself. Thankfully, though, much of this is freely available open-source software. Start off by looking at the Model Railroader article, then click on the following underlined link to look at the  JMRI website,  https://www.jmri.org/, before plunging onward. It looks like I'll need to do the same, and possibly scrap what I've written here, although I can still use my Raspi and hopefully its interface boards. "Stay tuned.". Meanwhile, beware!!!

Get the RasPi running, play around, and see what you can do. It seems to do very well with C and PYTHON code, among several options. Explore the Linux world. Being an old C hacker, that's the language that I chose.

Next, figure out what (and how) to control on your layout. I chose to use a graphical interface to operate mechanical relays to  operate an old-fashioned DC block-control system, whereas you may wish to use one of the new DCC systems. (See the "Adding EXPANSION BOARDS" ans "Adding RELAY BOARDS" pages.) The DCC approach offers simplification of wiring and layout hardware, but requires greater expense if you have more than a few locomotives. (The motor control hardware runs over $100 per locomotive at last glance, excessive for my limited budget.) ...your choice, though. 

Once you figure out what hardware to control, you can build a graphical interface upon which you can mouse-click to change the states of the various components. I did this using GLADE software, downloadable from the internet for free, an example of which is shown on the home page. See the "GRAPHICAL INTERFACE" page.) You'll use it for such output functions as block or track section Off/On, block or track Forward/Reverse (polarity, for so-called "reversing loops"), power source selection, speed control, and emergency stop. You'll also use it for input of signals from the layout, such as position detection (see POSITION DETECTOR BOARDS). I chose infrared sensor boards for this function, and positioned one sensor beneath the roadbed at the track gap between each two blocks. This way, I detect when a locomotive enters one block from a previous block, plus when the rear car exits the previous block. You could certainly use electrical current detection to tell when a locomotive is operating within a block, or aim an IR detector source and detector horizontally along the length of a track block, or numerous other methods limited by your imagination and available hardware.  ...and budget.

You'll find details in the various sub-pages, plus added topics. Examples include using ARTIFICIAL INTELLIGENCE to improve the code for speed measurement, details on Sidings and Crossovers, installing Motor Control, and of course, Turnout Position Control. Some of the latter topics are still under development. In fact, I may or may not include turnouts, since I have had bad experience maintaining their operating mechanisms and currently use manual operation.

Please be patient. Like all model railroading, this is a work in progress, and will continue to be so for as long as it (or I) exist. I hope it gives you some good ideas. Enjoy!

Model Railroading with Raspberry Pi:   Adding EXPANSION BOARDS

Introduction

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.

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


Adding POSITION DETECTOR BOARDS

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. 


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. 

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


Here's Where to Start