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!

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

Here's Where to Start