Some options...
Dear David,
A couple of solutions come to mind:
Analog Option #1 : simple "dead zone" system
IE
- a gapped loco-length "stopping section" in one rail at each of the perscribed stopping locations,
- with power feed to each stopping-section switched by a relay
- relays triggered by a derivative of the "flip flop" circuit as seen on Rob Paisley's "Misc electronics for Model Railroads"
http://home.cogeco.ca/~rpaisley4/CircuitIndex.html#Automatic
PROs
- should be capable of handling as much current as the LGB loco might demand
- very simple to troubleshoot
- compatible with any loco (locos can be freely swapped, system will still work)
- compatible with loco facing-either direction (Loco can be end-for-end swapped, system will still work)
- Cost effective
CONs
- hardware reliant
- may require arguably more wiring runs (dependent on how the system is actually designed/distributed/deployed)
- requires hardware and circuitry design of the 555-timer-based "Human-Input interface"
Analog option #2 : Analog with "smart" controls
Basically the same as above, except using a TI Launchpad, Arduino, or similar cheap microprocessor as the "recieves the button presses, triggers the required stopping-section relays".
Suggest checking the "Dawson Station" blog for one example
http://dawson-station.blogspot.com.au/2010/02/how-dids.html
PROs
- should be capable of handling as much current as the LGB loco might demand
- reasonably simple to troubleshoot
- compatible with any loco (locos can be freely swapped, system will still work)
- compatible with loco facing-either direction (Loco can be end-for-end swapped, system will still work)
- Cost effective
- never stops, always "fail-safe"
(no active detection means the loco will _always_ keep moving until it gets to the location intended by sheer dead-reckoning)
CONs
- both hardware and software reliant
- may require arguably more wiring runs (dependent on how the system is actually designed/distributed/deployed),
although waaaaaaay less than the 555-based system
(no inter-555-chip "logic jumpering", all logic handled by microprocessor code and "which button was pressed" input commands)
- requires hardware, circuitry, and software design of the Launchpad-based "Human-Input interface"
DCC option #3 : NCE Powercab with MiniPanel "brains" and BD20/AIU feedback
Levering the internal macro capability of the MiniPanel, along with Track-detection BD20/AIU feedback, a DCC-controlled loco can be predictably triggered, and run until it hits the desired location (as detected by the BD20s). Additional fucntionality can be introduced thru the iuse of DCC, IE a sound equipped loco can play various sounds/tunes, additional accessory decoders can easily provide related action/animation.
While arguably requiring less cabling (theoretically a Track Buss OUT around the layout powering everything and sending commands, and a Throttle buss Back returning feedback/detection), the programming and configuration may be tedious for some.
Suggest checking James Ingram's "Auto-Controls" website
http://track2.com/ingram/home/index.main.iac.shtml
PROs
- easier design of the system interfaces (trigger buttons direct to the MiniPanel, detection via AIUs)
- more capability in terms of "what the train can do if/when triggered"
- off-the-shelf components
CONs
- Cost for a "simple run-to-the-place-we-want-it-to" system
- Requires direct programming of the MiniPanel
(both easier and harder, depending on the application and who you ask...)
- Requires a decoder installed in all active locos
(cannot just "drop a fresh one on the track and go")
- Requires a decoder installed in all active locos
(This is G scale, current draw and decoder choice will be critical for long-term reliability)
- Does not handle "spontaneous" swapping of locos well
(automated commands are address-specific)
- Does not handle "swap loco end-for-end" conditions well
(commands are loco-direction-specific, not "direction of travel" specific)
DCC option #4 : NCE Powercab with JMRI "brains" and BD20/AIU feedback
Similar to above, but replaces the dedicated MiniPanel microprocessor with a generic PC + JMRI software + Logix Scripts + PC<> DCC interface
PROs
- same as above
CONs
- same as above
- adds a PC which MUST be turned ON and left-running for the system to operate
(more parts, more complexity)
- adds "PC problems" (Operating System, Driver and Interface, HDDs stability, App stability, etc etc) to the potential problemshooting mix...
(Willy Occum was onto something)
- adds manu more AIU units to cover the required number of "trigger input" switches
(replacing the human-interface Input circuitry lost when the MiniPanel was removed...)
Hope this gives you something to start with...
Happy Modelling,
Aim to Improve,
Prof Klyzlr
PS I don't "reccomend the right solutions",
(and respectfully, waiting for someone to drop "the perfect solution in your lap" will only result in you waiting a long time...
).
Rather, I seek to make suggestions that hopefully spur the modeller on to nut-out the best solution for themselves...
(I'm not standing there in the room with you,
you'll be able to "develop the most-appropriate solution-for-the-specific-problem-criteria in-the-field"
far faster than anyone else can "blind, by remote control"...)