We did a "simulation" yesterday at Randall using JMRI, a simple Jython script and time-based automation as indicated previously.

For the Passenger automation:

• We used the half/full/half speed scheme.
• Block-wise, the idea is to stop on 370 on the Summit.

For the Branchline automation, Jim decided on a "full speed" scheme, relying on DCC momentum.

Whenever possible I'd like to use block detection rather than IR sensors. It may not be a choice for the Branchline, but that remains to be seen by crawling under the layout and decoding the Branchline panel more closely. If not, I'll do IR sensors.

We will need to incorporate timing with the block sensors. E.g. for Passenger, the idea is to detect the train in B370 and wait a few seconds before stopping it. The number of seconds will have to be adjusted empirically depending on the train and its CV 4 value. Same for the train going back at the station as the whole thing is a long block.

The goal is still to do a small test with IR sensors in the back.

Speaking of blocks, I identified the main blocks on the mainline for passenger. Generally speaking a block starts after its turnouts. E.g. something like this:

 ----[B380]----|-<T380>-------[B370]-----|-<T370>----...

Since the layout was apparently designed to run in the other direction, that makes each block finish with the turnout it is powering. In DCC that means block B370 starts after T370 and powers through T380. So the power for T370 comes from B360, etc.

Blocks B340 and B350 seems to be powered in parallel.

It might be easier to configure the automation using a small text syntax.

The automation is a state machine where each state is the train movement (either stopped or running) and the condition to make it go to the next state, which means an “action ⇒ end/post condition” scheme.

The other possible is to have a “start/precondition ⇒ action” scheme, in which case the state machine can be identified by looking at the current state of the system. Doing it this way, it would be possible to initialize the state machine by looking at the current condition.

Comparison for Passenger automation:

Action ⇒ Post-Condition	Precondition ⇒ Action
Train stopped (at station) ⇒ Wait activation button	P2 active + Toggle on + Activation Button enabled ⇒ Half Speed Forward ; disable activation button
Half-speed forward ⇒ Till Block P1	P1 + forward ⇒ Full-speed forward
Full-speed forward ⇒ Till Block 370 + N sec	370 + forward ⇒ Half-Speed + Start Timer T370
Stop (at summit) ⇒ Wait 5 sec	Timer T370 ⇒ Stop (at summit), Timer Rev
Half-speed reverse ⇒ Till Block 360	Timer Rev ⇒ Half-Speed Rev
Full-speed reverse ⇒ Till Block P1	370 + rev ⇒ Full-speed Rev
Half-speed reverse ⇒ Till Block P2 + N sec	P1 + reverse ⇒ Half-speed reverse
Stop ⇒ Go to step 1	P2 + reverse ⇒ Start Timer P2
[Toggle off in steps 1-3] ⇒ Go to step 6 or 7.	Timer P2 ⇒ Stop (at station) ; enable activation button after N sec.
	Toggle off + not forward + not P2 ⇒ reverse
	Activation button + disabled = Horn

Even with the post-condition scheme, we need one precondition rule to bring back the engine.

The benefit of the precondition mode is that, as long as the conditions can be made non-ambiguous, we can pick up the proper step just by looking at the current state.

We do want to have a "current condition triggered" to avoid triggering the same step repeatedly. The logic would scan all conditions in a loop and we don't want to trigger the same pending action twice.

The goal is to handle unknown situations. Typically a derailment creating a short. As soon as the short is fixed, the train will restart moving and as long as we know the direction we can figure which step is going on. The other situation to consider is a power loss. DCC restarts with a speed zero but an operator could just toggle on/off to bring it back to the default location.

Similarly, the table for the Branchline would look like this.

We'll have 2 modes: storage vs running and trains starts in storage mode.

Precondition ⇒ Action

Toggle on + IR Storage ⇒ Half-speed forward / mode=Storage

IR Start + Forward + mode=Storage + ⇒ Stop / mode=Running

IR Start + Stopped + mode=Running ⇒ Full-speed forward

IR Reverse + Forward ⇒ Stop / Timer Rev

Timer Rev ⇒ Full-speed reverse

IR Stop + Reverse ⇒ Stop

Toggle off + mode=Running + Forward ⇒ Half-speed reverse / mode=Storage

Toggle off + IR Start + Stopped ⇒ Half-speed reverse / mode=Storage

IR Storage + reverse ⇒ Stop

We do need a mode since there's an ambiguity on the IR Start sensor: "IR Start + Forward" is the same when a train comes from storage (and needs to stop) as when the Activation Start button is pushed (and train goes full speed). A possibility is to use the speed as the mode variable but the concept remains.

IR Start / IR Stop might be the same thing depending on the train momentum. Will it overshot the sensor or still stay on top and trigger it?

That being said, it may all be academic. For simplification purposes, we'll also start the Branchline without using the storage track, in which case the start position is all we need.

Precondition ⇒ Action

IR Start + Stopped ⇒ Full-speed forward

IR Reverse + Forward ⇒ Stop / Timer Rev

Timer Rev ⇒ Full-speed reverse

IR Stop + Reverse ⇒ Stop

Toggle off + Forward ⇒ Full-speed reverse

In the AIU we'll still keep free spots for 2 start sensors and 2 reverse sensors in case we have an overshot-the-sensor issue.

---