An interesting challenge sir

My initial thoughts would some sort of straight DC version of a stationary decoder . . . .though wiring such a thing woul dbe a tad challenging.  Seems what you need is an auto reversing circuit (of which there are many available) that's wired to a DPDT toggle switch that connects to the "main" power circuit.  By isolating the shuttle route with insulated track joiners or styrene pads, and wiring the toggle between the reversing circuit an dthe feeders for the shuttle route I think you have all the options covered you outlined.  The tuning fork part would be handled because the shuttle section would be isolated from the main,a nd with the toggle thrown to allow the reversing unit to control this part, you would just need an automated turnout control to access the various parts of the fork.

Now I'll go get more coffee and figure out what I've missed.

Allan Gartner has one

Here is the link to Allan Gartner's site thread about his office cubicle train.  The circuit is simple, cheap, and has a time delay.  Look part of the way down the article to find the circuit and the description.

http://www.wiringfordcc.com/cubicle_main.htm

Can DCC do this?

Dear Don,

I'd not seen Alan G's solution before, but when I looked at the circuit,
it looked decidedly similar to the one shown on Rick Paisley's "Misc Electronics for Model RRs" page

http://home.cogeco.ca/~rpaisley4/AutoRevCheap.html

The circuit looks interesting for sure, but in asking the question, 
I was/am really hoping for a DCC-based solution to be presented...

I've been led to believe that analog is dying, and DCC is the future.
As such, I need to know that there is a DCC solution which can do what I need it to do.

Again, Many Thanks for your Considered Opinions...

Happy Modelling,
Aim to Improve,
Prof Klyzlr

JMRI:Dispatcher Run Trains Automatically

From the JMRI website

"Running Trains Automatically

Dispatcher supports running trains around the layout automatically, provided the layout meets minimum requirements. Once an automatic Active Train (called an Auto Active Train) is created, it is run automatically by a virtual engineer using a computer throttle. The Auto Active Train follows signals around the layout, and performs user-specified Actions, separate from Dispatcher. When an Active Train is created by the dispatcher, automatic running may be requested in the Activate New Train window, and options specific to the Auto Active Train are set at that time.

The dispatcher allocates Sections to an Auto Active Train in the same manner as allocating Sections to an Active Train run manually by a human engineer. From the dispatcher point-of-view, Auto Active Trains are treated the same as manually run Active Trains. There are two exceptions to this"

I think this will do what you want. Read up on it at the JMRI website here. jmri.sourceforge.net/help/en/package/jmri/jmrit/dispatcher/Dispatcher.shtml

DCC

Prof,

I didn't suggest DCC when I first saw your post, as it sounded like you wanted a system where the end client could grab any number of locomotives from a pool, drop it in and let it go. Initally that sounded like you were only interested in DC.

Besides the automated running feature of JMRI, also be aware that some DCC decoders have playback - you can run a sequence of actions, and the decoder will remember it and repeat them upon request. Not as useful in this situation with the turnout, but still something to consider.

One other advantage with DCC is that you can tune all of the locomotives in that pool to run at the exact same rate - whether they're geared steam, or a modern passanger train. I am presuming from your description that this piece is for display, and that may be of use to you.

Good_Luck! 

I'd prefer both...

Dear Scarpia,

Your description of the "system" is pretty much spot on,
at a show, one cannot afford any loco to hesitate while "onstage".
Ergo, the moment any loco gives a sign of problem,
it's removed (and booked for attention as soon as is practical),
a replacement loco is dropped in it's place,
and "the show continues on"...

NB that a show layout may be continuous, point-to-point, or "switching". Ergo, both _Manual_ and _Automatic_ modes of operation are desirable. The ability to switch between modes _on_the_fly_ with but a single toggle-switch "enable/disable" control, and the expected controls on the throttle, is the aim. Such "User Interface Limitations" may seem severe, but when I have a crew of 4 operators + myself at the show, "simple user interfaces" which are "at a glance" understood, (while not limiting the practical operations of the layout), are mandatory.

In extreme cases, (although I've never had the misfortune to have to go to this extreme),
if all "pre-prepared show locos" have failed for whatever reason,
(a un-diagnosed "scenery malfunction" during transportation of the layout to the show,
has resulted in all locos getting polyfibre wrapped around their valvegear, for example),

I have witnessed show-layout operators head accross the show hall to the traders,
buy a suitable loco, get it out of the box,
and "save the show" right then and there by deploying it immediately...
(a show layout with no trains running is a diorama, and even when the trains _are_ running,
to hold any given "general public" viewer's attention for more than the spec 30 seconds is a significant achievement...)

Please don't think I'm "only interested in analog DC",
I really _want_ someone to demonstrate that DCC can do what I need it to do, hence my posting the question...
(It's not that I'm "only interested in DC",
it's that I have a very definite set of parameters to work with,
and _any_ proposed solution needs to be able to forfill _all_ of them...)

What already is "proven working" is my "fallback",
I'm got my eyes and mind wide open to allcomer options,...
(the floor is open for whoever wishes to step up to the mic with a solution...)

Happy Modelling,
Aim to Improve,
Prof Klyzlr

I'm personally pretty excited

I'm personally pretty excited about this feature of DCC, this idea of pre-programmed routes.  One other thing I think would be cool was if the couplers were all automated as well, because then you could essentially let your yards "sort themselves" or let your industry switcher "switch itself" or let the mainline frieghts run loose while you switch the yards or industries, depending on your facny.  The latter is available now, of course!!

I was originally confused by your first post.

I was pretty sure that you were running dcc, but then you wanted to interchange locos as needed and just have them operate as soon as they were put on the tracks.  Others who are much more savvy about some of the possibilities than I am have made some good suggestions for automatic operation, I think.  In the show situation, I think you would need to have a dedicated fleet of "show locomotives" that are all programmed to the same decoder address, in order to change out locomotives and keep the show going.  Obviously, the spare locomotives could not be kept on a "live" track, or they would all try to run at the same time.  I may just be showing my ignorance, but I don't think there is any way to interchange locos with different addresses to keep the show going without calling up the new address on the operating system.  With the E-Z dcc system that my club uses, calling up a new addresss on a throttle takes less time than it does to actually put the loco on the track, but I'm not sure how quickly other systems would work or how quickly a new address could be called up in "automatic mode."

Wouldn't the simple solution

of putting any number of locos on the track and have them work without calling up a new address be as simple as consisting your "pool" of locos, even though they aren't technically in a consist?  This way, no matter what loco you drop on the layout, it will perform exactly as any of the other ones in the consist.

JMRI and museum projects

Prof,

I recommend that you post this question on the JMRI yahoo group.  There are a number of regular posters there who are working on museum projects, some of which are highly automated.  

http://groups.yahoo.com/group/jmriusers/

Of course, this may take you down a path with a learning curve with a high initial slope.  But, the long term results may be worth the trip.

Dear MRH Team, Many many

Dear MRH Team,

Many many thanks for the suggestions thus far! from the various thoughts, I haven't yet distilled down a practical "recipe" for a working solution, but there are some logical concepts being presented which are definitely worth chasing.

If I may, however, I'd like to try and "steer" the current stream-on-consciousness brainstorming, by
- looking at the suggestions
- comparing to some research I've already done on this problem,
(Yes, I have been looking around myself... )
- assessing the ideas against the "specification" given from the outset

and then seeing which ideas "show the most promise".

Don A brought an analog DC solution to the table, from Allan Gartner's excellent "Wiring for DCC" website. There are a numbber of such circuits floating around online, one of my faves being from Rick Paisley's "Misc Electronics for Model Railroads". Such circuits can easily achieve the required behaviours, and are a "known quantity".
(extra info: when the 12VDC power feed is dropped to these circuits, the reversing relay resets to an entirely _known_ _predictable_ setting. Therefore, a single "cut power" SPST toggle will allow the track power to pass _thru_ the relay unaffected, and under _direct_manual_ drive control from whatever throttle is feeding the "shuttle route").

However, as noted in the OP, the aim here is to get a DCC-based solution. Without wanting to diverge away from a reasonably sane "Problem> Analysis> Solution" thought path, I've been led to understand that Analog Control has a number of issues which will lead to it's ultimate demise. Ergo, before that "cut-off" point comes, I need to know that the most likely successor Control Option (IE DCC), can perform the tasks required of it.

Rob T introduced the idea of JMRI as an "automated throttle" system. This is entirely logical, and with the ability for JMRI to run on quite tiny/old machines, I _could_ see me building a small rackmount "JMRI box" which plugged directly into any of the show layouts in question, and "just working".

However, I see a number of potential issues, which we'll get to in a moment.

I'll note at this point that for the sake of the "Brainstorm", we're not considering $$$ as a decision criteria. Once we find "the Solution that fits the Problem", _then_ we'll scare ourselves witless working out how much $$$ we're up for/how "cost-effective" it is...

Scarpia recalled that some DCC decoders have the ability to record and playback "action sequences". These initially showed promise when I investigated the early BLI offerings. However, with no form of "positional feedback", I had the experience of a loco
- shuttling on a length of flextrack on a hobbyshop bench
- gradually "creeping" towards one end of the flextrack for every "shuttle cycle"
- and eventually derailing/shorting itself out when it "fell off the end" of the test track

Given that the layouts in question in my case are likely to use decoders from a number of different manufacturers, anything "decoder specific" such as this "sequence play" mode will be limited in it's applicability.
(Cuts accross Point #4)

I also take the point that DCC allows "speed matching" of various locos, but in prototype a geared loco simply _could_not_ match a modern passenger train for speed. Ergo, I'd prefer to have the "shuttle time" adjustable such that it is guaranteed to be longer in duration than the time required for my Longworths Class B 25t Climax #1375 to traverse the "shuttle route" at "1 sleeper/min" speed, and thus be guaranteed-compatible with any shorter "shuttle route", or train travelling at "faster speed".

Russ B made the point that for show work, there are usually a pre-prep'd roster of locos intended specifically for operation on the layout. They therefore can be "custom programmed" to operate on any "custom control system" that the given show layout may employ. This is largely true, but does not allow for the kind of "Panic" situation I described in the 6th post in this thread (which is broadly covered by Point #4 in the OP)

In extreme cases, (although I've never had the misfortune to have to go to this extreme),
if all "pre-prepared show locos" have failed for whatever reason,
(a un-diagnosed "scenery malfunction" during transportation of the layout to the show,
has resulted in all locos getting polyfibre wrapped around their valvegear, for example),

I have witnessed show-layout operators head accross the show hall to the traders,
buy a suitable loco, get it out of the box,
and "save the show" right then and there by deploying it immediately...

To get around the "no reprogramming when replacing a loco" issue, Russ suggested

 I think you would need to have a dedicated fleet of "show locomotives" that are all programmed to the same decoder address, in order to change out locomotives and keep the show going.  Obviously, the spare locomotives could not be kept on a "live" track, or they would all try to run at the same time.

Again, while logical, I have 2 issues with this.
(both of which are relevant to the assessment of Rod T's suggestions from earlier).

Issue 1- as Russ identified, this would require any currently-not-running locos to be lifted clear of the tracks, or parked on isolated spurs.

Assuming for a moment that the "Shuttle Route" and the "Main Route" are being fed by the same trackbuss/booster, and thus that both the "manual direct drive" throttle _and_ the JMRI "shuttle throttle" are both simultaneously sending commands to _both_ routes, this would seem unworkable. It would be impossible for
- JMRI to drive "loco #3" on the shuttle route
- while a Manual throttle tried to drive "loco #3" on the Main Route
(as both commands are passed via the common booster/trackbuss)

Seperate Boosters, Track busses, and possibly even complete Command systems?
Sure, but you then loose the ability to "drive a loco onto the shuttle route" as per Point #6

The "isolated spur" technique is possibly the simplest for currently-not-moving trains which are "staged in plain sight",
(EG I had a logging layout which had _NO_ "hidden staging", but by parking
- the loaded train at the sawmill
- the MT train at the Log Loading area
- and having a "passing loop" for a 3rd train
I could "stage 2 out of 3 in plain sight", and have the 3rd keep the show running...)

but immediately knocks out things like "onboard sounds occuring while the loco is stationary".
(not mandatory, but an awful shame to loose, bearing in mind that onboard sound is one of DCCs "party piece" advantages)

Issue 2 is more an idealogical one, but stated plainly
- if DCC's primary drawcard is "every loco addressable individually",
- and the "Main Route" (manual) operation seeks to take advantage of this behaviour

then, setting all decoders to "address #3" (for example), seems entirely counter-productive in the greater scheme of things.

Am I trying to "have my cake, and eat it too?" Absolutely!
Not to pull any punches, but if DCC wishes to be "all things to all men", then the ability to
- address each loco individually on demand (which DCC does very well)
and simultaneously
- to "shuttle any loco on a defined track/route without needing to explicitly address said loco,..."
(The fact that it is currently sitting _on_ the shuttle route is explicit enough to define the desired operation),

"...or re-compile/reprogram any "smarts" in the circuit..."
(load JMRI coding, reprogram NCE MiniPanel macros, etc)

is what I need to see.

"Chainsaw" Dave came to the party with an idea that seemed to be able to bypass this "individually addressible VS everyone-responds" issue, using the Consist functions. I had recently had simiilar thoughts, and put them to the NCE-DCC and DCC4EVERYONE YahooGroups. It appears that NCE (my preferred DCC system) has 2 methods of consisting, "Old" (NMRA Compliant) and "Advanced".

"Advanced" consist info is apparently held by _both_ the individual loco decoders _and_ the NCE command system. This means that,
- create an "Advanced Consist" on a given NCE-comtrolled layout
- lift the locos,
- and place them on any _other_ layout (NCE powered or otherwise)

and the "Consist" worth of locos will likely _not_ "just remember" that they are a "consisted set"

The "OLD" consist method however only relies on a given CV to be written into each decoder. Therefore, yes, it _would_ be possible (in theory) to set an entire layout roster worth of locos to "Consist #X", despite the locos never actually locking couplers.

The question was asked "if a loco _thinks_ it's 'part of a consist', will it still obey commands sent to it's _unique_ individual address?"

Response from both yahoogroups says "'Advanced Consist' = NO, 'OLD Consist' = YES"

Hmmm, so this is all looking good. We can have all locos "globally respond" to a given Consist address,
while still being able to be manually overridden/"driven away" on their Individual addresses...
(with the caveat that the “direct commanding” is a function specific to NCE, and is only known to work if the consist was created on a given NCE handset.
IE there is no information RE whether it will work if a Secondary Unit such as NCE-MiniPanel/JMRI was sending the “consist” commands,
while a regular NCE handset was sending the “direct control” commands).

There's only one possible “fly in the ointment”, as mentioned above.
- If _whatever_ device (JMRI, NCE MiniPanel, etc) is sending "Consist commands" thru the same booster/track buss as the "Manual drive" throttles,
and
- that single Booster/Trackbuss is feeding _both_ the Shuttle Route _and_ the "Main (manual drive) Route",

then will the loco that is currently being "manually driven",
recieve and respond to the consist commands?

SO, to wrap, we’ve got lots of great ideas,
but to mis-use a quote from “U2”,
“…I still haven’t found, what I’m looking for…”

Some side-effect info which came to light this weekend:

- using a handful of diodes and a rail-gap can create an “Asymetrical DCC” stopping block,
which is allegedly supported by all NMRA-compliant DCC decoders

Has anyone had experience with this form of DCC train control technique?

- There are a few companies that produce units which sit _between_ the booster and the track,
which do “station stop” and other localized control tricks,
apparently independently of the specific loco/address in question.
(BitSwitch is one such company http://www.dccbitswitch.co.uk/timedstopbitswitch.htm )

Unfortunately, they don’t do the equivalent of the “dumb timer/reverser” mentioned by Don A,
but a combination of such a unit + the above “asymmetrical DCC stopping system” would appear to be a “perfect fit” solution.

- There are also more advanced units available which are DCC system specific. Apart from obliging the use of a given DCC system,
it would seem that they are “single use equivalents” of a JMRI rig,
(IE not greatly different, just replaces the PC you first thought of).

http://www.cmlelectronics.co.uk/index.php?page=shop.product_details&flypage=flypage.tpl&product_id=20&category_id=7&option=com_virtuemart&Itemid=106

Hmmm, lots to consider,
but I don't think we've determined a “working solution” quite yet…

Love to hear any further thoughts from the Collective Wisdom…

Happy Modelling,
Aim to Improve,
Prof Klyzlr

I have to ask - is this an

I have to ask - is this an honest inquiry, or are you simply fishing for an example of where DC might be a better application?

Hoping it's the former, I do have a couple of other points.

Multiple locos. It would seem that four locos should cover your needs. If you think you would need more, I would argue that the control system is not the place to address that problem - it would be better handled by addressing the issues that cause that directly.

Speed Matching - certainly you can't get the slowest loco to go as fast as the fastest, but  that wasn't the point - the point was you can find a spot where all of the locos in your pool can run at the same speed, meaning the display will perform the same regardless of motive power selected.

Cost. Cost has to be a factor, otherwise simply hirer someone to run it during the length of the show, and be done with it. But lets presume we have some "cha-ching" to play with.

Recording and playback  - The only loco I have that can do this is a Walthers F3, and I haven't seen the drifting you mention, although to be fair, I haven't done it more than a couple of times. I wonder if there is a difference in manufacturers.

Controls. Without being an expert, I would suggest optical sensors at the end of each line that would trigger the computer system to slow, stop, and reverse the train when the sensor is occupied. This cannot be a complicated program, although admittedly, I'm not a programmer.

I'd recommend a Mac Mini as the driving computer, recommended for it's small size and weight, it seems a good choice for a mobile solution, and can be controlled off of a tablet or iphone, negating a monitor. There is another advantage for your display, you can set up some small, hidden speakers, and have the computer play ambient sounds - a great combination for sound equipped locos!

Wouldn't ask if I wasn't serious...

Dear Scarpia,

I can totally understand why you might draw that conclusion,
and be under no mis-illusions, analog can and currently is performing the current mission admirably on a number of layouts locally that I am aware of (under both "show work" and "home layout" situations).

While I _could_ push the
"DCC is oft suggested as being an 'everything to all men' Control System option,
here's a genuine practical application, where's the DCC solution?
Oh, it can't do it?
Sorry, but there's a techfail right there" button,

I'm electing to _try_ and rise above my own pre-concieved ideas and past experience,
and be genuinely open to any (addresses all of the criteria) solution that DCC can provide.
(Seriously! I _know_ you're laughing right now... )

I'm concerned that my own research has not turned up such a solution,
or in some cases, has turned up potential solutions which
- achieve the required "Shuttle system" specs
- while simultaneously _dis-abling_ basic DCC behaviour which would be key to converting from analog in the first place...

Seriously, am I asking/expecting too much?

Happy Modelling,
Aiming to keep my eyes and mind wide open in the search for a Solution,
Prof Klyzlr

PS In my Pro Life as a Audio Studio Tech, such "Solution must fit Problem"
(no matter how oddball the Problem Criteria may initially appear),
 analysis/solution/deployment is a regular feature.

It works for global broadcasting situations, where there's far more "on the line" than any Model RR I'm aware of,
and it's yet to steer me wrong in my "Modelling Life"...

PPS A number of close modelling friends very nearly had heart attacks when they heard I'd bought a basic NCE rig maybe 12 - 18 months ago. The fact that it has yet to be used "in anger" on any of the layouts under show _or_ home conditions (beyond occasional "tinkering" and testing), is simply a reflection of "it hasn't been the right tool for the task at hand" at the time...

PPPS having wired all of my previous layouts with "quick connect" and "suitable grade" techniques from the outset, it appears that the layouts themselves are effectively "DCC ready" without any significant modifications.
(with a suitable 4-pin plug on a SB3 booster, I can swap between my existing analog throttles and NCE DCC rig as fast as it takes to un-plug one, plug in the other, and ensure the correct locos are on the track).

IE I really do _want_ a DCC solution, and am reasonably prep'd to make it happen,
if only it were possible/available...

Take a peek

Take a peek at this

http://jmri.sourceforge.net/help/en/html/tools/automation/

This is the scripting info I was talking about.

JMRI Scripting solution : Thanks...

Dear Scarpia,

Thanks for that, it does indeed look like the kind of thing we're talking about.

- If the script can address a "consist" address instead of individual "loco addresses"
(with the assumption that all decoders will still listen and obey commands issued to their "Unique address",
even while CV19(?) has a "Consist address" loaded in it)

- and I can equip a cheap laptop + SPROG + "input detectors" or similar to run the "shuttle route"
(effectively a completely standalone DCC control rig),

- _and_ I can switch the "shuttle route" track feed between the "JMRI + SPROG" combination and the "Main Route"s NCE rig,
(should be easily accomplished with basic aux switching from the "junction turnout" throw,
with no additional "User Interface" to navigate),

then we may well have a working solution...

There are a few other options I'm chasing down at this point, but I'll definitely give this a shake,
and report back if there's any significant test results...

Again, Many Thanks

Happy Modelling,
Aim to Improve,
Prof Klyzlr

Every body is going over the

Every body is going over the top with this.  I wrote up and delete at least 5 replies to this thread.

I am a " Digitrax" user thru and thru, JMRI user,  but read about other  company DCC  stuff  that comes out that looks interresting just  for the knowledge. I could offer a Digitrax solution using JMRI.

Problem with the Sprog is it does not talk to any other device unless it is thru the rails. Sprog can switch turnouts for you but will not handle the detection messages as they are not sent thru the rails. This requires a communication bus (Loconet, XPressNet, CABBUS, RS232/RS485).  So the Sprog is not a fully viable solution here.   

The solutions that uses JMRI would have you learning JMRI, PanelPro, Layout Editor and  scripting.  Since you do not mention signaling ( because JMRI's SSL is great at this )  JMRI  would be overkill here in my view. Plus setting up an old boat anchor PC with Windows XP, JAVA, JMRI to have it run a back and forth script and then  find out it chokes under the load, is not fun. If you want to learn JMRI, for future use, go for it.  

Have you looked at the new NCE Minipanels. Flexible and programmable. Does require you have an NCE command station for control and the BUS but it is one sweet little device.

From NCE you would need command station,  Minipanel,  Auxiliary Input Unit (AIU91),  2 detectors (BD20), turnout decoder (Switch-it).

http://www.ncecorporation.com/minipanel/MP-tech ref.pdf

http://www.ncecorporation.com/minipanel/Mini-p program.pdf

You would pretty well have the automated operation covered with this.

Hey I am not even an NCE user, I think they stink

Sprog does not talk to

Sprog does not talk to any devices apart thru the rails.  Stationary decoders  will accept turnout commands via rails but they can not RETURN information via rails.  This requires some type of communication bus (Digitrax Loconet, Lenz XPressNet, NCE CabBUS, C/MRI RS232/RS485)  so the detectors can send back information to be processed.    

So some form of bus and  detection is required, then you also need turnout control.  One option for detection and turnout control could be the Digitrax SE8C and one BD4 giving you detection of 4 blocks, turnout control via manual or computer control via  PC/JMRI/ and.. problem..  Sprog does not talk LOCONET. 

You could get around this using a Loconet device as the ' Master ' (Locobuffer  or PR3)  as a replacement for the command station and have a stand alone ' Loconet ' talking to the PC/JMRI via PR3 or Locobuffer. You can still use the Sprog for engine control.

Now  you must write up a script or use those included in the JMRI package,  modified  for your needs.

The script could be very simple. Back the train from A to C. Once detected by D2 the engine is told to stop under its own momentum setting.  Since the speed is slow, momentum could be adjusted to keep the train off the floor.

Now the script would switch T1, change engine direction of travel, move it forward till detected by D1.  This use of D1 on both A and B spur is a fail safe. If T1 does not get throw for any reason, the engine WILL be detected on either spur and be brought to a stop.  So basically you  are shuffling between D1 and D2.  no need for timing apart pauses between moves.

Few niggly bits. Do not have any other current drawing item wander onto  this T-fork while the script is running or he will throw the proverbial wrench in the script on you.

The other  niggly bit is the change from PC to Human control.  Simple would be to have a  second command station. If using a single command station you will encounter  contention between throttles OF THE SAME SYSTEM for the engine/decoder.  Resolving this requires  added coding to release and acquire the decoder. So you either stop the script, pause the script or let it run.

PC/JMRI/Sprog are  still running the script in the back ground  when you transfer control of the engine to Human. Once you bring back the engine onto the T-fork section, it will immediately take off on you, once DPDT is toggled. The script WILL have been  waiting for the engine to get from C (D2) to  A or B (D1)  of the T-fork and that is fine. Trip the DPDT and off it will go.  Doing the switch over from PC  to Human when the engine is stopped in C, with the head light OFF (programming)  could be the indication to toggle the DPDT over to HUMAN.   I hope this last portion is clear, it is in my head.

The NCE solution sounds much simpler to me.

Locos do not need to be consisted or addressed the same.

I'm really only familiar with the E-Z DCC system, but have an NCE Power Cab  that I bought for my future home layout.  I haven't tried the NCE, yet.  If it is easy to simply call up a new address when you switch out locos, you locomotives could all have separate addresses in their respective decoders, and when you need to switch out a loco, just call up the new address in the dcc system that is running that train.  I'm not familiar enough with dcc to give advice on how to do the rest of the things that you want to do to keep one train running on a specific route with specific, repeated actions.

Russ

That is not viable in an automated, script running, environment.  That would mean you must have ALL the decoders entered into the script or change the script on the fly and tell it  "  who's on first  ? " . and like the Abbott and Costello sketch, people get confused quick. 

The simplest is to put the engines that would be automated  ALL on the same adresse, let's say 3. Then all that is required is drop the engine on the automated section of track  and off it goes. 

You could even use DecoderPro and a roster with specific CV settings and fire off this roster to any decoder that will travel automated.  Any engine picked up in a pinch could get it's CV listing read (as a courtesy to the lender) and saved and then get restored to factory defaults. Once that is done have the  "SHOW"  profile sent to it in a few minutes.  All you really need is adresse CV01=3, CV03 and CV04 settings.  The rest, in a "SHOW",  you do not really have to care about.

I may have misunderstood the o.p.

I thought he was talking about a short train with only one loco being used at a time in automatic mode.

+ +

To me he is using a train (short or long) and a single engine for the  automation portion.

To do automation, using either the JMRI solution or the NCE Minipanel requires the decoder adresse be known to the script (JMRI) or the Minipanel programming. 

If, for some reason,  you have to change the adresse (let's say the engine wraps the packing around the drive train, or brakes something)  you would have to go back thru the script and  change the adresse it is using or have all possible adresse all ready entered in the script. On the  NCE  Minipanel this means going thru it's automation programming to change the decoder adresse assigned to the task. 

So if he uses adresse "03"  both cases it is simpler to change the base adress on the decoder  to "03" and put it down  on the track than going thru the script or back thru all the minipanel program using those little buttons.

ROCRAIL may be an answer

To simply use DCC control with intermediate stops is to use some sort of feed back and a computer.

the computer controls the trains and uses block detection and the software to tell where the train is and what it should be doing

whether you use feedback through Digitrax, Lenz, S88, MERG CBus or any other system

I am at the stage of setting up my layout (still under construction) with feedback to my computer

JMRI is a good system but you need to learn to program (may or may not be easy)

RocRail ( http://wiki.rocrail.net/doku.php) has automation built in and is from what i have read it is relatively easy to do, setting up rules (acceleration and braking blocks.

I have not had a chance to test my DIY DCC and feedback system (S88 thanks to Paco Canada's Nanox S88 system.   http://usuaris.tinet.cat/fmco/home_en.htm based on expressnet)

I still have not made up my mind as to which system that I will use, but it is another "free" option out there.

cheers

Shraps

Shuttle no problem

if you use a decoder that has Asymmetrical DCC such as Lenz Gold or Silver:

All it takes is 5 diodes and a switch. I have a shuttle running all the the time with this method.

Take a look at the link below,

http://www.tonystrains.com/technews/lenz-asy-abc.htm

1/2 way there...

Dear Perone,

There's a lot to like about the Asymetrical DCC system,
the diode-stopping sections appear to mirror the current analog solution, a la

http://home.cogeco.ca/~rpaisley4/AutoRevCheap.html

However, do I take it that Asymetrical is a proprietary function of Lenz decoders,
or is it truly an "NMRA compliant DCC" function?
(I guess what I'm tilting at is, assuming there may be DCC-sound equipped locos in in play,
are LokSound and Tsunami likely to "play nice" with an asymetrical system?)

If this works as hoped with the expected range of decoders, then all we'd need to complete the picture is

- a timer-reverser unit
- which can send loco-address agnostic broadcast "change direction" commands
- and is wired in _between_ the booster and the shuttle-route trackage,
(IE such that only the track feeds to the shuttle-route trackage recieve the "reverser" commands)
thereby not broadcasting to the _entire_ layout.

Hmm, this is possibly the most promising response thus far...

Happy Modelling,
Aim to Improve,
Prof Klyzlr