One issue I have on the Randall layout is that operators or automation sometimes short the layout. Then the NCE EB1 circuit breakers take over and of course shut down their corresponding power district. Then operators or staff ask me why things do not work, yet a lot of them fail to check the circuit breakers to see if they are shorting.

One idea I had a while ago was to use an NCE AIU01 to monitor the NCE EB1 circuit breakers. Then I could feed that into my automation software and get reporting of actual shorts right on my status web page.

The proposed solution is to use dual-channel optocouplers to connect the EB1 LED output to the AIU inputs.

Here are the details, as updated on 2020-02-04:

I’ve just finished this project:

The car itself is a Model Power HO Scale “Safety First #624 Searchlight”. It’s a depressed flat car with a nice & sturdy die cast metal construction. It’s really well done.

Jim got it for Randall and when we tried to use it, somehow trains started crawling when pulling the car.

One of the goals of Conductor 2 is to codify and simplify some rules which are explicitly coded in the script for Conductor 1.

One such thing is the handling of train speeds along a route.

Most speed changes in the current V1 script can be codified as the following:

• Speed change when entering a block.
• Speed change within a block (with a delay).

A lot of the rules have extra conditions to make them happen only for a given route, and a specific direction.

Both combined gives us some explosive combination numbers: if this route is active, in this direction, and in this block, then set the train speed to such.

I have 2 suggestions.

Starting to implement the occupancy manager in Conductor 2 immediately showed an issue in the default route mapping: the default idle block of one route cannot be part of another route.

So let’s backup and analyze this.

Jim gave me this engine, with the sole purpose of changing the horn. How hard can it be?

Jim got this engine for Randall in commemoration of the 150th Anniversary of the Transcontinental Railroad.

My first attempts at doing that video were miserable as the engine would stop constantly at slow speed and I tried a few things to see if I could improve the power pickup.

One of the main concepts to be added in Conductor 2 is the concept of routes.

Conductor 1 already has “route” definitions. These are actually intended for display on the remote tablets. A route is defined using:

• A name,
• A DCC throttle object, used to display the engine speed and direction;
• The JMRI sensor used for the automation toggle on/off.
• A counter of number of times the automation started (incremented by the script).

The counter thing was a quick attempt at gathering some stats initially and never used -- it’s technically displayed by RTAC on the tablet, but the UI layout was designed for 2 routes, and with the current 3 routes the counter is ironically not visible. Even when it was visible, nobody was looking at it. Thus I suggest dropping it eventually, which will remove a couple lines from the script.

The concept of routes in Conductor 2 is supposed to be more elaborate. However I’d posit it can just be an extension of what is in Conductor 1 at the syntax level in the script.

So what properties would I want in a Conductor 2 route?

Routes, Profiles, or even the latter idea of Includes for Conductor 2 are all vaguely unsatisfactory.

Includes are just a hack in the current v1 script language which do not really solve anything.

The core issue is modularization of the script.

One concept I explored earlier in the 2018-12-08 post and that I still want are routes.

A route is a sequence of blocks and a reservation principle. They have different modes, e.g. global interlocking vs ABS window interlocking. I think this concept is good and should be kept as-is.

Conductor 1 uses a custom language implemented using ANTLR 4. The goal for Conductor 2 is to reuse an existing scripting engine.

Continuing with this, recently I started looking more closely at Lua to see if it could be a potential configuration language.

I have been thinking about my definitions of routes & profiles for Conductor 2 and I am not convinced they will be useful as such for Randall.

I am interested in two kind of routes:

• “Linear simple” routes: typical circuit loop with ABS-type block guards. There are mostly linear and simple means they don’t have complex rules. There still could be customizations: different speeds for different blocks, specific customizations such as grade crossing horns, etc. Some of these may depend on an engine number (especially sound F functions).
• “Dedicated Shuttle” routes: this is mostly what we have at Randall right now where routes are a mix of generic block mapping conditions and carefully dedicated to specific engines.