Thanks for the detailed description of how you run your automated
trains with scripts. The way you structured your setup is especially
interesting, and again started the gears turning in my thinking about
automated trains. I liked your second principle, "Every TRAIN has an
Engineer to ask for PERMISSIONS, and to drive the Train according to
these Instructions.", and how you implemented it. It's somewhat
similar, but a different slant, on what I've been thinking.
I'm interested in extending PanelPro to do essentially the same thing,
but without using scripts. Layout Editor captures the connectivity,
the signal head information, and the blocking information of the
layout schematic as the schematic is constructed. This is the starting
point on which to build whatever we come up with.
Thanks again for sharing this. Any further ideas/comments are very
On Jun 3, 2008, at 1:01 AM, Ron McKinnon wrote:
> On Wed, 28 May 2008 08:31:56 -0400, you wrote:
> This has been an interesting discussion, and it would appear that I
> already have working my version of this type of automated control,
> so you may be interested
> in how I structured this (Warning Long Description.)
> I would be pleased to answer any questions or receive comments.
> After the Java One Demo was presented, I tried to get this working
> but there were obstacles that I encountered (can't remember now)
> that made be investigate
> The first thing you need is to have the appropriate hardware, that
> is then controlled by JMRI and PanelPro together with scripts (as I
> am too old now to be
> learning yet another programming language ie Java) My hardware
> consists of a Digitrax DCS100 command Station & booster, BDL168
> occupancy sensors, and a mixture
> of Turnout decoders (DS54, 44 & 64), together with SE8c signal
> modules. My computer operating system is Windows XP SP2.
> These are the Principals that I followed in developing my control
> A TRAIN never moves from it's current position until it has
> PERMISSION to do so from TRAIN CONTROL.
> Every TRAIN has an Engineer to ask for PERMISSIONS, and to drive
> the Train according to these Instructions.
> A working SIGNALLING system driven by both TRAIN CONTROL (Starter
> signals), and SSL progress of trains around the system.
> TIMETABLE Trains follow specified routes to get from A to B. I call
> these Routes CONTROL SECTIONS as they could be made up of a number
> of blocks and/or
> Routes via Turnouts. Because my layout consists of many single track
> sections linked with passing loops my CONTROL SECTIONS only control
> that part of the track
> from the starting point to the allocated track of the passing loop,
> where the train stops or pauses to get further PERMISSION to travel
> over the next section of
> it's journey.
> Once a PERMISSION has been given for access to a CONTROL SECTION,
> then that section is LOCKED, and is unable to be released until the
> train arrives at the end
> of that section. While a Train is moving it tests the state of
> various SIGNALS along the right of way, and adjusts speed to suit
> the Aspect given by that
> I have implemented this strategy in JMRI PanelPro in the following
> TRAIN (Engineer):
> Each automated train has a set of three Internal Sensors associated
> with it. The first is used to Select if that train is to be run in
> that TRAIN
> CONTROL cycle (see below). The second denotes if that train is
> running or is in a paused state. (ie. has finished it's run.) The
> third is its PERMISSIONS
> sensor, which the appropriate TRAIN script sets when it requests
> clearance from TRAIN CONTROL. The TRAIN will not move until TRAIN
> CONTROL resets that Internal
> Sensor after it has evaluated if it is clear to proceed to the next
> CONTROL SECTION (see below).
> Each of my automated trains has it's own individual Automat script,
> although similar in content they are taylored to the particular
> characteristics and the journey over the appropriate sensor blocks
> to that train's destination.
> The reason I have done it this way is because I can then
> dynamically adjust CV's for Volume, exhaust rate etc (using OPS Mode
> programming), while that
> Engine is in motion.
> In the Init section of the Script, the throttle is acquired and
> allocated to a Global Variable for access purposes. Once acquired it
> will stay that way
> until PanelPro is shut down with a script, which turns off lights
> etc., and despatches all throttles.
> In the handle section there is a repeating loop which checks the
> Pause sensor to see if it is time to run /rerun the train over it's
> If set to run the program then branches to the main run routine
> where the engine prepares itself with lights and whistles and steam
> release etc., after
> it has asked for, and received PERMISSION to travel over the first
> CONTROL SECTION of it's journey. At this stage TRAIN CONTROL will
> have set the route turnouts
> and set the Starting signal to Green. The train then chuffs off. The
> script then has a series of WAITSENSORACTIVE parts for each sensor
> that the train travels
> over. On active, the Memory Variable for that Sensor is updated with
> that Trains ID Number, and the prior sensor Memory is set to a
> blank. These show on the
> trains progress on the panel.
> At various places the next signals state is checked by a sub
> routine. This is a decision tree of IF statements, which first
> checks for RED. If True then
> speed /Brakes are set to stop, and loops while RED. If False then
> checks for YELLOW, and sets appropriate speed for that engine and
> returns. If GREEN sets speed
> for Normal and returns.
> At the end of that CONTROL SECTION the TRAIN comes to a Stop,
> pauses for a time at station or water tank or whatever, and then
> again asks for PERMISSION
> to proceed from TRAIN CONTROL. When received The previous Section is
> UNLOCKED, and the journey again proceeds as above, until all CONTROL
> SECTIONS have been
> traversed, and the Train comes to a stop, the pause sensor is set
> and the script waits until it again called into action, where the
> whole process is repeated.
> I have a script that on startup of the system, gets and loads all
> signals into a Global array (indexed List), that can be accessed by
> any other script
> running on the system. This means that any of my TRAIN Scripts and
> TRAIN CONTROL scripts can access these and make decisions on what
> speed to set.
> NOTE: I have all my signals, (except for the Starter signals which
> are just screen sensors that look like signals) loaded using the
> SE8c SSL logic. They all
> work perfectly for control purposes and for screen display without
> even having the SE8c modules plugged in.
> CONTROL SECTIONS:
> All of my CONTROL SECTIONS each have an Internal Sensor, which if
> any layout sensor in that section goes active, will also go active,
> denoting that
> there is something present in that part of the track. When all the
> relevant layout sensors are unoccupied, the Internal Sensor will
> return to an Inactive state.
> There is also a set of companion Internal sensors for each CONTROL
> SECTION, that is set to Active (ie. a LOCKED state) by TRAIN CONTROL
> when it allocates that
> particular free CONTROL SECTION to a TRAIN. (The appropriate TRAIN
> will unlock that sensor once it gets to the end of that CONTROL
> SECTION, and has permission
> to travel into the next Section.)
> TRAIN CONTROL:
> My TRAIN CONTROL scripts are Listeners. There is a Listener for
> each TRAIN waiting for the PERMISSIONS sensor to be triggered by the
> TRAIN script. There
> is an IF statement for each place where this TRAIN will ask for
> PERMISSION to proceed. It determines that the occupancy sensor for
> that block is occupied, that
> the Memory Varible value is equal to this Train ID, and that the
> Direction of travel is correct.(Each Train script carries this
> direction variable for
> checking.)It is mainly used for my RDC commuter trains where the
> Train travels over an out and back journey. The varible is switched
> at the journey return
> If the above checks out, then the train is known to be in that
> place, and the rest of the routine is carried out. This then checks
> all CONTROL SECTIONS
> that also include parts of this section, firstly to see they are not
> LOCKED, and secondly that they are not occupied.
> If these check out then Permission is given by resetting the
> PERMISSION sensor for that train, otherwise it loops until all are
> clear. The Listener then exits
> until triggered again.
> TRAIN CONTROL CYCLE:
> I mentioned above about this TRAIN CONTROL cycle. This is a
> separate script which merely loops around until the system is shut
> down. In future this is
> where my TIMETABLE will be located. (but I haven't had time to do
> this yet.)
> It presently keeps track of which Locomotives have been acquired
> (which interprets into which TRAIN scripts are active.) If a new Run
> sensor has been
> turned on it then knows whether to trigger that script or not, and/
> or run that train in this cycle. This gives me the freedom to run
> whichever trains I want to
> at any time. Good for checking out changes to scripts, where I can
> just run that train until I have it correct. Then I can run as many
> as I want to.
> At present I have six trains set up to run automatically, although I
> have two more in the pipeline. The current cycle of six trains takes
> about 30 minutes, but
> this includes where there are at least three trains at any one time
> running in opposing directions. The signals and the Control Sections
> stop them from running
> into each other. (most of the time !)
> Ron McKinnon
> Wellington, New Zealand.
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> Jmri-developers mailing list