Function controls
Quote:
I also find the throttle-based consisting in the TCS throttles to be likely the least friendly of all (and we have yet to see how TCS's command station consisting will work in actual practice, so to declare it the winner is premature). Consider - a consist that's tied to a throttle will be extremely confusing for most modelers when they get the train later but don't happen to pick the same throttle. Why wont it move? Now which throttle had the consist again? On my layout with 10 throttles, I would make throttle-based consisting off-limits. Too dang confusing.
So I think it is fair enough to say that we should wait and see with TCS's CS105, as I don't currently have one, and I have not heard directly from anyone who does about how the consisting works (I don't know if there are NDAs involved right now, since it is still pre-production). It certainly sounds very promising if they implement it as they have described, and with the same ease of use of in-throttle consisting on the UWT-100.
The challenge is that most people using DCC seem to have no clue how consisting works to begin with, so yes, it could be more confusing to do in-throttle consisting. However, while TCS seems to have coined or at least popularized the term "in-throttle consisting" with the UWT-100, the basic functionality has existed in WiThrottle and Engine Driver for the past 11 years, so tons of people do it on the regular basis, and probably don't even really understand what they are doing or how it works. From what I've seen, people using throttle apps tend to be more casual modelers, the railfan types, or people running on club layouts, not doing serious operations (I'm sure there are counterexamples), so they may not have as much of a problem.
Confusion about being tied to the a throttle is sort of similar to the confusion caused by NCE's CV19 consisting when a consist doesn't get cleared from the decoders for one reason or another. There are also some pretty cool advanced use cases for in-throttle consisting like DPU and trailing units on locals, where you can consist consists together.
Quote:
My opinion comes from 20 years of operating on a large home layout with DCC consists. I'd like to hear AlexW's actual experience with these various systems and why he feels almost 180 degrees different than me. I'm not saying he's wrong, I'm just trying to understand the tradeoffs he has because they're clearly very different from mine.
So most of the layouts that I operate on use NCE, I have Digitrax, and I have operated quite a bit on a layout with ESU. I have also used Lenz, although that layout is all steam, so no consists. My major observation on NCE layouts is that most of the time, the CV21/22 are set totally wrong, and the lighting and functions are all kinds of FUBAR. Yes, for the advanced user, you can do some unique things with NCE-style consists, but for most users, they can't or can't be bothered to even get them to work correctly.
As long as you don't use brakes, and are OK breaking and re-making the consist at the end of a turn, Digitrax's consisting is really fast and easy, and usually results in proper function controls. If you want anything more, you're SOL. The other issue that I have not seen personally, but have heard of many times is the CV19 issue, where people either don't know or forget to clear CV19 from locomotives consisted on NCE, and then wonder why the locomotive makes sounds, but can't move.
I'm not particularly a fan of either Digitrax nor NCE at this point, but I've been particularly critical of most of the architecture of the NCE system. While their consisting method is uniquely powerful, it should NOT be the default, as the rather complex consisting and function controls are rather contradictory to the their whole marketing shtick of being easier to use, which compared to Digitrax was true.... 15 years ago. Their consisting is, however, a selling point for advanced users who want the double-ended consisting and function controls, and configure CV21/22 properly for such use on their layout.
It seems to me that the consisting systems of Digitrax, NCE, CVP, Lenz, and MRC are stuck in the computational limitations of mid-1990s technology, or retaining direct compatibility with such technology, while the more modern European systems that have far more processing and memory capability just don't care because they don't do a lot of MU operations in Europe, so it's a relatively unimportant feature.
If TCS implements their consisting system well, as the first modern North American DCC system, they have the opportunity to finally do consisting right, with the simplicity of doing it all in the command station and not needing CV 21/22 programming or having issues with CV19, but at the same time offering the ability to swap cabs and have granular function control for sound and braking features.
I really don't know why Digitrax hasn't made their consists double-ended at least, that would be fairly easy, adding granular function control might be a bit more complex, and not doable on the DT500 and lower series throttles, but surely a DCS240 and DT602 have the ability to handle such functionality.
However, consisting is just one part of the functionality of a DCC system. The proprietary radio systems are various levels of lousy, the system throttles leave a LOT to be desired in most cases. Digitrax has unfortunately abandoned potentiometers, NCE actually had a good design in the ProCab, but hasn't updated it in 25 years, so TCS did that for them in the UWT-100. NCE's polling lag is much worse and more noticeable with sound decoders, and the ease of use benefits that they got from their polled bus design with dumb terminal throttles in 1995 are long since obsolete. I like my UT4Rs, but otherwise, the Digitrax, Lenz, and NCE system throttles leave a lot to be desired, as do the proprietary radio systems.
What I've found recently is that the DCC system matters a lot less than before, as with JMRI handling the throttles and programming, the interaction with the system itself is minimal to nonexistent. However, with good JMRI integration, and good consisting, TCS could reverse this notion, and return some utility to the DCC system beyond being a proverbial (or sometimes literal) black box that converts commands from JMRI into DCC packets.
