Digitrax consisting issue

[Dupesy]

I'm having a random issue with engines dropping out of a consist.  If I dial up the "top" loco it will respond, but none of the other engines in the consist will.  If it try to select one of them they will show as being in a consist but will not respond until I break up the consist and rebuild it.  This happens at random, when initially selecting the consist.  It does not seem to happen while running.  I started noticing it when I was running a DCS-100 and DB220 booster, I've upgraded to a DCS-240+ with the DB220 and the issue still pops up occasionally.  All throttles are Digitrax, either a DT602D or UT6D.  I generally only have 1 or 2 throttles on at a time, and I'm the only one using them.  There's roughly 40 locos total on the layout.  Nearly all trains are kept in staging and the power to each track is switched; they do not all get powered up when the command station is turned on.

[John]

Try to look at the consists with jmri and see whats going on when it happens ..

[GaryHinshaw]

I've had this happen to me too and I couldn't identify a cause, so I just gave up on Universal Consisting (where the command station does all the work).  I've now switched to Advanced Consisting where I set CV19 in each consisted loco.  This is a little more cumbersome to set up, but it is very stable, and you can program lighting functions per unit in the consist.  However, it's less convenient if you want to frequently change your consists.

There is a nice guide to consisting here.

[jdcolombo]

How often do you break up consists?

If you rarely (or ever) break up consists, my solution to consisting is pretty simple: I set each engine to the same DCC address as the "lead" engine.  This pretty much ends any weird de-consisting behavior.

But it does require a bit of innovative programming, depending on how you use your consists.  Most of this deals with lighting, but if you use sound units, you'll need to do some of this, too.

First, let's deal with lighting, and let's use a 3-unit consist as the example, with the first two units facing forward and the rear unit facing backward.  In operation, you'll want to be able to have the lead unit headlight on when the consist is moving forward or in reverse with a train attached, but you'll want to be able to turn on the rear unit's headlight if the consist is running light in reverse or if you "turn" the consist to make the rear unit the lead unit (e.g., you do a run-around move on a train).  To accomplish this, I de-couple the lighting from F0.  I'll program the lead unit's headlight with F4 and the rear unit's headlight with F5. When the consist is running forward or in reverse with a train, F4 turns on the front unit's headlight.  When running light in reverse, or if you "turn" the consist so that the rear unit is now in the lead, I turn off F4 and turn on F5.  Now the rear headlight is on.  And you'll want to turn the lighting functions off for the middle unit.  You're never going to use those.

What about sound?  Same story, sort of.  You want F8 to turn on the prime mover on all sound units, so that you can leave alone.  But what about the horn and bell?  When running forward, you want the usual F1 for the bell and F2 for the horn.  But I turn these off on the rear unit, and assign F6 and F7 to the rear unit's bell and horn.  In normal operation, you'll use F1 and F2 when the consist is running forward either light or with a train, and same if running in reverse with a train.  But if running light in reverse, or if you "turn" the consist, you can use F6 and F7 to have the bell and horn sounds coming from the rear unit.

I've found that both Universal Consisting and Advanced consisting poorly implement lighting and sound for prototypical operation.  NCE's consisting system is much better, but still not what I want.  So I roll my own.  But this system really only works because I never break up consists.  I've had the same 3-unit or 2-unit consists (all with ESU LokSound decoders) running on my layout for 10 years.

John C.

[Maletrain]

My club is having that broken consist problem with the HO layout and it is driving them nuts.  It seems to have started with the change from a DCS100 to a DCS240, and continued with a DCS240+.  And, there has been much discussion of the same problem by others on the Digitrax groups.io list.

One of the posters on the groups.io list said that his problem was solved for them by updating the firmware in all of the throttle and their command station.  Not sure if that has remained true.  Digitrax has always insisted you need to update firmware when there is a problem, but has NOT said that any updates they have made were actually intended to address this consisting problem.

There are all sorts of theories, but few people are doing the necessary research to truly understand the problem, and Digitrax has not been helpful.

I am not involved with the HO problems, partly because I am the coordinator for the N scale DCC layout, which uses a DCS100 and does not seem to have the same problem, and perhaps also because the HO group is not happy with my suggested solution to their problem.

So, I am going to second the suggestion to use JMRI to see what REALLY is in the slots when a consist/MU that was working is suddenly not working.  (That usually seems to change with a shut-down followed by a power-up, and the duration of the time turned off doesn't seem to matter.)

I have had the same observation (on the HO layout) that a consist where the other locos do not respond to the lead address still show as being in a consist.   Others on the groups.io list have said that the problem is that those unresponsive locos have been somehow reassigned to a different consist.  But, I have not been able to independently verify that is happening on our HO layout.  So, it would be useful to employ the JMRI "slot monitor" to see exactly what address it says the non-responsive non-lead units now are consisted with.  And, also see what the addresses are that those new lead(s/) had previously been consisted with, and whether those other locos ended up in other consists.  That would tell us if the consists are really getting mixed up, or if some are just becoming unresponsive for some other reason(s).

The DCS 240 has 400 "slots" for addresses, but the slots above 120 cannot be addressed by the older Digitrax throttles.  So, the DCS240 command stations have firmware the "moves" the lead loco in a consist to one of the lower slots if that address is in a slot above 120 when it is acquired by a throttle that cannot access slots above 120.  That is ASSUMED to be at least PART of the problem with consists getting mangled.  Operators do see that the non-lead locos in the consist they are trying to use are not moving, but they probably have no idea if there are other locos somewhere else on the layout that are trying to move, or even moving, because their addresses are now consisted with the lead address the operators have acquired.

Our HO group has now outlawed all non-Digitrax throttles and all Digitrax throttles except for DT602s, UT6s and any DT402s specifically modified to address slots above 120, but that has not solved the problem.  (No WiFi throttles allowed - the LNWIs and UR91s and 92s have been removed from the layout.)

Nobody has told me that the HO  group has actually PROPERLY tested that all throttles still allowed have the latest firmware,  so I can't say that does not solve the problem.  So, it would be nice to know if all of the throttles Dupesy is using have the latest firmware, now that you are having the same problem with a much more controlled environment.

Our HO group has now gotten into trying to eliminate "sloppy" use of the Digitrax throttles it still allows.  There is some thinking that improper consisting technique still results in consists being made by a throttle, but that those consists are not "stable" when the command station is shut down and then repowered.  Not clear to me how that can even happen.  But, with the Digitrax PROPRIETARY processes allowing addresses to be "stolen" and "purged", as well as "released" and "dispatched", it is sort of plausible to think up a lot of things, especially if it is assumed that there are some bugs in the firmware for the throttles and/or the command stations.

Gary's experience with his solution using "Advanced Consisting" may add some knowledge.  That uses decoder CVs to carry the consist information, allowing the command station to send out single commands to the consist address in CV19 (of all locos in a particular consist) instead of sending individual commands to all of the loco addresses in the consist.  So, in theory, the command station should be using just one address and could not mangle the consist.  But I have never used a Digitrax command station to make an "Advanced Consist" (but do make them with NCE and by direct CV programming.)  So, I do not really know what the Digitarx command station does with address for the lead loco.  Is it the actual "consist address" in the CV19s, or is there an "alias" long address in the command station that is the lead loco address?

If the command station just tells the operator to use the consist address, that can be ONLY "SHORT" ADDRESS NUMBERS BETWEEN 1 and 127.  But, if the command station provides the lead loco road number (long address) as an "alias", it seems to me that MIGHT then allow some sort of mangling of the consist, because it still requires an association between 2 addresses. (Digitrax used to have an "alias" function to allow long address numbers to send commands to short addresses - but I don't know if they use that for Advanced consists without documenting it.)  On the other hand, , if an operator needs to put a "phantom" loco with a long address into a regular Digitrax "Universal Consist" with the "advanced Consist" so that you can control the advanced consist with the lead loco road number, I think that also probably opens up the process to getting unresponsive mangled consists again.  So, Gary, since you are using Digitrax "Advanced Consists", would you please describe how it works for us?

There are some really good minds in TRW, so I have some hope that we can get some useful findings here.

[GaryHinshaw]

^Right, I should have added that I now use a short address as a consist address when using Advanced Consisting.  My scheme is to make the first and last digit of the lead unit as the short address, e.g., lead unit 4933 gets short address 43 in CV19, then all other units in the consist get 43 in CV19.  The command station then sends throttle commands to one address, 43, rather than every (long) address in the consist.  This cuts down on Loconet traffic.  Of course this short address scheme fails if you have another lead unit like 4743, but I have not run into that limitation yet.

In the JMRI Consisting tab, you have the option to set decoder functions for each unit in the consist separately.  For example, if you have sound and you only want the lead unit to sound a horn, you set the lead unit to respond to the consist address for the horn function, and set the remaining consisted units to respond to their individual long addresses for the horn function.  Then, if your throttle is set to the short address of the consist, only the lead unit will sound a horn.  You would have to dial your throttle to the long address of a trailing unit to sound its horn.  (But why would you want to do that?)

[jdcolombo]

  Then, if your throttle is set to the short address of the consist, only the lead unit will sound a horn.  You would have to dial your throttle to the long address of a trailing unit to sound its horn.  (But why would you want to do that?)

How about this scenario: you are picking up (or dropping off) cars from an industry (or to an interchange yard, or whatever) that requires the consist to do a run-around move to the back of the train.  When you do the run-around. the last engine in the consist becomes the lead engine.  So you would want it to be blowing the horn, sounding the bell, and have its front headlight on when doing this runaround move (and any subsequent train moves where the former trailing engine is now the lead engine).  Is this POSSIBLE with advanced consisting using a Digitrax command station?  Yes, it is possible, if you properly set CV's 21 and 22 AND don't mind dialing up the trailing unit's address when wanting to blow the horn or sound the bell.  And you'll have to switch back to the consist address to control speed while you're doing this, although if you have a Digitrax throttle that has two speed knobs, you set one of the knobs to run the consist address and dial up the trailing unit on the other.  But why deal with that when there is, IMHO, a simpler way.  Set all the units to the same DCC address.  Program the function keys in each engine as I indicated above.  Now you have individual control of the lighting and sounds from the front and rear units AND you can use the actual lead locomotive address, instead of a made-up 2-digit address that your operators are sure to forget one minute after the op session begins, to control speed.

What is really needed is a new form of command-station-assisted consisting, where you can specifically designate the lead and trailing units, and the command station will automatically do what I do manually.  E.g., when you separate the consist from the train to do a run-around move, you press some function key (let's call it the "consist switch key") to tell the command station that the trailing unit is now the lead unit.  The command station automatically shifts lighting and sound commands to the trailing unit until you dis-engage the consist switch key.  This kind of programming actually might already be doable with LokSound/LokPilot decoders; I'm not sure, but the programming language for ESU's decoders is sophisticated enough, with If/Then and other logic, that it might be possible.

John C,

[Maletrain]

Jdcolombo, that "new form of command-station-assisted consisting" you are asking for sounds very much like the NCE consisting method, which uses the CV19s plus some info in the command station so that you can use the lead and rear loco addresses (but not internal loco addresses).

Or, you can set CVs for how various functions behave in a consist, forward and backward separately.

It just takes some work to make it all come out prototypically. 

[Dupesy]

my plan is to break up consists relatively frequently.  Maletrain's comment about other engines being randomly assigned to a consist reminded me I have had that happen at least twice.  His additional comment about improper consist building technique may be part of the equation; I know I frequently "mash buttons" to build a consist before I smarten up and follow the book.  I doubt all of my throttles are updated with the latest firmware, or the command station for that matter.  I have a friend that lives nearby who understands the info JRMI spits out far better than I do, I'll get him over and see what JMRI says.  I'm wondering if I should clear out all the current consists and start fresh.

[jdcolombo]

Jdcolombo, that "new form of command-station-assisted consisting" you are asking for sounds very much like the NCE consisting method, which uses the CV19s plus some info in the command station so that you can use the lead and rear loco addresses (but not internal loco addresses).

Or, you can set CVs for how various functions behave in a consist, forward and backward separately.

It just takes some work to make it all come out prototypically.

Yes, NCE's way of handling consists comes closest to what I think we need.  But even it is a bit cumbersome, because you have to set CV's 21 and 22 correctly to get it to work how you want.  I want a command station that can recognize the difference between lead, trailing and interior engines without any physical intervention other than maybe a single "consist reverse" button.  My "smart" command station would know that interior engines do not have their lights on, do not sound their bell or horn ever, but do have all the prime mover sounds (including, if you use them, dynamic brakes, wheel squeal, etc.).  It should be able to automatically shift lighting and horn/bell sounds to the trailing engine without any fancy programming for CV's 21 & 22 (again, perhaps with the press of a single "consist reverse" button).  It would do this by keeping track of the order in which engines are added to the consist.  First engine selected is the lead; if there is only one other, it is the trailing unit.  If there are more than 2, then the last unit added is the trailing unit.  And if you break up a consist, it would automatically re-assign function keys as needed.  Take out the trailing engine of a 4-unit consist?  Then the command station knows the 3d unit is now the trailing unit.  All this has to be doable with today's technology.  Aren't we in the middle of an AI takeover???

John C.

[Maletrain]

Be VERY carful what you wish for in the way of introducing "AI" to model railroad operations.   

Remember how much "fun" you have dealing with the automated telephone answering "services" when you need to get something straightened out that has not been going "according to plan".   

[jdcolombo]

@Maletrain

Only kidding about AI!

I think that everything I'd want done regarding consisting is doable with simple (-ish) If/Then, And/Or logic.  In fact, as noted earlier, NCE is about halfway (or maybe a bit more than halfway) there  In fact, it MAY be possible to do all this now by custom programming ESU decoders.  But I don't want to HAVE to custom program much of anything.  I don't want to have to futz around with obscure CV's (19, 21, 22) and bit tables to do what I want.  And most decoders out there do not have the level of programming customization that ESU does (Zimo may be the only other regularly sold in the U.S.).  Better to have this done inside the command station.  In a world where a Raspberry Pi 4 with 1GB of ram costs $35, I've got to believe this is all possible without being overly costly.  But I'm not a computer programmer (and my older son, who IS a software engineer for Microsoft, sadly is not a model railroader and cares not one whit about consisting logic!).

John C.

[peteski]

CV19, 21, and 22 ire NMRA defined standard, not some obscure bit-tables CVs.  All brands of decoders capable of advanced consisting should have those CVs.

[Sumner]

@.... Better to have this done inside the command station.  .....John C.

The DCC-EX team, the way I understand it, is working on the command station being involved in some way with consisting but I haven't followed it enough to know exactly where they are with it.  They release pre-release versions as they are working on new command station options.  One can experiment/try out the pre-leases  themselves before the next 'approved version' is up.  It only takes a few minutes to update to the latest release or a pre-release version with the auto-installer.

For anyone interested in interacting with the design team you are always welcome on their Discord channel

https://discord.com/invite/PuPnNMp8Qf


Sumner

[jdcolombo]

CV19, 21, and 22 ire NMRA defined standard, not some obscure bit-tables CVs.  All brands of decoders capable of advanced consisting should have those CVs.

Just because they are defined in the NMRA standard does not make them user-friendly.  Or not obscure.  I'll bet that 90% or more of people who use DCC have never heard of CV 19, let alone CV's 21 and 22.  And properly programming CV's 21 and 22 does in fact require that you know what bits you want to set and what decimal value that translates to in order to do the programming.  Yes, there are web sites with handy tables to help with this, but it is far from user-friendly.  JMRI makes this much simpler, but it requires an attached computer running the JMRI software which presents its own set of complexities. 

Given where we are in technology development, there is no reason it has to be this hard for the end user.

John C.