Issues noted during the Randall Opening Day:

• Passenger:
• One derailment from 204 going down on B320 between the signal bridge and the turnout.
• Two derailments from 209 going up right when leaving the station. This is again a very very subtle left turn.
• Branchline:
• About 4~5 times, the RDC stopped at a station and never left again. One time it missed the stop at the reverse station.
• 2 times we couldn’t figure where it was.

To deal with the Passenger train issue leaving the station: this happens where the train accelerates and there’s a very very slightly left curve. ⇒ Delay the acceleration till the train is in the straight line after, which leads to a right curve.

The branchline issues can be attributed to a lack of recent track cleaning, combined with the current keeper -- the train will continue even if it doesn’t receive DCC. It will also not register as being on the track when there’s no contact due to dirty track or wheels. Not only it does not get DCC commands but the computer cannot stop the train if it doesn’t know where it is.

To solve this, I’m modifying the RTAC program to add an option to reissue speed commands every second or so. Each throttle object has a “repeat” integer which is the number of seconds to repeat speed commands, with 0 to disable it. When the automation is activated, the current script sets that to two. It solves the “keeper keeps engine running and misses commands” effectively.

I also want to rework the program with the earlier idea of having pre-conditions and post-actions. That said most of the time the post-action will be to repeat the speed command, so there’s no real point in specifying it explicitly.

Rewriting the example from 2017-01-16 here:

BL1 ⇒ BL2 [T324] ⇒ void ⇒ BL3 ⇒ BL4

B503b ⇒ B503a ⇒ [T504] ⇒ [T321] B321 [T322] [T326] ⇒ [T330] B330 ⇒ void ⇒ B360 ⇒ B370

[T322] ⇒ B322 [T324] ⇒ [T326]

B310 ⇒ [T320] B320 ⇒ [T330]

B311 [T311] ⇒ [T321]

State Station:

B503b & Stopped & Start ⇒ Align T504, T322, T321; State Up; Speed Fwd Normal; Expect B321 in 10s.

State Up:

B321 ⇒ Align T322, T326, T330; After 40s do F3; Expect B330 in 50s.

B330 ⇒ Speed Fwd Restricted; Expect void1

Void1 ⇒ Align T370; Expect B360; After 10s do Speed Fwd Normal; After 15s do Horn

B360 ⇒ Expect B370 in 10s

B370 ⇒ After 8s do Speed Fwd Restricted; After 11s do Stop; After 15s do State Down.

State Down:

B370 ⇒ Speed Rev Restricted; Expect B360

This looks simplistic compare to the current program which has all sorts of timers and delays built-in and complex conditions chains.

One issue in that program is that it does not make it clear what an “Expect” means, or more exactly what it means when it does not happen. The original thinking was to make it a graph. E.g. PA state Up with B321 ends with an “expect B330 in 50s” so it defines an implicit route going from 321 to 330, but also gives an upper bound for when we think the train should be there so we can now detect that the train has not gotten there in a reasonable amount of time. This is an error condition.

What can cause such errors and what can we do about them?

• Electrical problem: some panel switch is improperly set ⇒ I’m probably the only one who can fix that. A museum staff could be provided with a very thorough check list and make sure switches all exactly match the list.
• Other electrical panel or power supply issue ⇒ I’m the one who can fix it.
• Mechanical problem: Train derailed ⇒ Staff can be trained about it.
• Train not receiving commands ⇒ Weekly track cleaning + adjust computer to flood send.

The question is what to do in error conditions. Due to the lack of proper communication and coordination with the museum, this has not been defined. One floated idea is to have a warning light + maybe send an email.

---