I'm writing my own DCC software to control the layout. Here I'll describe it as it develops. I don't know how technical to make this section - it could get very detailed, so please let me know if theres anything you'd like to see here, especially if you are also writing DCC software.
Saturday, March 04, 2006
Debugging feedback blocks
Last time I mentioned I was having problems with the software forgetting which train was in which block.
Closer investigation showed that there was a problem with one particular block. The train would leave the block and the ‘occupied’ light would go out, but shortly afterwards the occupied light would come back on and stay on.
I checked the wiring but there where no faults there, so I ran a test train over it at slow speed. For testing I’d hooked up a loco to a rake of coaches. Normally for block detection you would wire a resistor across a wheelset at the end of a train, otherwise you would just detect the presence of the engine. But I hadn’t got around to installing any resistors on the coaches.
So the block would read empty while the coaches where still occupying it. I didn’t think this would be a problem for some simple testing. However, occasionally one of the wheels on the train was making an electrical connection between the two block segments and the Lenz LB101 block sensor would be detecting the presence of the loco in the briefly linked block. And for some unknown reason it would fail to register the block as empty once the connection was broken. My assumption is that there is a fault in the Lenz LR101 feedback sensor when there is only a momentary signal on the input.
Later I’ll add some extra code to the software to double check the LR101 status when such a spurious signal arrives.
I removed the carriages and testing with one loco now worked flawlessly.
I added a second loco and again all worked fine - the trailing loco successfully stopping at the entry of the previous section whilst it waited for the first loco to exit. But I did notice on a couple of occasions that the LR101s would fail to successfully report that a section was empty. Usually this was corrected when a loco entered or left another section using the same LR101 (the LR101s report back the status of a block of four feedback items at one go).
That was until the lead loco simply refused to enter a section which was shown as being empty.
This afternoon I added a lot of extra code to the software to log the state as it gets updated by locos entering and exiting blocks. I’ve left two locos trailing each other around for over an hour waiting for the problem to recur but, as sods law often dictates, everything ran perfectly.
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.
When I bought my DCC set I included a Lenz LI101F computer interface. As a computer buff, with a desire to automate things, I couldn’t resist the temptation to build a computer controlled layout.
I intended to buy software to do the control and people seemed to be recommending Friewalds TrainController. I downloaded a trial version. At the time the only layout I had was a small double track oval. No point motors. No feedback modules. All I could do was use a throttle to control the trains.
This was definitely overkill for such sophisticated and expensive software. And I also found that the trial version kept timing out after a very short period. (They, of course, don’t want people using the software for free, but I felt I needed longer playing time to decide whether I liked it or not). So for the time being I stayed with the hand controller.
But as a nosey sod, I couldn’t help but take a peek at the on-CD instructions that came with the PC interface. At eighty pages of techno talk they where enough to put any sane individual off writing his own software. But I’m a fairly good Delphi programmer. And I really wanted computer control.
So, one afternoon, like an alcoholic dramatically falling off the wagon, I started writing some code. Actually, once you get down to it and realise that the worst of the technical stuff is completely irrelevant stuff that only affects the communications between the PC module and the command station I realised it wasn’t so difficult at all.
It’s just a long list of commands and responses that need to be implemented: “Set loco speed and direction”, “Set loco functions”, etc. It was just a case of starting at one end and working my way to the other.
So after a couple of afternoons work I had a basic throttle available on the computer, and was enjoying a thrill from driving a train via the PC that, for some reason, isn’t present when using the hand controller. Maybe it’s just because I wrote the software, a bit like the way food tastes better when you’ve cooked it yourself.
Feedback
So it was Christmas, and I was making plans to start on the proper layout. I needed to work out how to do feedback and turnout control from the PC in order to know how to build such things into the layout from the start rather than having to modify it later.
So I wired up some block sensors and a feedback module to a small test track and made a start on adding feedback code to the computer. All fairly simple - if you know how.
I’d pretty much decided that adding a nice layout plan to the software with the ability to switch points and plan routes would be great but probably best left to a proper piece of software. But I fell of the wagon a second time and found myself writing code for a pretty layout designer, to which I added my feedback modules.
The Present
Which brings things to the current date. With the outside loop of the layout laid and wired I was soon bored with running a single train around at a time. I wanted my computer driving the trains. Which, with the current layout, basically means I want a passenger train which stops at the station with every loop and a goods train which slowly follows. The fast passenger train being checked at the signals when it catches up with the goods. The goods waiting outside the station while the passenger stops to pick up and set down passengers.
And from there a want the computer to select a road into the fiddle yard for me and to choose which train to run so I can sit back and just watch trains go by.
