The Randall Museum in San Francisco hosts a large HO-scale model model railroad. Created by the Golden Gate Model Railroad Club starting in 1961, the layout was donated to the Museum in 2015. Since then I have started automatizing trains running on the layout. I am also the model railroad maintainer. This blog describes various updates on the Randall project and I maintain a separate blog for all my electronics not directly related to Randall.
2023-09-10 - Adjusting the Conductor 2 Program
Category RandallThe last 2 days, we had a problem with the UP automated train stopping just out of the Stockton Station:
At first I was a bit puzzled -- the train was fine, there was no dead block, there wasn’t any reason for it to stop.
This, ironically, turned out to be due to Conductor 2 working as expected: the script had a timing issue, and the automation software was stopping the train because the script said there was an error condition.
To understand the root cause of this, we need to deal with route statistics as explained here, and most specifically this data:
All the details are in the other blog, so I’ll only provide a brief summary here: the script defines the minimum time that a train should spend on a block, and my default ballpark value for this was 10 seconds for all the routes. The software then enforces that -- if a train activates the next block too fast, something’s definitely unusual and unexpected. In automation, we don’t like “unexpected” things. Typically that means something else (like another train) could be occupying that next block, or that the controlled train is going too fast for some reason, or any unexpected thing that would make that next block look occupied to the block sensor. In either case, that’s an error, and the automation software stops the controlled train right away before it crashes into something.
However it turns out that block B503a is really a very small block, and it really can take 10 seconds to cross it, or even less. For a week or so, the timing was very close to that minimum time, but just a tiny bit above. Then the last two days, the train was initially taking just a bit more than 10 seconds (everything’s good) and then, probably as it warmed up, it was taking around 9.5 seconds to cross that block, fast enough to trigger the error mode for the automation.
The fix is of course very simple: adjust the timing for that specific block. In that case, I’ve set it to 5 seconds minimum.
val B503a_fwd = node(B503a) { minSecondsOnBlock = 5 maxSecondsOnBlock = 30 onEnter { PA.bell(Off) } } |
That’s why I added the capability to log statistics at the end of a run, and then made a nice spreadsheet showing every duration spent on every block. This way I have a complete understanding of how I should adjust these timeouts.