Digitrax consisting issue

[kiwi_bnsf]

I also gave up on Digitrax Command Station consisting long ago. It was unreliable, and so I too ended up opting for CV19 Advanced Consisting.

This ended up proving a good choice as I've subsequently become addicted to my ProtoThrottle, and this pretty much relies on Advanced Consisting.

I ended up going down a bit of a rabbit hole as I wanted my consists to respond appropriately to the ProtoThrottle's independent front and rear headlight controls, as well as the horn and bell to be only active on the lead locomotive.

I'm an ESU LokSound user and lighting and sound logic can be made conditional based on ESU's SoundCVs. I ended up programming custom ESU sound slots for horn, bell, and lighting that are "consist aware" based on the value of ESU's SoundCV16 (CV170) — which is spare in my sound projects.

The values of SoundCV16 dictate the response of the locomotive:

0      Loco is independent and all lighting and sounds respond (default)
1      Loco is consist leader (forward facing)
2      Loco is consist leader (rearward facing)

5         Loco is consist intermediate unit

10      Loco is consist trailer (forward facing)
11      Loco is consist trailer (rearward facing)


To reverse a consist, I just perform an ops mode write for the value of SoundCV16 (CV170) for the lead and trail unit, and all the sound and lighting adapts instantly. The front light control on the ProtoThrottle controls only the consist leader's lights (and only at the correct outward facing end). etc etc.

Even the process of setting CV170 can be made quite prototypical, as engineers typically have to call the dispatcher to change their lead locomotive number, and the dispatched updates the corresponding GTB number. I perform this same process via JMRI.

Breaking down and forming consists is pretty quick when performed via JMRI Decoder Pro. I just set CV19 and the direction in the consist, and then set the value of CV170.



TCS has done a similar (but less nerdy, and more generic) approach with their implementation of command station consisting in the CS-105 — where you can on the fly configure how a loco in a consist responds to sound and light commands https://docs.tcsdcc.com/wiki/CS-105#Consist_Settings Unfortunately the command station consists are not able to be manipulated easily on-the-fly with JMRI via LCC (only TCS throttles), and so I've not been able to take advantage of this implementation since switching to the CS-105.

[peteski]

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

A simpler, more intuitive DCC would ruin the fun for some modelers. 

Kidding of course.  But that is what we have - those DCC standards were developed decades ago, when JMRI (or LokProgrammer) did not exist.  The computing power of both the microcontrollers in decoders, and even those early home computers was merely a fraction what's available now. JMIR Decoder Pro is a well developed more-or-less user friendly front end that deals with the arcane DCC system.

Even Digitrax still has to cling to their arcane DCC design with Ops Switches and other weirdness.  They did put a nice user interface on the new throttles, but under the skin it is still the good ol' confusing Digitrax.

Unless the entire DCC standard is blown up and recreated new, we will have to put up with using modern front end to an antiquated standard.  Actually Decoder Pro seems to do a decent job with most things.

[jagged ben]

Gee, it seems like there should be a throttle app that takes care of all this for you and communicates with JMRI over wifi, and just sends all the appropriate commands to the locos without having to program them.   

[jdcolombo]

A simpler, more intuitive DCC would ruin the fun for some modelers. 

Kidding of course.  But that is what we have - those DCC standards were developed decades ago, when JMRI (or LokProgrammer) did not exist.  The computing power of both the microcontrollers in decoders, and even those early home computers was merely a fraction what's available now. JMIR Decoder Pro is a well developed more-or-less user friendly front end that deals with the arcane DCC system.

Even Digitrax still has to cling to their arcane DCC design with Ops Switches and other weirdness.  They did put a nice user interface on the new throttles, but under the skin it is still the good ol' confusing Digitrax.

Unless the entire DCC standard is blown up and recreated new, we will have to put up with using modern front end to an antiquated standard.  Actually Decoder Pro seems to do a decent job with most things.

Yeah, I get that we are stuck with standards created 35 years ago.  But it's the "modern front end" that I'm interested in.  Don't see why Digitrax or NCE can't design its command station to keep track of which engines are in consists (which they already do), have embedded logic for assigning things like lighting and sound to the lead engine, and some way to re-assign those things when the consist changes.  So instead of having the individual user program CV19, 21 and 22 (which is necessary with Digitrax; less so with NCE), either the command station would do that for you (NCE automatically assigns a consist address already), or (better, IMHO), the command station would be smart enough to "shut off" the relevant lighting and sound commands to all engines other than the lead engine in the consist.  This could be default behavior, programmable for those who just can't stand simplicity  .  No change in DCC standards; big-ish change in the operation of the interface between those standards and the command station/throttle.  It appears from the responses in this thread that some folks may already be working on this kind of solution.  May they succeed!

John C.

[Maletrain]

Especially in N scale, turning off the horn and bell in non-lead units is not always desirable.  I find that "triphonic sound" works best with my ABB lashup in noisy environments such as show and open house events. so that visitors can actually hear that N scale does make sounds.  At normal visitor viewing distances, it is hard to tell what unit(s) are emitting sound.  So, if all 3 are emitting the same sound at the same time, it is just louder.

[jdcolombo]

Especially in N scale, turning off the horn and bell in non-lead units is not always desirable.  I find that "triphonic sound" works best with my ABB lashup in noisy environments such as show and open house events. so that visitors can actually hear that N scale does make sounds.  At normal visitor viewing distances, it is hard to tell what unit(s) are emitting sound.  So, if all 3 are emitting the same sound at the same time, it is just louder.

Agree, which is why one should be able to override default behavior with special programming.  Digitrax already allows you to override almost all defaults in the command stations with op switches.  Don't know why you couldn't have a "consist logic on/off" op switch.  My main point is that right now, getting a consist to operate lighting and sounds prototypically requires a significant amount of end-user programming, and even with that, some things cannot be accomplished.   The "default" is essentially "everything lights up and everything makes noise".  I would propose that the default be "prototypical operation" (or as close as we can get) and then if you want to deviate from the default, have at it. 

John C.

[Dupesy]

So I've been messing around with this the past couple days.  Yesterday I hit the "loco reset" button, then rebuilt all of my consists using a UT6D.  As I built each one, I ran it back and forth to verify all engines in the consist responded appropriately.  Today I turn on the layout and hook up JMRI.  All the consists look good except one, the "top" loco is by itself, and the two that should be consisted to it show in a consist, with address 2 as the top engine.  When I'm done with a throttle I change the address to the number I've assigned the throttle, in this case it was throttle No. 2.  I'm wondering if by not dispatching the top engine first then selecting a new address is somehow messing with the consist.

[Maletrain]

Dupesy, On the UT6D throttles, you can "release" or "dispatch".  Which are you doing?  Release is preferred.  It is simply [Loco] followed by [X].  Dispatching with the UT6D requires going into the menu.

[Dupesy]

I was dispatching them this time around.  Previously I usually just selected another loco.

[Maletrain]

Dupesy, your observation may provide a key others, including myself, have been searching for.

Digitrax "dispatching" was initially developed to let an experienced user with one throttle turn over control of a loco address to an inexperienced user with a less-capable "utility" throttle. 

So, the Digitrax command station does some things with addresses in the "slots" when you dispatch.  It also does some things when you "steal" an address that is already in a slot associated with another throttle.  And now the DCS240s do more things with slots, to work around the earlier throttles not being able to address slot numbers above 120 by moving addresses ftom above 120 to below 120 when a non-capable throttle tries to acquire an address in a slot number above 120.  I am getting the impression that the programming to accommodate all of that is not working as intended.

But, Digitrax has a "proprietary" system, so nobody who talks to us users is allowed to tell us how the programming really works.  We can only test and see what happens.

So it would be really helpful if you can figure out how to do some process that will demonstrate the fault and be repeatable.  And, then, see if there is a different, work-around process that can repeatably be successful in avoiding the problem.

So, can you try to do whatever sequence of events you did last time that resulted in the trailing locos of the consist being reassigned to the top address "2"?  If you can do that repeatedly, then see if the result is different if you "release" the consist top address instead of "dispatching" it, using the rest of the process the same way.

[Dupesy]

well, I'm back at it, and found a couple of my consists had done it again.  When I powered up and connected jmri, a couple consists had the top loco removed and were in consist 1.  I had JMRI running at shutdown and everything looked fine.  Instead of using the "loco reset" button on the CS, I reset opsw 39, and am now rebuilding a couple of them again. I'm noticing that after a while (10-15 min) of no use, the top engines no longer show as the "top" in slot monitor, but the others still show consisted to it, and the consist works.  I'm not savvy enough with this to know if that's normal or not.

**edit**  I've built 4 consists, 2 that I dispatched, 2 that I used "X" when complete.  I shut off the CS and upon powering up found the top engines that had moved as mentioned above again showed as the top loco and the consists are intact.

[Maletrain]

It is not normal for the "top" designation to disappear on the JMRI LocoNet Slot Monitor.  My consists with a DCS100 last for months, with shutdowns at least once per week.

You could try cicking on "force refresh" to see if they come back into view there.  Let us know.

Also, I am not understanding your meaning about "consist 1".  Do you mean "slot 1" or are you numbering your consists, somehow?  I also don't understand how the tops for 2 (separate?) consists both ended up in "consist 1". 

It would help if you told us the actual address numbers, which slot numbers those addresses are in, and which slots are labeled "top" and which slots are labeled as consisted to which "top" slot.

Tell us that for both how they appeared when you set them up, and how they appeared after the changed.  It would also be important to know what else happened between those 2 conditions.  You  seem to say that it might be just a matter of time, so that would probably be the best thing to check, first.

[Dupesy]

so for instance I had engines 1016, 1717 and 1728 consisted, top loco being 1717.  Upon powering up this morning, the 1717 was not consisted, and the other two still were, with the top address for them being address 1.  Another consist, with locos 1948-3182-1910-1925, had 1948 as the top loco.  This morning, the 1948 was not part of the consist, the other three still were consisted, to address 3 (i think it was).  What I noticed this morning, after resetting opsw39, is that after I built a consist and dispatched it, the top loco would, after a short time, change slot numbers and no longer show as the top, but the whole consist responded correctly.  The consists I built then "loco"-"x" did not do this.  I did shut down the layout for about 5 hrs and just came back to it, the consists I built this morning are functioning as intended.

Also, I did check the throttle firmware via digilPLI last night; I updated my 602D, but bricked 2 of my 4 UT6Ds.  They seem to be stuck in update mode (flashing buttons, blank screen) and will not function at all.  I will have to send them to Digitrash Digitrax.

[Maletrain]

It would help if you told us the slot numbers as well as the addresses.  When you say the tops went to "address 1" and "address 3", do you really mean they went to slots 1 and 3, with the same addresses (1717 and 1948) in those low slots as in the original slots? 

The DCS240 may be moving the slot of the top loco address from a slot above 120 to a slot below 120 without changing the actual address.  The Loco Monitor shows the slot that the other slots are consisted to, so you need to look at that top slot's content to see the actual top address.  If that is what is happening, then it is probably correct behavior, and would explain why the consists still work at that point.

But, there are 2 remaining questions:

1.  Why did the command station move the top consist addresses to those low slots?  Was the top address originally in a slot number higher than 120?  Did you try to acquire those consists with a throttle that is not enabled for the slots above 120?  Check your throttles to make sure that they are set to be able to address the higher slot numbers.  For instance, see https://www.digitrax.com/tsd/KB1068/ut6-throttle-options-settings/ , which indicates that the UT6D throttles come with the default setting to not be able to access the high slots. Similarly, see https://www.digitrax.com/tsd/KB1067/dt602-throttle-options-list/ , which also shows ID10 as "off" by default for the DT602D throttles, so they aren't enabled for the high slots by default, either.  So, to enable these throttles for the high slots, you need to go into their menus and change their ID10 settings if you have not done that already.  Strangely, the manuals don't mention any of that, directly - they just have pointers to the links I provided above.

2.  Anyway, in addition to the consist top addresses being moved to different slots, you say those consists eventually stopped working, which is an additional issue.  So, we need to understand what happens after the slot changes occur. So, for instance, when the top address moves from its original slot to a different slot, what happens with the original slot.  Does the top address also stay in the original slot, but just lose the "top" designation for that slot, or does the original slot get cleared of its address, or does some other address appear there.  And, if some other address does appear there, then what is that new address?

I am beginning to get the thought that the problem here is that the throttles making the consists are not enabled for slot numbers above 120, but are still somehow making consists that are in slots above 120, anyway.  Then when the not-enabled throttle requests to acquire the top address, the command station moves that address to a lower slot to allow the acquisition.  But, somewhere along the line, perhaps after a shutdown or a timed inactive address "purge" (see DCS240 Op Switch settings) the connection between the top address slot(s?) and the consist gets "lost".

So, lots of stuff to check to figure this out - which is why most people do not bother to pursue the issue this far - so the issue has persisted for quite a while.

Also, regarding your "bricked" UT6Ds, it is common for the Digitrax updating program to fail to complete an update and leave the update item "bricked".  The Digitrax solution for that is to keep trying until it works.  (Yes, that is also the definition of insanity, but it does often eventually work - after as many as 7 tries in quick succession.)  It does help to make sure that the LocoNet is absolutely "quiet" on the command station doing the updating.  The usual recommendation is to disconnect the command station from the layout LocoNet and plug the item to be updated directly into the LocoNet jack on the command station before updating.  Worth a try before paying for "Florida vacations" for your UT6Ds.  (I would also disconnect the track feeds from the command station, in case there is some sort of Railcom signal from somewhere on the layout.)

[John]

On the off chance, is there a battery in the command station.  Maybe replace that if it’s been in there for a while