rrinker Though to be fair you can do perfectly reliable automation without Railcom if you have reliable detection. It's not too hard in software to keep track of the order in which blocks go live so if you know the starting point you know whaere a given train is at any point just by watching the sequence of block detections. --Randy
Though to be fair you can do perfectly reliable automation without Railcom if you have reliable detection. It's not too hard in software to keep track of the order in which blocks go live so if you know the starting point you know whaere a given train is at any point just by watching the sequence of block detections.
--Randy
It would be handy to see at a glance what engines are sitting on which tracks in your hidden staging !
Mark.
¡ uʍop ǝpısdn sı ǝɹnʇɐuƃıs ʎɯ 'dlǝɥ
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
Remember, RailCom is TWO way communication. The same way the command station reads a new engine when its placed on the rails, the detector relays that same information back to the command station. The detector itself is programmed for that specific block. Whenever any engine enters that block, it relays that engine's information back to the command station for which block it has control over.
Taking a step further, the detector can also relay information to that same engine telling it to automatically slow to a stop if the next block is occupied or a red signal is indicated.
RailCom is a key factor in automation if you have all the components required.
How does the block detector know which loco is in it?
passenger1955 Thanks Mark. Those are all good practical applications. On that block detection, I wonder how the loco knows what block it is in (so it can pass that information back to the controller)?
Thanks Mark. Those are all good practical applications.
On that block detection, I wonder how the loco knows what block it is in (so it can pass that information back to the controller)?
You have it backwards .... the loco doesn't know what block it's in, the block detector knows what engine is in IT. The block detector then relays the engine information back to the command station. The command station can then indicate engine 1234 is in block ABC.
I don't use JMRI, but I would assume if it is capable, using their dispatchers board, it would automatically populate the board with what engine is where as well. Does JMRI support RailCom ?
I'll probably be the odd man out with the system I use - ESU EcoS - and all my sound equipped engines are running Loksound decoders, both of which utilize RailCom.
RailCom is basically two-way communication between the engine and the command station. When I place a new engine on the rails, the EcoS automatically detects the RailCom communication from the decoder and imports all the decoder's information into the system (engine address, sound file, active function buttons and even the function button icons that I have selected during programming). This eliminates me from having to manually enter that information into my system.
Another option using RailCom is to use RailCom equipped detection units. These detection units will not only display that something is occupying the block, but will also tell me the engine number that is in that block.
There are numerous other options that I have yet to explore, but it does have its benefits IF your decoders and system support it.
I've been learning about DCC and acknowledgements during service mode. I'm reading through RailCom documentation. What are some of the practical uses of RailCom? Is this intended for use on the operation track (as opposed to the programming track)? Is it meant to allow you to program CVs on the operation track? Outside of CV programming, what other data is envisioned that the loco/decoder might send back to the command station?