Introduction to EX-RAIL Automation¶
EX-RAIL is in Beta testing. It is very far along, but you may experience unexpected issues.
We can use your help in final testing and ideas for new features. Please see us on Discord here to participate in the Beta, and get notified of new code releases.
You can find instructions to download the EX-RAIL version of the software here.
EX-RAIL is an “EXtended Railroad Automation Instruction Language” that can easily be used to describe sequential actions to automatically take place on your model layout. These actions are defined programmatically in a simple command script file, and uploaded to the Command Station once to configure it. EX-RAIL will then run automatically on CS startup.
To begin, let’s define a few terms:
SEQUENCE - Simply a list of things to be done in order. These things might be to actually drive a train around, or merely to set some turnouts or flash some scene or panel lights. Actions can be made to wait for conditions to be met, like a sensor detecting a train, a button being pushed, or a period of time elapsing.
ROUTE - A SEQUENCE that is made visible to EngineDriver with a readable name so the user can press a button to get the sequence executed. This might be best used to set a series of turnouts and signals to create a route through the layout.
AUTOMATION - A SEQUENCE that is made visible to EngineDriver so that a user can hand over a loco and let EX-RAIL drive the train away, following each step listed in the sequence.
Things You Can Do With EX-RAIL¶
Create “Routes” which set multiple turnouts and signals at the press of a button in EngineDriver (other WiThrottle-compatible throttles are available)
Animate accessories such as lights, crossings, or cranes using “Sequences”
Automatically drive multiple trains simultaneously, and manage complex interactions such as single line working and crossovers by setting up “Automations”
Drive trains manually, and hand a train over to an Automation
Intercept turnout changes to automatically adjust signals or other turnouts
Turn on the coffee pot when the train reaches the station
What You Don’t Need¶
While extra functionality may be attained by using additional tools and applications, to get the benefit of EX-RAIL you don’t need anything more than a DCC-EX Command Station, and the Arduino IDE used to configure it.
You DON’T need:
JMRI, or any additional utilities
EngineDriver, or any other WiThrottle app
A separate computer living under your layout
Knowledge of C++ or Python/Jython programming
How It Works¶
A small amount of code in the CS, the EX-RAIL executor, lets you write an automation script in the form of simple, easy to use text commands that it interprets and runs on your layout. You don’t have to be a programmer and you don’t have to learn code. You simply add your own myAutomation.h file in the same program you use to upload the Command Station Software to your Arduino (the Arduino IDE, PlatformIO, etc). This means that you already have all the tools you will need, and there is nothing else to download or install. The method of creating your script file is described in the next section.
The EX-RAIL code is surprisingly small and requires very little PROGMEM (memory that holds the program code) or SRAM (the runtime workspace that stores variables and things the program needs) to operate. However, you will still need a Mega for your CS; the UNO and Nano memory is simply too small to include EX-RAIL with the rest of the Command Station code.
EX-RAIL automation is much (perhaps 2 orders of magnitude) more time efficient than the code required to process incoming requests from an external automation processor, or the continuous polling of every sensor.
The EX-RAIL code is only included in the compilation of the Command Station if the compiler detects a “myAutomation.h” file. If you don’t create that file, no extra space is wasted for something you don’t use.
The Automation Process¶
All routes, automations, etc step through a list of simple keywords until they reach a
For a full list of keywords, see EX-RAIL Reference
Automation scripts are added to your Command Station by creating a file called “myAutomation.h” in the same folder as CommandStation-EX.ino, and adding in the scripts as follows:
EXRAIL ... your scripts ENDEXRAIL
Connecting your Arduino and pressing the Upload button in the usual way will save the file and upload your script into the Command Station.
To create the myAutomation.h file in the Arduino IDE, use the pulldown button and select New Tab (or simply press Ctrl+Shift+N).
Enter the file name “myAutomation.h” (This is case sensitive)
And type your script in, starting with EXRAIL and ending with ENDEXRAIL.
Some Simple Examples¶
Example 1: Creating Routes for Engine Driver¶
A typical Route might be used to set a sequence of turnouts in response to a single button in Engine Driver, or a pushbutton on a fascia panel near a yard. The EX-RAIL instructions to do this might look like
ROUTE(1,"Coal Yard exit") THROW(1) CLOSE(7) DONE
Or you can write it like this
ROUTE(1,"Coal Yard exit") THROW(1) CLOSE(7) DONE
Or add comments
// This is my coal yard to engine shed route ROUTE(1,"Coal Yard exit") // appears in Engine Driver THROW(1) // throw turnout onto coal yard siding CLOSE(7) // close turnout for engine shed DONE // that's all folks!
Of course, you may want to add signals, and time delays
SIGNAL(77,78,79) // see the Defining Signals section SIGNAL(92,0,93) // below for details ROUTE(1,"Coal Yard exit") RED(77) THROW(1) CLOSE(7) DELAY(5000) // this is a 5 second wait GREEN(92) DONE
Example 2: Automating Signals with Turnouts¶
By intercepting a turnout change command, it’s easy to automatically adjust signals or
automatically switch an adjacent facing turnout. Use an
ONCLOSE keyword to detect a particular turnout change:
ONTHROW(8) // When turnout 8 is thrown, THROW(9) // must also throw the facing turnout RED(24) DELAY(2000) GREEN(27) DONE ONCLOSE(8) // When turnout 8 is closed CLOSE(9) RED(27) DELAY(2000) GREEN(24) DONE
DCC-EX supports a number of different turnout hardware configurations, but your automation treats them all as simple ID numbers. Turnouts may be defined using
<T> commands from JMRI, or in
SETUP("<T ...>") commands or C++ code in mySetup.h, just like earlier versions.
You may, however, find it more convenient to define turnouts using EX-RAIL commands, which may appear anywhere in the ‘myAutomation.h’ file, even after they are referenced in an
CLOSE command. (EXRAIL extracts the turnout definitions just once from your script at Command Station startup.)
Turnouts defined in ‘myAutomation.h’ will still be visible to WiThrottle and JMRI in the normal way.
See the Reference section for TURNOUT, PIN_TURNOUT and SERVO_TURNOUT definitions.
Signals can now simply be a decoration to be switched by the route process; they don’t need to control anything.
GREEN(55) would turn signal 55 green, and
RED(55) would turn it red. Somewhere in the script there must be a SIGNAL command like this:
SIGNAL(55,56,57). This defines a signal with ID 55, where the Red/Stop lamp is connected to pin 55, the Amber/Caution lamp to pin 56, and the Green/Proceed lamp to pin 57. The pin allocations do not need to be contiguous, and the red pin number is also used as the signal ID. Thus you can change the signal by
GREEN(55). This means you don’t have to manually turn off the other lamps. A RED/GREEN only signal may be created with a zero amber pin.
Example 3: Automating various non-track items¶
This normally takes place in a timed loop, for example alternate flashing of a fire engine’s lights. To do this use a SEQUENCE.
SEQUENCE(66) SET(101) // sets output 101 HIGH RESET(102) // sets output 102 LOW DELAY(500) // wait 0.5 seconds SET(102) // swap the lights RESET(101) DELAY(500) // wait 0.5 seconds FOLLOW(66) // follow sequence 66 continuously
Note, however, that this sequence will not start automatically: it must be started during the startup process (see later) using
Example 4: Automating a train (simple loop)¶
Start with something as simple as a single loop of track with a station and a sensor (connected to pin 40 for this example) at the point where you want the train to stop.
AUTOMATION keyword means that this automation will appear in EngineDriver so you can drive the train manually, and then hand it over to the automation at the press of a button.
* Technically, an automation can independently run multiple locos along the same path through the layout, but this is discussed later…
AUTOMATION(4,"Round in circles") FWD(50) // move forward at DCC speed 50 (out of 127) AT(40) // when you get to sensor on pin (40) STOP // stop the train DELAYRANDOM(5000,20000) // delay somewhere between 5 and 20 seconds FWD(30) // start a bit slower AFTER(40) // until sensor on pin 40 has been passed FOLLOW(4) // and continue to follow the automation
The instructions are followed in sequence by the loco given to it; the
AT command just leaves the loco running until that sensor is detected.
Notice that this automation does not specify the loco address. If you drive a loco with EngineDriver and then hand it over to this automation, then the automation will run with the loco you last drove.
Example 5: Signals in a train script¶
Adding a station signal to the loop script is extremely simple, but it does require a mind-shift for some modellers who like to think in terms of signals being in control of trains! EX-RAIL takes a different approach, by animating the signals as part of the driving script. Thus set a signal GREEN before moving off (and allow a little delay for the driver to react) and RED after you have passed it.
SIGNAL(77,78,79) // see the Defining Signals section above for details AUTOMATION(4,"Round in circles") FWD(50) // move forward at DCC speed 50 (out of 127) AT(40) // when you get to sensor on pin (40) STOP // Stop the train DELAYRANDOM(5000,20000) // delay somewhere between 5 and 20 seconds GREEN(77) // set signal #77 to Green DELAY(2500) // This is not Formula1! FWD(30) // start a bit slower AFTER(40) // until sensor on pin 40 has been passed RED(77) // set signal #77 to Red FOLLOW(4) // and continue to follow the automation
Example 6: Single line shuttle¶
Consider a single line, shuttling between stations A and B.
Starting from Station A, the steps may be something like:
Wait between 10 and 20 seconds for the guard to stop chatting up the girl in the ticket office.
Move forward at speed 30
When I get to B, stop.
Wait 15 seconds for the tea trolley to be restocked
Move backwards at speed 20
When I get to A, stop.
Notice that the sensors at A and B are near the ends of the track (allowing for braking distance, but don’t care about train length or whether the engine is at the front or back.) We have wired sensor A on pin 41, and sensor B on pin 42 for this example.
SEQUENCE(13) DELAYRANDOM(10000,20000) // random wait between 10 and 20 seconds FWD(50) AT(42) // sensor 42 is at the far end of platform B STOP DELAY(15000) REV(20) // Reverse at DCC speed 20 (out of 127) AT(41) // far end of platform A STOP FOLLOW(13) // follows sequence 13 again… forever
Note a SEQUENCE is exactly the same as an AUTOMATION except that it does NOT appear in the EngineDriver app.
When the Command Station is powered up or reset, EX-RAIL starts operating at the beginning of the file. For this sequence we need to set a loco address and start the sequence:
SETLOCO(3) START(13) DONE // This marks the end of the startup process
The sequence can also be started from a serial monitor with the command
</ START 3 13>.
If you have multiple separate sections of track which do not require inter-train cooperation, you may add many more separate sequences and they will operate independently.
Although the above is trivial, the routes are designed to be independent of the loco address so that we can have several locos following the same route at the same time (not in the end to end example above!), perhaps passing each other or crossing over with trains on other routes.
The example above assumes that loco 3 is sitting on the track and pointing in the right direction. A bit later you will see how to script an automatic process to take whatever loco is placed on the programming track, and send it on its way to join in the fun!
Example 7: Running multiple inter-connected trains¶
So what about routes that cross or share single lines (passing places etc)? Let’s add a passing place between A and B. S= Sensors, T=Turnout number. So now our route looks like this:
Assuming that you have defined your turnouts with TURNOUT commands.
SEQUENCE(11) DELAYRANDOM(10000,20000) // random wait between 10 and 20 seconds CLOSE(1) CLOSE(2) FWD(30) AT(42) // sensor 42 is at the far end of platform B STOP DELAY(15000) THROW(2) THROW(1) REV(20) AT(41) STOP FOLLOW(11) // follows sequence 11 again… forever
All well and good for one loco, but with 2 (or even 3) on this track we need some rules. The principle behind this is
To enter a section of track that may be shared, you must RESERVE it. If you cant reserve it because another loco already has, then you will be stopped and the script will wait until such time as you can reserve it. When you leave a shared section you must free it.
Each “section” is merely a logical concept, there are no electronic section breaks in the track. You may have up to 255 sections (more can be supported by a code mod if required).
So we will need some extra sensors (hardware required) and some logical blocks (all in the mind!):
We can use this diagram to plan routes. When we do so, it will be easier to imagine 4 separate mini routes, each passing from one block to the next. Then we can chain them together to form a full route, but also start from any block.
So… lets take a look at the routes now. For convenience I have used route numbers that help remind us what the route is for.
SEQUENCE(12) // From block 1 to block 2 DELAYRANDOM(10000,20000) // random wait between 10 and 20 seconds RESERVE(2) // we wish to enter block 2… so wait for it CLOSE(1) // Now we “own” the block, set the turnout FWD(30) // and proceed forward AFTER(71) // Once we have reached AND passed sensor 71 FREE(1) // we no longer occupy block 1 AT(72) // When we get to sensor 72 FOLLOW(23) // follow route from block 2 to block 3 SEQUENCE(23) // Travel from block 2 to block 3 RESERVE(3) // will STOP if block 3 occupied CLOSE(2) // Now we have the block, we can set turnouts FWD(20) // we may or may not have stopped at the RESERVE AT(42) // sensor 2 is at the far end of platform B STOP FREE(2) DELAY(15000) FOLLOW(34) SEQUENCE(34) // you get the idea RESERVE(4) THROW(2) REV(20) AFTER(73) FREE(3) AT(74) FOLLOW(41) SEQUENCE(41) RESERVE(1) THROW(1) REV(20) AT(41) STOP FREE(4) FOLLOW(12) // follows Route 12 again… forever
Does that look long? Worried about memory on your Arduino…. Well the script above takes about 100 BYTES of program memory and no dynamic SRAM!
If you follow this example carefully, you’ll see it allows for up to 3 trains at a time, because one of them will always have somewhere to go. Notice that there is a common theme to this…
RESERVE where you want to go. If you are moving and the reserve fails, your loco will STOP and the reserve waits for the block to become available. *These waits and the manual WAITS do not block the Arduino process… DCC and the other locos continue to follow their routes!
Set the points to enter the reserved area. Do this ASAP, as you may be still moving towards them.
Set any signals.
Move into the reserved area.
Reset your signals.
Free off your previous reserve as soon as you have fully left the block.
In addition, it is possible to take decisions based on blocks reserved by other trains. The IFRESERVE(block) can be used to reserve a block if it’s not already reserved by some other train, or skip to the matching ENDIF. For example, this allows a train to choose which platform to stop at based on prior occupancy. It is features like this that allow for more interesting and unpredictable automations.
Starting the system¶
Starting the system is tricky, because we need to place the trains in a suitable position and set them going. We need to have a starting position for each loco, and reserve the block(s) it needs to keep other trains from crashing into it.
This EX-RAIL version isn’t ready to handle locos randomly placed on the layout after a power down!
For a known set of locos, the easiest way is to define the startup process at the beginning of ROUTES. E.g. for two engines, one at each station.
// ensure all blocks are reserved as if the locos had arrived there RESERVE(1) // start with a loco in block 1 RESERVE(3) // and another in block 3 SENDLOCO(3,12) // send Loco DCC addr 3 on to route 12 SENDLOCO(17,34) // send loco DCC addr 17 to route 34 DONE // don’t drop through to the first route definition that follows in the script file
Some interesting points about the startup:
You don’t need to set turnouts, because each route is setting them as required.
Signals default to RED on power up, and get turned GREEN when a route clears them.
Drive Away feature¶
EX-RAIL can switch a track section between programming and mainline automatically.
Here for example is a startup route that has no predefined locos but allows locos to be added at station 1 while the system is in motion. Let’s assume that the track section at Station1 is isolated and connected to the programming track power supply. Also that we have a “launch” button connected where sensor 17 would be and an optional signal (ie 3 leds) on the control panel connected where signal 27 would be.
SEQUENCE(99) SIGNAL(27,28,29) RED(27) // indicate launch not ready AFTER(17) // user presses and releases launch button UNJOIN // separate the programming track from main DELAY(2000) AMBER(27) // Show amber, user may place loco AFTER(17) // user places loco on track and presses “launch” again READ_LOCO // identify the loco GREEN(27) // show green light to user JOIN // connect prog track to main START(12) // send loco off along route 12 FOLLOW(99) // keep doing this for another launch
The READ_LOCO reads the loco address from the PROG track and the current route takes on that loco. By altering the script slightly and adding another sensor, it’s possible to detect which way the loco sets off and switch the code logic to send it in the correct direction by using the INVERT_DIRECTION instruction so that this locos FWD and REV commands are reversed. (easily done with diesels!)
You can use
FOFF(n) to switch loco functions… eg sound horn.
DCC++EX allows for sensors that are Active Low or Active High. This is particularly important for IR sensors that have been converted to detect by broken beam, rather than reflection. By making the sensor number negative, the sensor state is inverted. e.g.
Magnetic/Hall effect sensors work for some layouts, but beware of how you detect the back end of a train approaching the buffers in a siding, or knowing when the last car has cleared a crossing.
Handling sensors in the automation is made easy because EX-RAIL throws away the concept of interrupts (“oh… sensor 5 has been detected… which loco was that and whatever do I do now?”) and instead has the route scripts work on the basis of “do nothing, maintain speed until sensor 5 triggers, and then carry on in the script”.
Sensor numbers are direct references to VPINs (virtual pin numbers) in the Hardware Abstraction Layer. For a Mega onboard GPIO pin, this is the same as the digital pin number. Other pin ranges refer to I/O expanders etc.
Sensors with ID’s 0 to 255 may be LATCHED/UNLATCHED in your script. If a sensor is latched on by the script, it can only be set off by the script… so
AT(5) LATCH(5)for example effectively latches the sensor 5 on when detected once.
Sensor polling by JMRI is independent of this, and may continue if <S> commands are used.
Generic Outputs are mapped to VPINs on the HAL (as for sensors)
SIGNAL definitions are just groups of 3 Output pins that can be more easily managed.
All ROUTE / AUTOMATION / SEQUENCE ids are limited to 1- 32767
0 is reserved for the startup sequence appearing as the first entry in the EXRAIL script.
Defining names for any ID numbers¶
ALIAS() command in your script file. This must come BEFORE the
Should be reasonably short but descriptive.
Must start with letters A-Z or underscore _ .
May then also contain numbers.
Must not contain spaces or special characters.
ALIAS(COAL_YARD_TURNOUT,19) ALIAS(COAL_YARD_SIGNAL_3,27) EXRAIL ROUTE(1,"Coal yard exit") THROW(COAL_YARD_TURNOUT) GREEN(COAL_YARD_SIGNAL_3)
EXRAIL ROUTE(1,"Coal yard exit") THROW(19) GREEN(27) DONE #include "myFireEngineLights.h" #include "myShuttle.h"