Several angles of discussion for Conductor 2.

First config file. Drop the ANTLR language. Don’t do a DSL using Groovy/Kotlin. Instead let’s keep it simple and use a Jython-based config file (like BUILD files). Sure it won’t be as eye candy as a gradle-like DSL but it might be easier to create and get started.

Example of “pythonizing” the current Conductor 1 script:

B320 = sensor(“B320”, “NS784”) T320 = turnout(“T320”, “NT320”)   PA = route(“Passenger Automation”,            blocks=[B310, T310, T320, B320, T330, B330, B340, B350, B360, T371, B370],            speed_vars=[“mainline”, “station”, “sonora”]) PA.on(B320, delay=10, events=[PA.throttle.speed(5), PA.throttle.horn()])   profile(“RDC”, route=PA, speed_vars={ “mainline”=20, “station”=8 }, …)

This is obviously more verbose. There’s a need to carefully stringify arguments and build lists or dicts where needed. However at that point it’s just about building an API, and there’s one benefit in having typed variables (e.g. a sensor var can’t be used where a turnout is used, etc.)

Using Jython has the “advantage” that JMRI already uses Jython so potential re-users should be a tad familiar with it. I would need to be careful since there’s already a Jython built into JRMI.

Using gradle would of course result in a similar result, but has the obvious cons of providing one extra API to learn.

Now independant of the config format, here are the specs I want for Conductor 2:

• Drop the idea of having adaptive learning. Look at that later.
• Focus on having routes and profiles instead.

Routes were explained before, but let’s get into them again: a route is a succession of blocks that the train is going to travel. E.g. the passenger shuttle is B311, B321, B330, B340, B350, B360, B370, and back. Now there are a few interesting things here:

• Not all blocks have sensors. For example, B350 doesn’t.
• Transition between blocks is not clear cut. Sometimes it looks as only one block is on at a time, sometimes both are seen activated at the same time. It depends. There’s also the slow sampling speed of the NCE AIU combined with JMRI, including default debounce options.
• Some block sensors can be flaky. B320 / B321 is typical. B340 also somewhat.
• Turnouts can play games with the BD20 sensors as they might create a connection between 2 blocks.
• Routes would define variables: speed variation and timer variables, so that they can be adjusted for the route based on the engine running.

Mandatory features I want to have are safeguards & prediction:

• Max time a train should stay on a given block (when moving).
• At the end of the route, automatic reversal for an engine which overshots the block.
• Or more ideally, detection on the next block that would force the auto-reversal.

Profiles are the new addition. A profile is a train composed of a DCC address, a name, and variables for a given route. For example 2 trains can run the short-passenger route: the RDC and the doodlebug. These would be 2 profiles, associated with that route, and defining speed and timings for these engines of that route.

This would allow the RTAC tablet to display and let the staff/operator change the profiles for a given route. Such a change could be done only when the route is idle (not used).

A route is either disabled (no profile/train associated with it), or idle (profile associated but train not started), or scheduled/occupied/busy/running (train has started).

When a route is scheduled:

• On the RTAC software, it should not be possible to toggle turnouts for that route. (Right now RTAC doesn’t do that, but that’s one change I want to make: there would be a safety check to know if a block next to a turnout is occupied + full lock on an occupied route, with maybe some kind of override.)
• It prevents another route using the same blocks/turnouts from starting.

In Conductor 2, route occupation would be all-or-nothing.

Since the goal is to remove the activation buttons at Randall, the next step is to do route scheduling, namely Conductor keeps a list of the start times for the N routes. If there’s no presence at the layout, these would be delayed. We also want to have (start?) end times for the day but this is independant and would be done by turning off the automation toggle.

---