One of the new projects we are working on is an “Interlocking In A Box” – a simple, yet flexible piece of signal logic designed to control an automatic interlocking for a diamond on a model railroad. The idea came from one of the mail lists I’m subscribed to and we have been working on refining the definition and designing the signal logic over the past several months. I figured now would be a good time show everyone where we are headed and maybe get some feedback.
Eventually, we plan to offer a complete, assembled and tested system for sale as the MRB-IIAB (MRBus enabled Interlocking In A Box). It will be based on the MRB-XIO hardware, with an optional MRB-FCM running updated firmware to simulate trains on dummy crossing tracks.
The original request was for a single mainline crossing another (dummy) single mainline. On the real mainline, there is also a siding on one side that affects the signal indications shown on the point-end home signal. This is a very simple case, so we decided make it a little more generic in the final implementation. We allowed both tracks to be real and both to have provisions for a siding. Simulated trains can appear on any track, from any direction. Also, signal indications are generic, allowing 3 lights to be driven per signal, for future expansion to take into account occupancy in blocks ahead or any other signal standards.
Being an Interlocking in a BOX, our goal is simplicity. Out of the box (no pun intended), the product should be able to operate with minimal configuration. But, we also want it to have enough flexibility to accommodate a variety of situations. This is always going to be a balancing act.
The primary piece of hardware required is the MRB-XIO. This board provides 40 input/outputs lines, a microcontroller, and an MRBus interface. The interlocking logic will run on this board, taking in block detector and turnout position inputs and driving the signal outputs. The interlocking board is set up to run a complete interlocking with real trains on each track. It can also simulate trains on any track, in any direction, when connected via MRBus to an MRB-FCM fast clock master.
Block detection can come from a variety of sources. The MRB-IIAB is able to interface directly with any optical or current-based detectors that provide logic-level outputs, including the MRB-BD4X detectors. It will also be able to accept detector status over the MRBus network.
To mentally test (brain sim) the various situations that might be presented to the Interlocking In A Box, some test cases were put together. These will also be used to verify the design during development, help communicate its operation to others, and develop custom solutions when requested.
First up are some basic situations (Note: east/west is equivalent to north/south – the logic is symmetric and these cases apply equally well to either case):
Next are some meets at the interlocking:
Four programmable delays are provided for enhancing realism and making single-point optical detectors operate more realistically:
LOCKOUT: After passing through the interlocking, a lockout period is observed where the train, now on the opposite side, cannot be detected as “new” train approaching from that direction.
TIMEOUT: When optical detectors are used, trains present in a block may not always be detected. A timeout is used to “coast” through these period of non-detection. Once a train is detected, the detector must remain in the no-detect state for the timeout period before the interlocking assumes the train is no longer present.
This also affects the situation where a train momentarily enters the approach block but then leaves (for example, switching a yard).
DEBOUNCE: With behavior similar to the timeout timer, the debounce timer applies to the interlocking block. It makes sure when the interlocking detector says the block has just cleared, it really is clear.
For those who get a thrill from these sorts of things, a copy of the state machine diagram is available below (click for larger version). This is current as of today, but may change over time as test cases are run, bugs are fixed, and new features are added. However, it gives an idea where we are headed. The latest can always be found in the MRBus SVN repository in the mrb-iiab/doc/ directory and the corresponding code in the mrb-iiab/src/ directory. That same repository also has all the design files for the MRB-XIO hardware.
No model railroad electronic product would be complete without a test track. The track has been laid and wiring added. An MRServo-2 will be used as the turnout controller. Signals and block detectors will also be added.
To keep things simple (and save some expense), we only have one siding. Since the control algorithm is symmetric and does not distinguish between main and crossing tracks, this should not be a problem.
Since this is a moderately complex piece of signal logic, some form of testing was desired to make sure we meet the requirements and don’t break anything as features are implemented or new features are added.
First, a control panel display was implemented in software. This is a simple “ASCII art” display that reads status information from an IIAB node via its MRBFS driver and displays it in a terminal window.
Second, a set of regression tests are being written, first to cover the test cases shown above, then to add other areas of concern. This test platform provides an automated way to verify that the IIAB is doing what it should and, more importantly, isn’t broken when making changes or adding new features.
The video above shows real tests being run on the actual hardware. The first test is a westbound taking the main. The second test is a northbound taking the siding. The code for both the control panel display (panel.c) and the regression testing (test.c) can be found in the mrb-iiab/src/test/ directory in SVN. Keep in mind that this is very much a work in progress, but (constructive!) comments are always welcome.
We hope you find the Interlocking In A Box interesting and maybe even have a use for it. If you are interested in using this design, please keep in touch and look for updates as we progress with the design. If you have any questions or suggestions for improvements, please also share them, either using the comment section below or via email.