Model Train-related Notes Blog -- these are personal notes and musings on the subject of model train control, automation, electronics, or whatever I find interesting. I also have more posts in a blog dedicated to the maintenance of the Randall Museum Model Railroad.

2022-08-03 - Conductor 2: An Update on Implementation

Category Rtac

Although I haven’t posted anything here lately, I’ve spent most of the summer time completing the implementation of the engine for Conductor 2. The new kotlin engine is working well, with a suitable battery of unit tests, and I have a functional simulator to exercise the engine before I try it at the museum. I also converted the latest Conductor 1 script to the new Conductor 2 DSL. It’s all in the bitbucket repo under the dev branch:

We can compare the Conductor 1 vs Conductor 2 scripts right here:

Click here to continue reading...


2022-04-26 - Conductor 2: Route sequence graph in Kotlin DSL

Category Rtac

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)

Click here to continue reading...


2022-04-25 - Conductor 2: Kotlin DSL vs Groovy DSL

Category Rtac

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:

Click here to continue reading...


2022-03-15 - Dead Spot Detection Car for DCC

Category Train

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:

Click here to continue reading...


2022-02-13 - Conductor 2: Sequence Manager and Block Graph

Category Rtac

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.

Click here to continue reading...


2022-01-23 - Conductor 2: Block Graph and Travel Direction

Category Rtac

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.

Click here to continue reading...


2022-01-22 - Conductor 2: Startup corrective behavior

Category Rtac

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.

Click here to continue reading...


2022-01-22 - Conductor 2: Error Management

Category Rtac

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.

Click here to continue reading...


2022-01-21 - Reboot on the Reboot on Conductor 2

Category Rtac

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.

Click here to continue reading...


2021-07-04 - How do the Electroluminescent (EL) Displays Work?

Category Train

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).

Click here to continue reading...


 Generated on 2022-10-03 by Rig4j 0.1-Exp-666f4a7