Here’s an idealized turnout, showing the polarity of the frog based on whether the turnout is normal or reverse:

The frog is directly connected to rails A or B via the switch points of a slow-motion turnout motor, be it a Tortoise or a Fulgurex (in the case of the Randall layout). This works for any turnout which has a metal frog which polarity changes based on the turnout position. Examples are turnouts powered by a Tortoise or Fulgurex where the auxiliary contacts from the slow-motion motor are used to change the frog polarity. Another example are the EZ-Track turnouts with a metal frog.

We can directly wire two LEDs, green and red, with a resistance, to the frog and the A / B rails to get them illuminated to indicate the position of the turnout, as follows:

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.