Feedback blocks
I’ve divided the layout up into blocks. The blocks feedback the position of trains to the software. The software can use this information to control the trains. For example if a train approaches an occupied block it can slow to a stop at a (currently theoretical) signal.
Each block is connected to a Lenz LB101 block detection module. Each LB101 can ‘sense’ two blocks. These are then wired to an LR101 feedback module - each LR101 handling four LB101s, ie eight blocks - which send signals to the computer via the command station.
Note that all the DCC system sends to the computer is an ‘occupied’ or ‘not occupied’ signal. It doesn’t tell the computer which train is actually in that block. With newer decoders such as the Lenz Gold Mini capable of two way communication this may become possible in the future, but for now, it is up to the software to remember which loco (or locos) is in each block.
The Software Side
So the software has to be told which train is in which block. It also needs to know which direction the train is heading. When a train enters a block it looks further up the line for the next block and, like a real signalman, asks the next block for permission for the train to enter. If the block is empty, the train proceeds.
However, if the block is already occupied, or the block has already given permission for a train from a different direction to enter the block, it denies access for the new train, and the first block stops the train until the next block becomes free.
But that’s a little too simple. Using that system trains would be stopping at the start of blocks, or even in the middle of blocks once they have decelerated.
The diagram above shows my solution. The diagram shows the anti-clockwise loop of the layout, with trains entering from the right. Blocks A, C and E are the standard blocks as described above. There will be signals just past the end of the blocks and just before each set of points. Block C is the station platform.
The diagram shows two extra blocks at B and D. These I refer to as ‘stop blocks’. Their sole purpose is to detect when a train is very close to the signal. Thus the software can detect when the train is at the signal, and make it stop at the correct position if the signal is at red.
So the full system will work as follows: When a train enters section A, the computer asks permission to enter block B. Block B is simply a short stop block, so it only allows a train to enter if both itself and block C are available[1]. If block C is free the train proceeds normally.
If block C is not available the train will decelerate whilst passing through block A (just as a real life train would after receiving a orange signal. As the train enters block B the state of block C will again be checked. If it is now available, the train will now accelerate again, as if passing a green signal.
If block C is still unavailable, the train will be stopped. Since the train has already slowed down while passing through block A it can slow to a gentle halt, rather than the emergency stop it would have to do if it where still travelling at full speed.
Once block C becomes available it will query it’s neighbouring blocks to ask if any of them have a train waiting to enter. If so one of them will be given permission to resume it’s journey.
The same set of actions will be repeated with sections C, D and E.
Well that’s the theory anyway. Most of that capability is built into my software now. I’ve even had a train successfully stop at a signal and resume it’s journey afterwards by placing and removing a resistor on the track, but the software has a habit of sometimes forgetting which train is where, especially when I tried having two trains running together. So I’d better get back and hunt some bugs. See ya next time.
[1] In a fully developed system blocks A and B should operate as one block when allowing a train to enter. Ie. a train can only enter block A if block B is already empty.