Programming

The programming is all in Python, a new language to me but I’m learning quickly. The previous layout programming was in Python 2 but common sense said to use the newer Python 3; that immediately made most of my old code obsolete without major reworking.

For copyright and support reasons I’m not releasing the full code for the programming at this stage, I have included code snippets in some pages under the GNU General Public License version 3.  These are unsupported and are released for information and out of interest, no warranty is provided and no liability accepted.

Structure and Principles

I decided from the start to adopt a multi-level structure for the programming and control. This has a lot of advantages during the development phase as you simply start at the bottom and work up! I’ve used terminology that sort of fits with the real world to make it more understandable.

Level 0 – IO

IO routines are used to interact with the various control boards. These may be provided by the equipment manufacturer or written by me.

Level 1 – Actions

Actions call IO routines to “make something happen”, that might be to switch a point, turn on a light or make a loco move. An Action may require several IO routines, for example switching a point requires both the servo movement and a relay to be switched.

Level 2 – Routes

A Route comprises a series of Actions which are carried out sequentially, possibly with timed delays or waits on an input trigger. The route may be to move a loco from one place to another, for example, but may also be a sequence of turning layout lights on and off to simulate people arriving or it could be turning the ambient light up and down at dawn and dusk

Level 2 – Manual Control

Also on level 2 is the coding for manual control. These routines could provide a simple text input on the computer, a graphical display or for a full manual controller to be built. The basic principle is that an input triggers an Action, it’s that simple.

Level 3 – Timetables

Following common heritage railway practice Timetables will be identified by colours. A typical example may be that the Red timetable applies on weekdays and the Green one on weekends. For my purposes a Timetable is a series of Routes called at specific times. Clearly running to “real” time would be very boring so the clock is accelerated.

Level 4 – Calendars

The ultimate for me in terms of automated control would be to run the railway for a long simulated period without intervention. To do this a Calendar is simply a day-by-day series of Timetables.

Data

I’ve avoided hard-coding the data for the various routines within the program. All data is stored in a series of files. These files are currently created by a separate Python program; once I start creating Routes, Timetables and Calendars I’ll need to look for a simple way to maintain these, one option will be to use Excel spreadsheets, saved to a CSV file and copied to the Pi.

Multi-Processing

This is the point at which the programming moves from relatively simple to more complex coding.

In the real world activities on a heritage railway don’t happen sequentially, 2 or more things can be happening at the same time. I want that ability so things are more natural although there will be some limitations due to the control systems. To do this each Route is submitted for processing simultaneously. Some other areas benefit from simultaneous processing including the lighting.