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.
I decided from the start to adopt a multi-
IO routines are used to interact with the various control boards. These may be provided by the equipment manufacturer or written by me.
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.
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
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.
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.
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-
I’ve avoided hard-
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.