Jeff
My intent was never to argue this. I just wanted to point out a concern of mine with DCC. Training operators is a priority but in the end we are all human and do make mistakes. It's good to know that there is someone out there that can realize my critiques are constructive criticisms that are only meant to better the current technology, not bash the people who use it.
Check out the Deming Sub by clicking on the pics:
el-capitan wrote: Wrong. A block does not just allow or disallow operation of a train there. A block determines WHAT train operates there. A power district can be shut off but cannot allow one train to run there and disallow another. It's the difference between changing channels and turning off the TV. If you have a single line block system with blocks named A-B-C-D-E in that order, how do you (with DCC) allow cab 1 to operate on only A&B and cab 2 to operate only on D&E?
Wrong. A block does not just allow or disallow operation of a train there. A block determines WHAT train operates there. A power district can be shut off but cannot allow one train to run there and disallow another. It's the difference between changing channels and turning off the TV.
If you have a single line block system with blocks named A-B-C-D-E in that order, how do you (with DCC) allow cab 1 to operate on only A&B and cab 2 to operate only on D&E?
I don't see a point to arguing the semantics of cabs and blocks, the point you make, which is true, is that all trains within a DC block will be controlled by the same cab/throttle, which should greatly reduce the possibilty of a confield meet.
Well, the obvious 'smart' answer is to train the engineers. But, the technology is there, or nearly so to do what you want. I haven't read all the details, and I don't know how it works, but Digitrax's transponding can locate the trains. The 'all you need' is software in the control station that's smart enough to not allow a loco to move into a zone occupied by another. The algorithm to do this would need to know quite a bit about the layout (another thing the command station doesn't know right now), and some rules for how to operate. I rather expect the pieces to do all of this already exist in different products and homebrews, but it could be quite some time before it hits the point where a user friendly, commercially viable system exists.
I can understand your reasons for preferring this method of operation for the trains you run. I'd never have thought of this as an advantage of DC, but I don't have the same concerns you do. It just points out the truth that there is no one right answer.
Jeff But it's a dry heat!
Wrong again. Your block system does not control trains; it only controls operators/cabs. The block you describe has no control over which train is in a block; only who can run a train in that block.
This is my last response to this thread; I have more important things to do.
el-capitan wrote: Alan I understand the difference in how they work. DCC is much better in most respects. But a power district is much different from a block in how they function. Any engineer running DCC can run his train from one power district to another without the dispatcher knowing. On a block system an engineer can only operate on tracks designated by the dispatcher. DCC takes this control away from the dispatcher (me). I probably have some kind of god complex and I definately have control issues. I get these things by owning expensive equipment that I don't want to see get damaged because of a careless operator.Please explain to me how I can accomplish these three things simultaneously:1. Have good multitrain operating system.2. Be in control of my entire layout from one control panel with 4 operators independantly running trains.3. run a minimum amount of wire4. Spend a reasonable amount of money to do this. Remember, if the price goes over $1,200 I will just by a new Santa Fe Mountain from Sunset.
Alan
I understand the difference in how they work. DCC is much better in most respects. But a power district is much different from a block in how they function. Any engineer running DCC can run his train from one power district to another without the dispatcher knowing. On a block system an engineer can only operate on tracks designated by the dispatcher. DCC takes this control away from the dispatcher (me). I probably have some kind of god complex and I definately have control issues. I get these things by owning expensive equipment that I don't want to see get damaged because of a careless operator.
Please explain to me how I can accomplish these three things simultaneously:
1. Have good multitrain operating system.
2. Be in control of my entire layout from one control panel with 4 operators independantly running trains.
3. run a minimum amount of wire
4. Spend a reasonable amount of money to do this. Remember, if the price goes over $1,200 I will just by a new Santa Fe Mountain from Sunset.
You seem to a problem with blocks and power districts. They are one in the same as in identical physical things with different names. A block with a switch (switched block) and a power district with a switch (switched power district) are identical.
Switched blocks do not tell you where trains are nor do they offer any type of control of what trains do; they simply allow/disallow operation of a train that is there. DC or DCC does not matter.
If you like operating with switched blocks; fine with me. If you like for a dispatcher to have control of those switches; again fine with me. DC and DCC are interchangeable under these conditions.
el-capitan wrote: Alan_B wrote:[Not picking on you as an individual; however, most of this thread is pure BS. You are assuming that block control is only used on DC. It can be used equally well on DCC if you want to. Block control is not related to DC or DCC. It is a means of controlling track power. The actual running of trains is determined by the operation of the DC power pak or the DCC throttle. I have used DC and now have DCC and will never go back. Why do I get so much static anytime I point out that DCC is not perfect? I know what DC is and I know what DCC is. But I have never heard of anyone setting up blocks for separate cabs on a DCC layout. Many people with larger DCC layouts have and should be able to break down large layouts into smaller areas by installing isolation switches to make it easier to find shorts. Other than that every DCC layout I have ever been to has always ran a buss wire the entire length of rail for power.Are you suggesting I replace my four DC throttles with four separate boosters and run four independant DCC cabs? I wouldn't see the point (aside from better sound and lighting features) of making this huge investment in DCC. Do you know any one who has ever done this? Please explain.The best two things DCC has going for it are multitrain operation and simple wiring. If you take those things away much of the allure of DCC is lost.And please keep in mind, the title of this thread is "The quest for the ultimate Multi-train system". I am only trying to point out that DC with block control is not perfect and DCC is likewise not perfect and what I would want in the ultimate system. DCC has done more to help this hobby since electricity was standardized. I know how great it is. I want it better. Also, I'm not picking on you as an individual, but you are yet another in a long line of DCC faithfuls not able to admit that there is a higher risk of collisions on (non-block) DCC layouts.
Alan_B wrote:[Not picking on you as an individual; however, most of this thread is pure BS. You are assuming that block control is only used on DC. It can be used equally well on DCC if you want to. Block control is not related to DC or DCC. It is a means of controlling track power. The actual running of trains is determined by the operation of the DC power pak or the DCC throttle. I have used DC and now have DCC and will never go back.
I have used DC and now have DCC and will never go back.
Why do I get so much static anytime I point out that DCC is not perfect?
I know what DC is and I know what DCC is. But I have never heard of anyone setting up blocks for separate cabs on a DCC layout. Many people with larger DCC layouts have and should be able to break down large layouts into smaller areas by installing isolation switches to make it easier to find shorts. Other than that every DCC layout I have ever been to has always ran a buss wire the entire length of rail for power.
Are you suggesting I replace my four DC throttles with four separate boosters and run four independant DCC cabs? I wouldn't see the point (aside from better sound and lighting features) of making this huge investment in DCC. Do you know any one who has ever done this? Please explain.
The best two things DCC has going for it are multitrain operation and simple wiring. If you take those things away much of the allure of DCC is lost.
And please keep in mind, the title of this thread is "The quest for the ultimate Multi-train system". I am only trying to point out that DC with block control is not perfect and DCC is likewise not perfect and what I would want in the ultimate system. DCC has done more to help this hobby since electricity was standardized. I know how great it is. I want it better.
Also, I'm not picking on you as an individual, but you are yet another in a long line of DCC faithfuls not able to admit that there is a higher risk of collisions on (non-block) DCC layouts.
Individual block control, with more than one cab, is the only way to run multiple trains with DC (unless one throttle setting works for more than one engine). Independent control, under DC, can only be obtained with multiple cabs (and therefore multiple blocks). None of this is necessary with DCC.
A good number of DCC run layouts have multiple blocks (sometimes called power districts). My layout has 8 power districts all run from the same power source and all accessible from multiple throttles and all isolated from each other. Only one of them has a switch (I use the switch to switch from operating track to programming track to OFF). I use tail light bulbs as isolators and current limiters. I chose not to install switches for each block. The light bulb is a visual indicator of shorts (opens are obvious from a stopped train with no throttle control). I could use as many districts as I want and could put switches in each.
Unlike DC, I can operate several trains from one throttle, each with different speeds/direction: OR I can use several throttles for several trains.
What you "normally" see is that people realize that the complicated wiring required for DC multi train operation, is not necessary (meaning that it is optional) for DCC. It could be used for DCC; therefore the issue in BS when comparing systems, unless you understand that it is required for DC and optional for DCC.
The beauty of DCC is the simplified wiring that is actually required and the lack of switches needed to run trains. You tend to spend time with the enjoyment of running trains and not with the necessary DC task of operating switches just to keep trains running. Neither system will prevent operator induced errors or problems.
If you want control; you can have it with either system. If you want simplicity and just the enjoyment of running trains, DCC is the best choice.
el-capitan wrote: BRAKIE wrote: marknewton wrote: el-capitan wrote: If the engineer fails to stop for whatever reason (inexperience with the rules, not knowing the town names, not paying attention) on my DC layout he will hit the block boundary at the end of the siding and the train will stop, probably causing a short circuit. If my layout where DCC his train would continue on through the siding, into a tunnel where a head-on collision could happen with the oncoming train. This is one of the con's to DCC in "my" bookIn my book this has nothing whatsoever to do with DCC, it's a problem with the operators. Whether it's a DC or DCC layout, bad driving is bad driving...Mark. Absolutely! While theres been 1 or 2 freak DC head ons at the club we have had more then our share of side swipes due to inattentive train handling and ignoring red blocks. I agree. Bad train driving is bad train driving. However, on a DC layout engineers are confined to operate on the section of layout that a dispatcher sets for them. Even my home layout travels through 3 seperate rooms. As the dispatcher I cannot see where every train is but since I have DC I know that train 2 is either operating on one of the blocks that I set for him or he is at a dead stop at a block boundary (I usually keep a block shut off in between trains to avoid rear-ending the train in front.) I do not have this type of control over my layout with DCC.I run 2 rail Oscale. My heaviest steam locomotive is over 12 pounds. I've know people to own steam engines that weigh over 20 lbs. All of my cars weigh close to or over a pound each. When 2 Oscale trains hit head on it's not like 2 matchbox cars bumping into one another. a 40 car train can weigh over 50 lbs. That's alot of mass to be stopping all at once. I tend to want to avoid this.The title of this forum is "The quest for the ultimate Multi-train system". not "101 reasons why DCC is perfect". I love what DCC has done for the hobby. I would probably have it myself if I didn't need to make the choice between spending $1000 to put decoders in all of my locomotives or buy another brass steam locomotive. I just want more. I want to be able to dispatch from my laptop on wi-fi from my backyard. There would be a schematic on my screen of my entire layout. If I click on a turnout, it switches. I would be able to see all of my trains run around on the schematic and know exactly where they are. Maybe GPS locators in each engine and caboose. Come on, I can look on the internet to pinpoint exactly what seat my kid is sitting in at the movie theater because he has a gps cell phone, why can't that technology be used in railroading.Finally, I want one, just one, DCC guy to admit that accidents are more likely on a DCC layout over a DC layout. Even if its only.01% greater, admit that it is more likely. Because I have yet to hear someone with DCC say that.
BRAKIE wrote: marknewton wrote: el-capitan wrote: If the engineer fails to stop for whatever reason (inexperience with the rules, not knowing the town names, not paying attention) on my DC layout he will hit the block boundary at the end of the siding and the train will stop, probably causing a short circuit. If my layout where DCC his train would continue on through the siding, into a tunnel where a head-on collision could happen with the oncoming train. This is one of the con's to DCC in "my" bookIn my book this has nothing whatsoever to do with DCC, it's a problem with the operators. Whether it's a DC or DCC layout, bad driving is bad driving...Mark. Absolutely! While theres been 1 or 2 freak DC head ons at the club we have had more then our share of side swipes due to inattentive train handling and ignoring red blocks.
marknewton wrote: el-capitan wrote: If the engineer fails to stop for whatever reason (inexperience with the rules, not knowing the town names, not paying attention) on my DC layout he will hit the block boundary at the end of the siding and the train will stop, probably causing a short circuit. If my layout where DCC his train would continue on through the siding, into a tunnel where a head-on collision could happen with the oncoming train. This is one of the con's to DCC in "my" bookIn my book this has nothing whatsoever to do with DCC, it's a problem with the operators. Whether it's a DC or DCC layout, bad driving is bad driving...Mark.
el-capitan wrote: If the engineer fails to stop for whatever reason (inexperience with the rules, not knowing the town names, not paying attention) on my DC layout he will hit the block boundary at the end of the siding and the train will stop, probably causing a short circuit. If my layout where DCC his train would continue on through the siding, into a tunnel where a head-on collision could happen with the oncoming train. This is one of the con's to DCC in "my" book
If the engineer fails to stop for whatever reason (inexperience with the rules, not knowing the town names, not paying attention) on my DC layout he will hit the block boundary at the end of the siding and the train will stop, probably causing a short circuit. If my layout where DCC his train would continue on through the siding, into a tunnel where a head-on collision could happen with the oncoming train. This is one of the con's to DCC in "my" book
Absolutely! While theres been 1 or 2 freak DC head ons at the club we have had more then our share of side swipes due to inattentive train handling and ignoring red blocks.
I agree. Bad train driving is bad train driving. However, on a DC layout engineers are confined to operate on the section of layout that a dispatcher sets for them. Even my home layout travels through 3 seperate rooms. As the dispatcher I cannot see where every train is but since I have DC I know that train 2 is either operating on one of the blocks that I set for him or he is at a dead stop at a block boundary (I usually keep a block shut off in between trains to avoid rear-ending the train in front.) I do not have this type of control over my layout with DCC.
I run 2 rail Oscale. My heaviest steam locomotive is over 12 pounds. I've know people to own steam engines that weigh over 20 lbs. All of my cars weigh close to or over a pound each. When 2 Oscale trains hit head on it's not like 2 matchbox cars bumping into one another. a 40 car train can weigh over 50 lbs. That's alot of mass to be stopping all at once. I tend to want to avoid this.
The title of this forum is "The quest for the ultimate Multi-train system". not "101 reasons why DCC is perfect". I love what DCC has done for the hobby. I would probably have it myself if I didn't need to make the choice between spending $1000 to put decoders in all of my locomotives or buy another brass steam locomotive. I just want more. I want to be able to dispatch from my laptop on wi-fi from my backyard. There would be a schematic on my screen of my entire layout. If I click on a turnout, it switches. I would be able to see all of my trains run around on the schematic and know exactly where they are. Maybe GPS locators in each engine and caboose. Come on, I can look on the internet to pinpoint exactly what seat my kid is sitting in at the movie theater because he has a gps cell phone, why can't that technology be used in railroading.
Finally, I want one, just one, DCC guy to admit that accidents are more likely on a DCC layout over a DC layout. Even if its only.01% greater, admit that it is more likely. Because I have yet to hear someone with DCC say that.
Not picking on you as an individual; however, most of this thread is pure BS. You are assuming that block control is only used on DC. It can be used equally well on DCC if you want to. Block control is not related to DC or DCC. It is a means of controlling track power. The actual running of trains is determined by the operation of the DC power pak or the DCC throttle.
el-capitan wrote:Finally, I want one, just one, DCC guy to admit that accidents are more likely on a DCC layout over a DC layout. Even if its only.01% greater, admit that it is more likely. Because I have yet to hear someone with DCC say that.
Honestly, don't know. The only layout I've run both DC and DCC was mine and only ran one loco at time unless they were on separate loops while DCC. Had plenty of mishaps when both my son and I ran on DCC.
Chip
Building the Rock Ridge Railroad with the slowest construction crew west of the Pecos.
I kind of agree with you.
However, whatever technology comes down the pick next MUST be downwardly compatible with the current DCC systems as some many people already are running DCC systems.
The market place with decide which technology is best or most accepted.
Yes I was looking at the SPROG home page http://www.sprog-dcc.co.uk/ which has some step by step instructions for connectign the SPROG and don't mention needing to manually send the config information. It just says to download the Java runtimes from Sun, install JMRI, and plug in the SPROG.
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
"Since the latest SPROG documentation on the SPROG site no longer mentions having to do this one-time setup command, I'm wondering if it is still necessary"
Randy,
I'm looking at this:
http://jmri.sourceforge.net/hardware/SPROG.html
Are we looking at different docs?
Mike T.
Sigh!
At our club the club president likes to start his train running then get into conversations often going 30 minutes without looking at his train. The kids are speed demons and often rear end slower trains and derailed trains. Switches are often left set to sidings and spurs.
There's a lot of wrecks at our club.
Larry
Conductor.
Summerset Ry.
"Stay Alert, Don't get hurt Safety First!"
MTennent wrote:Randy, I like the look of the JMRI and the SPROG sounded promising until....I got to the set up part. A chart with values that you need to figure out a binary number to enter somewhere. Sigh. I know binary. I've use it in programming for computers. But it's the last thing in the world most model railroaders should have to deal with. Maybe this is what's holding this area of DCC back - the computer geek aura. I'm trying to figure out a comparison. It's almost like a TV manufacturer offering a TV that has a remote, but you have to program each channel into a specific memory location. And you have to it in binary. And, oh yeah, you have to buy another interface to use the remote and the software to do it is free but you have to download it from someone else and it's written in JAVA.Aaaarrgghhh!I think where I'm going with this is why should a DCC user have to go through all that? Why don't the makers offer it with the purchase? If I buy a router, printer, or other computer peripheral, I sure expect it to be plug n play with a CD and any needed software included. Why shouldn't DCC be that way?I think Chip is right when he says the first ones to wake up and put a USB interface on one and the software to go with it will start it all in motion.Mike T.
I like the look of the JMRI and the SPROG sounded promising until....
I got to the set up part. A chart with values that you need to figure out a binary number to enter somewhere. Sigh.
I know binary. I've use it in programming for computers. But it's the last thing in the world most model railroaders should have to deal with.
Maybe this is what's holding this area of DCC back - the computer geek aura. I'm trying to figure out a comparison. It's almost like a TV manufacturer offering a TV that has a remote, but you have to program each channel into a specific memory location. And you have to it in binary. And, oh yeah, you have to buy another interface to use the remote and the software to do it is free but you have to download it from someone else and it's written in JAVA.
Aaaarrgghhh!
I think where I'm going with this is why should a DCC user have to go through all that? Why don't the makers offer it with the purchase? If I buy a router, printer, or other computer peripheral, I sure expect it to be plug n play with a CD and any needed software included. Why shouldn't DCC be that way?
I think Chip is right when he says the first ones to wake up and put a USB interface on one and the software to go with it will start it all in motion.
Since the latest SPROG documentation on the SPROG site no longer mentions having to do this one-time setup command, I'm wondering if it is still necessary. The settings may have been integrated into JMRI so that it sends the proper command.
At any rate, there apparantly has been no clamor to resolve this potential 'issue' since Andy (the developer of the SPROG) or any number of people could write a simple config program that performs that function in plain English. Which is also why I wonder if they perhaps haven't integrated it in JMRI now.
el-capitan wrote:If the engineer fails to stop for whatever reason (inexperience with the rules, not knowing the town names, not paying attention) on my DC layout he will hit the block boundary at the end of the siding and the train will stop, probably causing a short circuit. If my layout where DCC his train would continue on through the siding, into a tunnel where a head-on collision could happen with the oncoming train. This is one of the con's to DCC in "my" book
Sounds Cool Art,
Keep us posted as to when that brochure comes online.
Space Mouse,
I got tired of waiting for a truly open system architecture (I guess that DCC manufacturers need to make money somehow), so I decided over 15 years ago on ZIMO. I do all of what you mentioned since then. My computer is running the layout. Now before everyone writes back that this is the death of model railroading because you want to be the engineer and not just stand on the side watching trains go by, read on.I can take control of one or more trains operated by the computer at any time by simply pressing a dedicated key on the throttle. No need to run to the PC first and let it know. It will continue to operate all other trains but the loco(s) that I aquired with this key will ignore all computer commands as long as the key remains active. Pressing the same key again hands the train back to the computer. This allows me to run my complete layout (48 trains) fully automatic (for visitors for example), run trains manually with the computer acting as an ETCS (collision avoidance, stopping trains automatically if I overrun a red signal) or run them in complete manual mode as mentioned above, crashing trains if that's what I want to do ;-)
ZIMO's "location dependent function control" turns functions on/off at specific sections on the layout automatically. This could be your lights, sounds (e.g. whistle) and so on. But you could also for example have a train enter your yard. After it comes to a full stop the locomotive automatically backs up a little to unload the couplers, uncouples the train and moves away from the train. This BTW is not a computer function but a ZIMO loco decoder function and works also without a PC by simply pressing the function key for the uncouple function.
For this year ZIMO is planning to introduce touch screen control, "ultra-mobile" PC technology based on the new Samsung Q1 with any number of virtual cabs, programming and control of functions without CV or function numbers. Bidirectional communication is being phased in rightnow.I'm just in the process of translating the 2007 ZIMO product flyer and it will be on our web sitesoon.
Regards,
ArtZIMO Agency of North Americawww.mrsonline.net
MTennent wrote:Randy,You missed part of my point - JMRI appears to work through each proprietary system and requires additional interfaces for each.I'm talking about a manufacturer independent, plug n play setup for any decoder equiped engine. It's own short programming track, USB interface, etc. Doesn't matter if you use Digitrax, Lentz, Atlas, MRC, etc.Take it home, load the software, plug it in and set everything. Not sure if its practical - just brain stormin'Mike T
You missed part of my point - JMRI appears to work through each proprietary system and requires additional interfaces for each.
I'm talking about a manufacturer independent, plug n play setup for any decoder equiped engine. It's own short programming track, USB interface, etc. Doesn't matter if you use Digitrax, Lentz, Atlas, MRC, etc.
Take it home, load the software, plug it in and set everything.
Not sure if its practical - just brain stormin'
Mike T
Well that would be the SPROG. Which uses JMRI as its controlling software. A standalone system independent programming device. OK so it doesn't come with a piece of track glued to it to be used as the program track - but if they did that they'd have to make a dozen variations to cover all the scale/gauge combinations. Also, there is an add-on bit for the Locobuffer-USB interface that will allow it to be a standalone programmer. And the Digitrax PR2 can be used with JMRI to program anything, not just the Digitrax sound decoders.
MTennent wrote:"interface ease counts for a lot, particularly with first-time users - and if you can make it easy, why not make it fun? "Since DCC is "equal" at the decoder level, that is, Cv 29 is CV 29, there's really no reason why someone couldn't come up with a self-contained programing system (track, computer interface and software) that you could just set everything on screen using common english. Brand independent.Point and click, pull down boxes for CVs and Functions, an interactive graphical interface to set speed curves, etc. Set an engine up and then move it to your layout and run it. Perhaps the economics is holding it back. As someone said earlier, DCC is really still a small market and recovering costs and making a profit is a consideration. But I think the first manufacturer to do it will capture a lot of users.Mike Tennent
"interface ease counts for a lot, particularly with first-time users - and if you can make it easy, why not make it fun? "
Since DCC is "equal" at the decoder level, that is, Cv 29 is CV 29, there's really no reason why someone couldn't come up with a self-contained programing system (track, computer interface and software) that you could just set everything on screen using common english. Brand independent.
Point and click, pull down boxes for CVs and Functions, an interactive graphical interface to set speed curves, etc. Set an engine up and then move it to your layout and run it.
Perhaps the economics is holding it back. As someone said earlier, DCC is really still a small market and recovering costs and making a profit is a consideration. But I think the first manufacturer to do it will capture a lot of users.
Mike Tennent
This already exists. And it's free. It's called DecoderPro and it's part of JMRI. http://jmri.sourceforge.net
Or if you prefer commercial software, RR&Company's TrainProgrammer does the same thing.
DCC vs DC? (forgetting the nitty gritty's') The basics:
DC (overall) is cheaper. DCC is more 'fun-ner'.
-----------------------------------------------------------------------------------
DC: (2 cabs - 2 men - 2 trains) Can you have more? sure - run in 'sections: Yard master; engine house; towns, CTC dispatcher panel;etc. How many guests do you need?
DCC: (Unlimited cabs @ 79 - $129 each) vs. All cabs can run entire layout. NOW, How many guests can you afford ?
DC ENGINES can run into another's control block ("who stole my train"?), DCC ENGINES can run into each other (crash) DC shorts on mialigned switches vs. DCC Derails (and shorts). Problem solution is Operator error.
I wonder whether the non-proprietary nature of DCC makes it harder to secure patents, and whether this might to some degree discourage innovation. Wasn't there some discussion awhile back about the DCS interface MTH is marketing? For some reason, I remember reading something about that being a bit more user-friendly.
Don't get me wrong - I love technical jargon. I'm just interested in railroad, electrical and construction jargon; all that CV stuff makes my eyes glaze over.
http://mprailway.blogspot.com
"The first transition era - wood to steel!"
I think you're onto something - interface ease counts for a lot, particularly with first-time users - and if you can make it easy, why not make it fun? Or prototypical? I can imagine all sorts of possible approaches - given that there are programs for desktop computers that can simulate a locomotive, why not a program that can take what we know about, say, the operating characteristics of a D&SL Mike, juggle them, take the known operating qualities of my Samhongsa Sunset D&SL 2-8-2, and make the model respond differently to various combinations of reversing lever, throttle, and airbrake application?
One of the interesting aspects of a mathematical model is its ability to produce results that reflect reality - even inadvertent or unexpected results. I had the impression when I read that DCC was producing cornfield meets on large layouts that we had taken a giant step in that direction. When DCC can inadvertently produce a runaway on my 2% grade, we'll know it has arrived.
"Troubleshooting is not the reason for blocks"
Jim,
I fully understood, I just wanted YOU to say it since you seemed to be making such a big deal about it being so advantageous. It's a very minor issue.
As I said earlier, I've never seen this argument against DCC. It sort of turns the whole wiring complexity thing on its head. More wires to come loose, more switches to malfunction, more things to go wrong - that's a GOOD thing.
It just struck me as a peculiar argument.