![]() If you pick up a train from one block and place it in another then the software won't understand. With Traincontroller this is done by dead reckoning, but other software (eg Rocrail) will need a second sensor to tell it the train has fully entered the block. However block A will not be released (nor turnouts in between) until the software has calculated that the train is fully in B. When the train leaves A the detector will go off (usually when the engine leaves). Each route is a pair of blocks so a train scheduled to run from, say block A though B, C and end in D will allocate routes A-B, B-C and C-D. Same when an detector goes off.Ī schedule is a series of routes. ![]() So when a train enters a block, the occupancy detector comes on and the RS8 signals this change to the DCC system and to TC, and TC does the rest by its tracking logic. I didn't realise that 'train tracking' was the defacto standard (what would happen if I picked up a train and put it somewhere else and then started a timetable?)Įach block is electrically isolated from others (and turnouts between blocks which are not normally part of blocks). RFS that's quite interesting - so essentially you broker the RS8 blocks between the bus and the rail sections. You will have defined the stop points as well as the brake markers (ie tells TC when to start slowing down). With this information it's able to being a train to a stand at an exact point by simple dead reckoning. TC profiles all your locos by a process that runs the loco back and forth over a measured block at various speeds so that it then knows the speed profile of the loco. With automated schedules, one of the hard tasks is bringing a train smoothly to a stand in a block either for a scheduled stop (station etc) or unscheduled stop (red signal). When you run a train via an automated schedule, or manually through the software, TC is able to track the trains round the layout because it knows which way the points are set (and sets them itself for automated schedules) so when an occupancy detector goes on it knows which train it is. In other words it knows the starting position (ie which trains are in which blocks and which direction they're pointing). Like other automation software, TC works via simple train tracking. The other rail is connected directly to the bus. Each block is fed from a port on the RS8 and is isolated from adjacent blocks via an IRJ, with the feed from the RS8 being to one rail only. In my case, with Lenz LZV100 command station, that's the LDT RS8 which manages 8 blocks. With this software, the only detection required is an occupancy detector. Mr Holland also has push buttons which immediately active a given route program in his software - and I gather that's the same kind of question - is that DCC traffic going around the bus, or some additional layer of connectivity? ![]() Fundamentally I understand how accessory decoders are controlled, but even those expensive detectors I have seen that can return specific train occupancies seem to only do so via LCD screen as opposed to comms back to the controller itself? Holland is manually switching trains as well as using automated timetables. What kind of magical occupancy detector is this? Surely it's not just logic based on the last known location, because Mr. The system appears to know where each locomotive is at any one time, and uses this as the basis for protection/interlocking and to facilitate automated movements. I understand how route setting works with software, but on the aforementioned thread northolland there are two features which really stand out to me: As per the post in the wonderful Chapeltown thread I've seen that DCC is mature enough now that computer control is fairly par for course if you're that way inclined, and there are dozens of software options for automating some and all parts of your layout.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |