I’m now proceeding with the first tests of the new Conductor 2 “live” at the museum using JMRI and the actual trains, and the first two tests have been… interesting. In the pure line of “no plan survives first contact with the enemy”, both tests were highly “educational” and produced a list of issues to address.

Since I’m doing quotes, let’s also quote Eisenhower’s “plans are worthless, but planning is everything”. The planning I did recently to prepare for the deployment really paid off and I was able to run the tests. A bunch of unexpected things happened during the tests, and I collected enough data to know about what to do next. I would have been highly suspicious if the new automation engine had worked perfectly out of the box. It didn’t, and more importantly I got some valuable data to work on it.

Ironically a big part of Conductor 2 is to have a simulator so that I can try the routes when I develop the automation code without having to actually run the trains. But the simulator is not perfect, or actually it is too perfect. It is idealized, and does not account for a few idiosyncrasies from the real life behavior of the sensors.

So let’s look at what I discovered:

• The UI part is in pretty good shape overall. The new Swing window displays the SVG map and the live block status. Not only that it also gives me the “virtually occupied” blocks, something the previous version was unable to do. It did need a few tweaks which I’ve done already:
• Add a “kiosk” mode to maximize the window and place it on top of all other windows.
• Update the UI depending on whether we’re in simulation mode or live with JMRI. In the latter case, the “quit” button should not quit the app, it merely hides the window.
• Ability to toggle sensor states is currently restricted to simulation mode only. It should also be allowed in the live JMRI mode, at least when the window is not in kiosk mode.
• The every-second speed override should not be running when the automation is off. It makes it impossible to reset the trains.
• The Google Analytics reporting, the JSON state reporting, and the KV Server all worked without issues.
• The tablet does not display the SVG map it receives from the server (works when tried at home though).
• The tablet does not display routes’ state when they are in error since that’s a new feature not coded on the tablet yet.
• The tablet reset action did only reset one of the two routes.
• In the very first try, trains would stop immediately after transitioning out of their parking block. I quickly identified that to be due to the fact that, as soon as they would cross the block boundary, two blocks would be occupied and that was flagged as an error. The route sequence manager was updated to allow this case.
• That’s one case where the simulator was too perfect: it used to always “neatly” transition trains instantly from one block to the next one. But in reality, a train crossing a block boundary means that the two blocks are going to be activated simultaneously for anywhere from 1 to 5 seconds (depending on speed). I updated the simulator accordingly.
• In the second try, trains actually ran a bit after I updated the route sequence manager to account for two consecutive blocks to be activated temporarily. But then sometimes there’s a small unmonitored track section between two monitored blocks, and that is now flagged as the train having vanished. So that’s what I need to handle next.
• In the second try, the passenger train made it all the way up to Summit where it should have stopped and then reversed. Instead it reversed too early, and that confused the route sequence as the train entered the previous block when it was expected to stop.
• Something seems off in the timing. It’s as if all the N-seconds delays happen too fast.
• There were a few quirks in the script:
• The passenger train did not start with sound. Sound was only turned on when it reversed.
• I have not implemented the “5pm automation shutoff” feature yet.

The next feature to handle are the “dead spots” where a train can vanish between two not-so-consecutive blocks, and the early reversal of the passenger train at Summit. I plan to address the first issue using the system of “virtual blocks” which I had discussed before. Once I fix these two edge cases, I will have the trains working with their “default” route as before.

The current script does not exercise the new “automatic recovery” potential of Conductor 2. I coded that in the script yet I disabled it for the initial try to be able to focus on one feature at a time. That’s the part I’ll tackle next. After that I’ll deal with updating the tablet display.