Intro

Let’s continue our discussion on Raspi hardware and programming in C, using my model railroad application as an example. Last time, after burning out a couple of IO Pi Plus expansion boards, I replaced them and got them running, then hooked up a number of relay boards and tested them.

I recognized that my next step needed to be a decent interface for the model railroad. Having retired from chemical engineering in the polymer and petrochemical industry since the late 1960’s, I had certain expectations for what the control interface ought to look like. Specifically, I wanted a graphical interface to interact with the hardware, but I also wanted at least one status screen to tell me how the controls were configured and to point out problem areas. Here’s my formalized plan. I hope to present it to you here, as long as I don’t wear out my welcome with Andrew & friends.

Topic List

• Overall structure discussion.

• Intro to GLADE.

• How the C program incorporates the GLADE file.

• How "messaging" works and is handled.

• How arrays of pointers are used to access various user-specified input information, and how the information is displayed.

• Two types of buffers: a non-time-sensitive one for the information that is displayed directly, and 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). Also, a time-sensitive buffer for the dynamic information from the position detector cards (which must be "de-bounced").

• 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) of the earlier code which displays relay setting information showing whether it is safe or not to cross the gap from one track block to the next.

There's code buried in here to implement some of the checking, but this will be revised later in the "Artificial Intelligence" section.

RasPi Graphical Interface:

As noted, I wanted two parts to the interface, (1) a graphical overview of the model railroad layout with both input and output, and (2) a status screen. As a first step, I brainstormed what it would take to bring about the two screens. A couple of ideas popped up, not necessarily in this order:

• • • A need to periodically and quickly read and buffer time-sensitive layout status, rapidly changing items and items that have noisy signals, particularly track block occupancy detectors. I’ve had problems in the past with such things as magnetic reed switch contact bouncing, so these items will require buffering, and possibly, interrupt-driven code (We’ll see about that later.)

    • A need to periodically but not as frequently update one or both status displays, and accept control signals such as power pack selection, track block on/off and power pack selection, direction, and whether or not these settings are matched on adjacent blocks. A train should not cross from one track block to another unless all the aforementioned settings match.

So, for this section of computer code development, we’ll need to write code to support such items as

• • • Color-coded status display of track block power, direction, occupancy, gaps between track blocks, turnout positions, etc.

    • Receiving commands from the computer (a classical AI application, to be discussed later) or directly from you, the modeler, to change state of the aforementioned settings, as well as storage of what those states are.

The bare layout diagram was displayed above. Let's summarize what we need to control need to control. You can easily change this sort of thing to meet your own project requirements, seeing as how the guts of the thing are relays for output and detectors (to be visited later) for input. There will also be a section later in this writeup which discusses motor control.

The following is a partial implementation of the control screen, showing color-coded feedback for electrical assignments. Most of the text can be clicked on to toggle direction, power assignment, and the like.

Blocks:

Yes, I know, there’s a system known as DCC which allows you to feed alternating current power to the tracks and uses electronics onboard each locomotive to receive commands to regulate speed, direction, power pack selection, and operate lights, horns, et cetera. I have a number of locomotives and to use DCC would necessitate investing a considerable amount of money. Instead, I elected to go with good ol’ DC power and use a computer to operate the components that control power and direction. For what I want to do, anything more than four or five locomotives would be cost-prohibitive. Besides, I’m used to block wiring. In the old days, that approach required lots of single-pole double-throw (SPDT) center-off electrical switches, plus lots of double-pole double-throw electrical switches to control direction. In general, a single electrical block of track required one of each type. (Note here that I refer to electrical switches to avoid confusing what the prototype railroads call track switches, which model railroaders call turnouts.)

So, take your layout diagram and divide it up into as many electrical blocks as you feel are necessary. A good place for a block boundary is just past a turnout location, as can be seen in the earlier diagram. In the case where two tracks are parallel and there is a crossover, a pair of turnouts such as blocks 01 and 02, etc, in my diagram, you’ll need a block boundary there. This avoids “sneak” path short circuits. Think about it: the train s on tracks 01 and 02 run in opposite directions, so there’ll be a short circuit between them if there isn’t a break in the rails. To use the crossover, you’ll have to match directions, i.e. set block 01 forward and block 02 reverse, before you can drive a locomotive over the crossover from one block to the other.

…clear as mud, huh? What is normally done is to designate one rail as “north” and the other as “south,” then trace ‘em to see if they ever connect. If they do, you’ll have problems. (Follow this approach through block 00 to see the problem.)

Now for a control scheme plan. I’d like the following:

Having established blocks and with control scheme in mind, you’ll need to describe the track layout and supporting electronics to the computer so you can display such important information as what power pack a block is connected to, what the direction is, and whether or not the block is occupied. We do that by using arrays in our code and filling them in so we can use them to refer to the actual physical layout. Here’s mine. Note the extra hardware information associated with each block. Yes, I'd love to store this information dynamically and read it from a file into a linked list. I used arrays because they're faster to implement. Were I to be building something for commercial sale, it would be different. Too bad- - this thing is illustrative, but good for my needs only. Be tough- - you have to enter your own layout information anyway.

First, some definitions, to make the code a little easier:

With those definitions in mind, go ahead and specify your layout. I have used the array to record not only track details but also hardware details. With apologies, I have made arbitrary decisions about array dimensions. A better solution would be to use dynamic run-time dimensioning, and better yet would be to use a linked list built on the fly. Sorry. I didn’t want to make this example overly complicated. Mine is as follows:

Next, a couple of definitions and global variables for the RasPi I2C channels:

Power Controls:

A look ahead- - there are two power packs, #1 and #2, supplying power to all blocks via two power busses and a common return buss. The current from each of them is switched off or on with a single pole double throw (SPDT) relay. The layout trackage is divided into eight main electrical blocks numbered 00 through 07, each of which needs its own power controls. These controls consist of, for each block, an SPDT relay connection to either one of the two power supply packs, an SPDT off/on relay switch, and a double pole, double throw (DPDT) forward/reverse directional control relay. In addition there are three sidings, numbered 08 through 10. These sidings need only be connected to their adjacent blocks via an SPDT relay, which simplifies wiring considerably. (One rail is soldered to the main block, and the other is connected to its corresponding rail via this single SPDT relay.)

To draw both images, GLADE generates a file that starts out like the following:

The above GLADE output generates a window screen containing a child object that you can write and draw on with C code, which is the second (Status) page. I'll show you some code a bit later. Do NOT attempt to copy this code! Instead, let GLADE build it for you. (Some of it can get pretty ugly, as you will see.)

The GLADE file continues with another object, the upper detailed Main Control Diagram shown first above, which contains a "fixed" container holding lots of child label objects whose value and color and all can be set programmatically, as well as can be drawn upon or text listed on.

The rest of the file consists of various "child" entries which add items to the "fixed" window. For example, here's one that adds the fixed-window-area menu. (Some entries have been deleted, for brevity.)

...and so on.

There are a number of "widgets" which are fun to use, such as a progress bar and various label objects and buttons and whatnot. Where it really gets interesting, though, are when you start using labels as control buttons, sending "messages" to the C code. For example:

Below here, we launch into a bunch of labels which list block names and controls. These labels can be clicked on to generate "message" signals which the program's loop can interpret as commands "on the fly." (Note the "button-press-event" signal and the name of the subroutine which will be called.) These get positioned on or adjacent to where the track lines will be drawn by C code. There appears to not be a way to insert straight lines and curves and such into GLADE, so lines have to be drawn with code. That's okay, though, because it is easy to use color settings to show information such as power connection. These two, above, are used to toggle the block 01 or block 02 forward/reverse direction relay.

The two main powerpack off/on switches, and in fact all of the relays, are toggled the same way. For brevity, I won't list them here. This writeup is getting far too long.

Within the code are means of indicating what power is selected for what track block, et cetera. Built into the screen shot are three warning types. One is a simple red/yellow/green indication hard-coded into the slow screen update code, which runs every 5 seconds, and checks to see if adjacent track blocks are powered by the same powerpack or not, are set in the same direction, and whether or not the next block is occupied by a train. In the second, which is hard-coded logic, similar information is used to indicate whether it is okay to cross a gap between one track block and another via color code. If everything is set correctly, normal track color is used, otherwise, a red indication is displayed. The third warning is drawn on a separate status screen which shows what is right or wrong. Each track block has a display of its status plus that of the previous and next blocks, showing occupation, power selection, and direction.

This is useful, but maybe overkill. You decide.

Click here to see the details of the next page, Adding C code to Utilize GLADE Output File