Going to change the way a route sequence graph is defined in Conductor 2 from:

nodes = listOf(

    listOf(B311_start, B321_fwd, B311_rev),

    listOf(B321_fwd, B330_fwd, B321_rev, B311_rev),

)

to:

nodes = listOf(B311_start, B321_fwd, B311_rev)

branches += listOf(B321_fwd, B330_fwd, B321_rev, B311_rev)

Over the last few months, I re-implemented my Conductor 2 prototype entirely. The initial Groovy DSL project lacked a clear structure, so I scratched it. And since I was rewriting it from scratch, I explored using a Kotlin DSL instead.

The verdict is to go with the Kotlin DSL approach.

Highlighting the pros and cons:

Here’s my latest DIY experiment: a homemade “dead spot detection car”.

Here’s a schematic and a rough explanation of how it works:

This is designed to work exclusively on DCC track.

The goal is to help operators detect dead spots on the track, either by rolling the car manually or by pushing it with an engine as seen above. They need to move it till the front green LED turns off. That will allow us to determine where the break in the track continuity is located. Then using the yellow LEDs, we can determine if the break is in only one rail or both rails.

This isn’t just about breakage in the rails, either. The original motivation was to help me find issues with unpowered frogs on the layout’s turnouts. In this case by moving the car manually over a turnout, we should be able to see a green LED go off when the frog or the closure rails are not powered correctly.

When building this, LEDs polarity does matter as shown in the following electrical schematic:

Conductor 2 is organized around the concept of routes, and each route as “manager” which defines its behavior. Upfront, I envision 3 types of route managers: idle (does nothing), sequence (aka shuttle mode), and window (a “free” algorithm better suited for continuous runs).

Right now we’ll focus on the sequence manager, for shuttle operations.

In Conductor 2, each route has its dedicated route type, driven by a “route manager”.

For our shuttle routes, we define an almost linear block list of blocks traveled.

• Normal:        B311 → B321 → stop/reverse → B321 → B311.

As seen above, to handle the rare case of the end-run overrun, we want to actually have a block graph.

One of the potential benefits of route management in Conductor 2 is being able to fix the invalid start behavior. In conductor 1, we simply cannot start the mainline automation if the trains are not at the startup point. For the branch line, I do have some self correction.

We need to dwell a bit more on error management in Conductor 2. What is the current situation, versus what we really want?

In Conductor 1, error management is made ad-hoc by the script. For each individual route (branchlines vs mainline), there’s a timer, and the goal is that each shuttle should complete its travel within 5 minutes. The implementation is rather simple: the timer is started when the engine starts in either direction, and stopped when the engine reaches the target block. If the timer expires, the global state is changed to error, which stops everything for that route. There is nothing in the script to get out of that error state. A manual reset (via the tablets) is necessary.

In Conductor 2, the error management should depend on the route manager. Here we’re only concerned with the shuttle “sequence” manager. We can decide to keep it as simple as it was in Conductor 1 -- namely that the route must complete in a given time.

That Conductor 2 project has been taking too long now. I still think there are good ideas in the design and the core foundation for it. The implementation has been taking forever due to a lack of clarity combined with some other projects taking precedence.

In between I have started an implementation in Groovy which is not quite satisfactory. It was merely a prototype to explore the DSL syntax and as such the project structure has not been carefully planned. It’s already hard to extend and I realize I’m not able to express the script logic as I want with it. The core issue is that the prototype tried to do too many things -- explore how to create a Groovy DSL, figure out the language I need, and at the same time the business logic of the script. So I have a bit of everything, and nothing concrete for each category.

So let’s reboot it. Let’s tackle it differently. Ignore the syntax. Focus on what the script business logic needs to work. I can express that “on the paper” using the ANTLR script language from Conductor 1. I’ll figure the DSL and engine structure from there.

We’re in the process of adding a Miller Engineering animated sign on the layout, and later I want to revive the 2 broken ones (the theater one and the motel one). So naturally I wonder how they do work… What's the tech behind it?

Looking at the Miller Engineering site, they have an “experimental” section, which partially replies to that question:
https://microstru.com/collections/experimenter-kits

So these are listed as “electroluminescent” (a.k.a. EL) displays. The Miller ones come with a little control board, and they are typically powered by a 4.5 V DC power supply or 3 x AAA batteries. They call the board an “inverted”, and it features an obvious transformer, so that gives us a fairly good clue on what it does (i.e. that’s a voltage booster).

Today we’re modifying this cheap “Motion Sensor LED closet/night light”: https://amzn.to/3qqVBqS

So here’s the situation: the back room at Randall where we have the workbench presents some challenges. The switch to turn the room light is in one corner of the room, and we enter the opposite side of the room. And in between we have the Bridgeport yard, the Napa yard, and the workbench. Thus when we enter the room we need to carefully navigate around all these things mostly in the dark till we can turn on the light. Not ideal. Most of us use our phones as a flashlight to avoid tripping into something. Can we do better?