More info required

Very doable, but more info required.

What type of control system, DC, DCC, something else?

How many tracks in staging?

What type of layout ?

How do the trains get to the staging yard. Will you be making up a train in a yard ? will trains run from staging to staging, eg point to point.

Do you like to tinker or prefer off the shelf ?

How much money do you want to spend ?

Cheers,

Steve

Will evolve with the layout.

Will evolve with the layout.  

1. Because this problem is staging, there are at least three track options with two turnouts.  Clearly to succeed the system needs to know what tracks are empty & determine the route to get there.  
2. The control system is DCC.  
3. The entire problem in staging is TBD.
4. The elements will likely be off the shelf.
5. the decision maker may not be.
6. Or it may be a computer that is specifically dedicated for these automation activities.  

Thoughts

Dear Larry, 

In only a vague order of appearance and/or preference.

- Worth reviewing this thread, as one of the more-recent investigations into "automation" R&D
https://model-railroad-hobbyist.com/node/38389

and if I may

https://model-railroad-hobbyist.com/node/38389?page=0#comment-415836
(Inc many relevant Links and Related Reading)

Easily achieved using Optical (IR or visible light) or Track-Current detection. Commercial and DIY options abound.

This can be both a blessing and a curse, both at the "command station" level
(which make/model of DCC system in-play?)

and at the Decoder level
(What functions/capabilities/commands does the decoder know/understand/respond-to?
If the fleet of locos on the layout have various make/model decoders,
then some locos may play fair, while others do not...
...starting with Automation as a "Must have" may have "obliged decoder choice" implications for the entire fleet).

From a long-time-ago, just one example
https://model-railroad-hobbyist.com/node/6281

...which, by definition means nothing can be decided until the "Problem Definition/Scope" is "determined".

Good thing we're having this conversation then...
(Something about "...the journey of 1000 miles starts with a single step..."???   )

While this is "logically desirable", the reality is that 

"...the more tailor-made/specific the problem-definition and resulting matching solution is,
the less-likely it is to be avaiilable in "turnkey" or "off the shelf RTR" form..."

We'll revisit this in a bit...
(In the mean time, re-read thru the Thread linked-to above...
...it's instructional on this point)

By "Decision Maker", I take it you mean the "Brains" of the Automation system?
If Yes, then Yes, Absolutely agree,

esp if whatever "Brains" you choose are expected to not just drive this yard,
but be "extensible" to cover the (eventual/envisaged) whole layout worth of Automation.

IF you are considerng "automating" this yard in isolation,
and keeping it that way forever more,

then an Arduino
(DIY coding and home-knitted I/O interfacing)

or NCE MiniPanel
(NCE-specific "Programmable Macro controller"
with built-in Input/Trigger and NCE-Cab-Buss Output/Command interfacing)

will likely achieve your desired results in one form of another.

IF however, you are thinking "long game" and looking to deploy an "extensible" system which can grow to cover not-just this yard, but the entire layout,
then a dedicated machine running some form of automation software/scripting, running on a "dedicated PC" is the logical appropriate solution.
(JMRI is the "obvious" US-market-popular answer, but there are others,
again see the linked thread above)

- Is this "inbound train" under Human/Manual Operator control,
(Human "keep driving" til a "mimic signal" tells them to "Stop!")

or has it already been "siezed" and is being "driven"/controlled via the Automation system?
(IE metaphorically the human-operator "crew" has "gotten off the train at the crew-change point",
and the "next traincrew", aka the Automation system,
"gets on the train and drives it onward" IE into the relevant staging-track "parking spot") 

- Does the Inbound Train care which of the available staging tracks it "lands" on?
("...any track, as long as it's empty..." VS "Extra 123 West ALWAYS parks on Staging Track #2")

- Does the subsequent (possibly hours/days/weeks/next-session later) use of that train have any Order, Sequence, or Timing restrictions?

IE if the staging yard is literally just a "send whatever train is next" holding-tank to provide a "constant passing-parade of trains",
and "which specfic train comes next" does NOT have any timetable/operational/sequence importance, 
then "automating" both the Trains and the Yard-Throat Routing systems becomes a Lot Easier...

...alternatively, if "Extra 123 West is THE Next Train",
then Extra 123 West may be Obliged to be sitting on "Staging Track #2",
so the Automation systems KNOWS What train it is Sending, and When...

Is that

"the automation systems guides the train to AN (IE "ANY") empty staging track..."

OR

"the automation systems guides the train to THE (IE "a Specific Defined") empty staging track..."

The Former can be easily achieved as an isolated system with an Arduino, and an appropriate set of Input (Detector) and Output (Turnout swichmotor driver) interface or "edge devices".

The Latter is a far more complex problem to solve, requiring:
- Knowledge of Which Specific Train is "inbound"
- Knowledge of Which Specific Staging Track the nominated Train needs to be directed-to
- (Optional) Knowledge of If/When/Where that Nominated Train will be required again

Now, "which specific train" can be addressed by:
- Loco (RailCom, Decoder and Command-Station dependent)  
- Loco (RFID)
- Train (Software/Sequence-recorded "dead reckoning" VS "dumb" block-occupation detection)

but is not "trivial" to achieve, esp with any degree of reliabiility, determinism, and/or "self-healing".

"specific train to specific track" really does send us straight to "dedicated PC with automation software",
even if the "Scope of Works" will Never extend beyond controlling Only this staging yard.

Ah, this right here is where "decoder specific" kicks-in,
and variations in DCC loco setup can make for Pleasure or Pain.

In no particular order oof preference:

- Simply "dropping power" to a DCC loco will NOT stop the Command Station sending "Go FWD @ xx SpeedStep/Speed" commands to the rails.

Ergo, IF that loco Happens to see power again for whatever reason,
possibly minutes/hours after the last operator Consciously noted what that train was doing,
it will start moving "Unexpectedly", with "mild-confusion/panic" being the least-worst possible outcome.

- ++ to the above if locos are equipped with stupidly-high-capacity KA/CK/SA circuits
("...when I say whoa, I means WHOA..." means NOTHING to a KA/CK/SA, 
the trains is now UNControlled, may roll for inches beyond the Clearance Point,
and are you/the Operators Ready For That?)

- Intelligently stopping a DCC train using one/any of the following:

      - "Stop on DC" braking
      - "Stop on Asymetrical DCC" braking
      - "Set SpeedStep = 0" brake-generator braking

is arguably a better, more-controlled, and "can handle any loco, inc KA/CK/SA-equipped units" solution,
BUT has implications for Command-Station, Decoder, and Automation-deployment choices.
(NMRA DCC Spec says "Ahem, CV27!",
US-Manuf DCC equipment/decoder manufs apparently respond "Don't care"....)

Again, I'd hope you've read thru the above-linked thread,
so already have links to relevant reading/resources RE the above "braking systems", 
but in case you haven't, Google "DCC BitSwitch" for one set of commmercial options...

In short (Too Late),

- What you're considering is entirely possible
- Rest Assured that the Rabbit-Hole you are peering down is absolutely deeper, darker, and potentially more angst-laden than your worst-fears might currently suggest
- "Off the Shelf" components can be used to construct a Complete Solution
- Some of the "Best/Most-application-suitable" components Will Likely NOT be the ones you would Otherwise Prefer to use, and may well be from Euro manufacturers
- ...but it will NOT be operational without some degree of bespoke "knitting" the components together,
- and Absolutely, there WILL be Some form DIY programming or "coding" involved.

Looking forward to hearing the results of your considerations, and any futher questions you may have...

Happy Modelling,
Aim to Improve,
Prof Klyzlr

Thank you Prof

Once again for your generous giving of your time & knowledge.  Just skimming the references that you mentioned lead me to additional links that will help get me there.  I will spend much of the day tomorrow with this assignment and will come back with more questions.  
This is getting at the reason for the discussion.  To do well with automation, one has to plan ahead.  This means give some thought into what level of automation your after.  There are many ramifications to that statement.  My planed 13 x 9.5 around the wall will not come close to the enormous layouts that Prof & John G referenced in one of the links.  However, the vision of what I want to do will bring the needs to light so they can be included with the layout build instead of requiring subsequent rebuilds.  Obviously many concepts and decisions need to be examined earlier rather than later.  I will be back with questions & some initial vision which will go beyond the staging problem.

Can I suggest??

HI Larry, 

If you already have a track plan in mind, can I suggest that you draw it out using a trackplannng software like Xtrackcad? That one is free and comes complete with most commercial track ranges. With more effort you can design for flex track and custom pointwork. You can also set minimum radii so that any flex track will "alarm " (appear as red track) if it goes tighter than the minimum radius you select in the Parameters section. 

This will give you an electronic road map that can be used to set the position of sensors and also provides a "game" framework to check the operational decisions of which train moves when and how far before any conflicting moves occur. 

You also probably need to get your head around the concept of "Truth Tables" when it comes to automating your yard. Simple questions like which end does a train enter or leave the yard  and which sensors flag which tracks are occupied can be laid out in a grid that will help you get your head around where you need to put your sensors and what they "should be saying" to whichever logic system you decide to use to "call the shots" as the overall controller. 

REMEMBER - you are starting to dip your toe into the lake of "positive train control". You need to know what you should be "seeing" from your sensors as well as any "odd/unusual" sensor inputs that could indicate a failure condition that will allow you to park 2 trains on top of each other in your yard.  (OOPS!!) 

Lots of interesting work in those links

Spent some time reviewing Profs thoughts & references.  

Amazingly there are five companies that think they have a solution.  I did a quick review of each, based on their web site info. It is not clear which will be able to learn & relearn what  is needed for the layout automation as it evolves.  

For the specific problem I posed, I actually like Ken’s solution in the older link as far as it goes.  You still have the issue of KA to deal with. As well as where does the automation put the train.  

The figure below is my current thinking of the staging area:

The layout is N scale.  The  over all plan is an around the room layout, with staging behind the main layout on the north wall.  

I have modified the staging since yesterday.  Even at that, I am thinking that another track would be helpful.  It will require another inch or so of width to the staging modules, but that will be worth it.

I have been discussing this build process In another thread here & on my site.  The overall build will be by modules with two return loops on either end.  Until the main layout is completed, one of the “staging tracks will be part of the continuous loop.  Thus the need to be able to change the automation strategy.  

The other parts of the layout will evolve as time goes on.  The important part here will be to pick the proper foundation.  

Prof, my thinking is more like your European friends, ideally the railroad will be able to run by itself, but with one or two others running a specific train. It is the long game that your referred to.

The staging activity for now will be first in first out, there will be east bound & west bound, so in that case specific tracks need to be designated as such, which should make it simpler.  

Based on the little examination so far, the immediate needs are:

1. Finalize the staging track plan 
2. Identify the number of sensor locations
3. Identify the type & manufacturer- based on the reading optical seems to be the right choice
4. The turnout throw strategy also needs to be identified
5. Make a first cut at the other elements required

While the main layout will be made up of different modules that will be mobile, it is not likely that they will leave the room.  When set up separately.  The automation features may not be used at that time.  

At this time I have the choice of decoder for DCC.  I anticipated that a common type or manufacturer would be the case, I am open to that based on factors such as this.  

Because of all of the activity of the day, I was anticipating that an Arduino system would be the choice.  It appears that others have developed some alternates that may be further down the road. As for knitting ing & coding, I was expecting that.  I have done a fair amount of coding over the time.  Most of what I seen is in C which I used to be proficient with.  I will have to shake off the rust a bit, but it will be fun.

This is not a rabbit hole.  It is a problem with many opportunities and potential solutions.  Right now we need to pick a path with some experience, so it will have the fewest surprises and the least resistance.

Thanks again for the references & you time.  Any further help will be greatly appreciated.

Case Study

My layout is automated and it works very well. I can not help on the issue of shutting off power to specific tracks but the software does move the trains around with a click of the mouse.

The components used in this case are--

-Digitrax command station and loconet

-Digitrax BDL168 block detectors on loconet

-Digitrax DS64 stationary decoders for Tortoise motors

-Digitrax MS100 (obsolete but still works) PC to loconet interface

-A PC running Windows

-Train Controller brand software   https://www.freiwald.com/pages/index.html

In the example diagram above you can see how the yard tracks are set up with 3 blocks in each. The blocks on each end are about 3 ft long. These are where the trains will stop. Which block it stops in depends on which direction it is heading.

In the Train Controller software there is a feature called the Dispatcher. Inside the Dispatcher you can create schedules that move the trains between blocks.

Examples:

A train heading WEST from block 2 will stop in block 3 on TRACK 3.

A train heading EAST from block 1 will stop in block 8 on TRACK 2.

A train may be moved from any block to any block.

Virtual on screen throttles and hand held throttles may be used for manual control.

---

Alternatives to this set up that I have seen use JMRI software and NCE with network. The Loco Buffer PC to network interface is an alternative to my MS100.

There may be other brands you can use. Generically speaking you will need:

-A DCC command station with DCC network capability

-Block detectors

-Stationary decoders

-Turnout motors

-A computer

-A computer to DCC network interface

-Automation software

Case Study questions

Dear Eek,

Thankyou for the Case Study, it really is good to get wisdom from someone who's "been there, done that".

Some thoughts/questions arise, if I may?

RE In equivalent to your Digitrax example list,

an equivalent NCE list would look something like

- NCE Command Control (DCC) system
(for the proposed size of the layout and automation, I suspect a PowerPro may be called-for)

- NCE AIU "Input device" interface + whatever form of detector one might wish to use
(Allows "detectors" to feed into the NCE system, and thus to the PC for "input/feedback")

- NCE "Switch-It" or similar "DCC Accessory decoder" for turnout-driving

- NCE "USB Interface" 
(The bridge between the NCE Host DCC system and the computer "Brains" of the automation system)

- a dedicated PC 
(Could even be a Raspberry Pi, does not necessarily have to be a "proper computer" for JMRI?)

- the "Brains" software of your choice
(JMRI, Friedwald, et al
NB Software choice may limit appropriate "Computer" and "OS" options...)

NB the fledgling "LCC" system could well pose a viable alternative to the "Cab Buss" hardware/comms-protocol used by the AIU/USB-interface/DCC-system? This would (theoretically) be extensible and cross-platform/cross-manuf, and would open up access to the mooted TCS DCC command system, and various "not proprietary locked-in" handheld throttles and similar...

https://www.nmra.org/lcc
https://dccwiki.com/Layout_Command_Control
/> https://www.rr-cirkits.com/
/>
https://tcsdcc.com/commandstation
/> https://tcsdcc.com/throttle
/> https://tcsdcc.com/mini-throttle

RE "3 blocks per staging track"

Is this to accomodate
- "bi-directional staging tracks"?
- "Elephant staging" tracks?
- Other requirement?

RE "which block the train stops in"

Do I take it that the software explicitly sends
"FWD @ Speed Step 0 (Zero)" commands to stop Loco Address 1234?

If YES,
- How does/did the software know that "Loco 1234" was the loco that tripped "the relevant detector"?

- If "Loco 1234" is not actually the loco that tripped the detector (for whatever reason),
what happens?
(Is there any "automatic braking backup" or "Big Red Emergency Button" for a human to hit?)

- If "Loco 1234" is "0-5-0 swapped" for "Loco 5678" in staging,
does the software know/learn that the current loco is now "Loco 5678"?

Intrigued...

Happy Modelling,
Aiming to Improve,
Prof Klyzlr

Re: Prof K

Dear Prof,

RE "3 blocks per staging track"

Is this to accomodate
- "bi-directional staging tracks"? Yes this one
- "Elephant staging" tracks? This one would require 5 blocks if bi-directional. I tried it once and it worked but impractical for my style of operations.
- Other requirement?

Do I take it that the software explicitly sends
"FWD @ Speed Step 0 (Zero)" commands to stop Loco Address 1234? Yes. Once the engine crosses the gap to the stopping block, the block detector reports occupancy to the "brain" and the brain sends a 0 speed command. The momentum setting is in play here so I give it 3 ft to coast down.

- If "Loco 1234" is not actually the loco that tripped the detector (for whatever reason),
what happens? If the destination block or any other block along the route becomes occupied for some reason, loco 1234 will pause until the block is unoccupied. The brain tracks the train logically along the route from starting block to stopping block.

(Is there any "automatic braking backup" or "Big Red Emergency Button" for a human to hit?) There is a freeze button and a power off button in the UI you can click to panic. On your keyboard the escape key will power off.

- If "Loco 1234" is "0-5-0 swapped" for "Loco 5678" in staging,
does the software know/learn that the current loco is now "Loco 5678"? It might do this if you set up transponding. I dont use it. You the operator assign a train (or engine) to the block it starts in and the name of the train is displayed in that block. When the schedule is activated the brain tracks the train along its route and its name is displayed in the blocks as it crosses the gaps. When it reaches its destination the train stops and its name is displayed in the block it stopped in.

Automation is an interesting

Automation is an interesting topic.  I have now got two small layouts running with automation using Rocrail, which is a free, open source software that is European based and not unlike TrainController.  I started with JMRI Dispatcher, but compared to Rocrail, the JMRI automation feature is rather 'clunky' (technical term).

The software has to know which loco is where, and I am using Rocrail as the software.  The common method is to have the layout detected, then you digitally put a loco in a block and hit start.  On the monitor you simply drag the loco from the roster to the block. But enough detection is required so that the software knows where the loco is at as it moves over the entire layout.

Detection can be by block detection such as the Digitrax BDL168, or spot detection like IR or reed switches/Hall effect sensors.  I have one layout with the BDL168 and the other with reed switches and Digikeijs DR4088LN's.  Both layouts have stand-alone LocoNets and run Rocrail on Raspberry Pi's.  One is DCC++, the other NCE.

An alternative method to identify which loco is in a block is with RailCom, which requires special detectors and command stations.  (RailCom with a Digikeijs DR5000 is what I am implementing on my own Ho layout)  It could identify the loco as it enters staging.  BTW some have used RFID detectors as well.

The software can route you into an open staging track and stop the train at the desired spot.  Rocrail can add an 'action' when the loco stops in staging, and that 'action' could serve as a signal to an Arduino to open a relay which supplies power to the staging track.

Which brings me to my initial thought for a simple solution, do the staging thing with an Arduino.  You would need a servo to run each turnout, a detector (IR comes to mind) at the stopping point, an Arduino controlled relay for each track, and a push button for each track to resume running.

Sequence: Train enters track and trips detector,  Arduino sends DCC stop command using Geoff Bunza's DCC stop feature, ( https://forum.mrhmag.com/post/sma22-%E2%80%93-low-cost-dcc-controllerfunction-generator-for-animation-test-tracks-absolute-stopping-blocks-for-12202555) then opens the relay to kill track power.  Arduino stores 'occupied' for the state of the track and throws turnouts to an open track for the next train.

When you want to run that train again, you push a switch and the Arduino powers up the track, aligns the turnout, and delays any response to the detection for a given time.  You drive the train away.

Then wash, rinse and repeat.

More info upon request.

automatic stopping blocks

eekdout suggested similar, but the approach i've seen is to disable power in the 3' stopping blocks following a longer block.

in the layouts i've wired, power is controlled thru panel switches.    if not obvious, when the loco runs thru the powered longer blocks, it stops when entering the stopping block.     when run slowly, 3' should be long enough to handle momentum

on a computer controlled layout, power can be controlled with relays.

a 1k resistor is also wired across power switches or relays so that detection circuits continue to work