i’m learning about Digitax features on a club layout and I, along with some club members who hav ebeen using Digitrax for over a decade are surprised to learn about Digitrax’s slot following feature.
slot following is a training feature that allows 2 controllers to control the same loco. apparently “STEAL” only results in absolute (by a single throttle) control of a loco if/when the loco on another throttle has been properly “dispatched”.
as you can imagine, inadvertent use of the feature can result in some mysterious behavior
wondering how many Digitrax users are aware of this feature and what kinds of experiences they and other users have had that many be related?
Yea, it is a pain. Learned about it when a loco kept changing speeds that had worked right before. I played with it a bit and had two throttles, one at one end of the main loop and one at the other, both set at different speeds and as the loco got closer to one or the other, the speed would change.
My Digitrax experiences go back to April, 2005 when a friend was in the unfortunate position of having to liquidate his model RR things. So, while I was “on the fence” about choosing and installing a DCC system this friend made me an offer I could not refuse.
Early on I learned about the “slots” and how they fit into the Loconet framework. With the early throttles you couldn’t easily determine that you had reached your “slot=max” situation but an occasional reset (option sw. 36) of the command station cleaned up the situation. That “slot following” thing never made sense to me and as far as I recall, I’ve never used it. It is an anachronism of the early Loconet days.
Some early throttles could only handle two-digit addresses. Selecting a four digit address on another throttle then “stealing” that address on the other throttle was a way around this limitation.
Later when JMRI came along with its excellent brace of Loconet tools including “Monitor Loconet” and “Show Slots” functions it became very easy to “release” addresses and keep an eye on what the command station was doing in relation to the Loconet network.
Now the latest iteration (6xx) of the DT throttles makes it even easier to keep tabs on address dispatching. If your club does not use JMRI Decoder Pro I would encourage them to do so.
i’ve been working with a previous member of the club who wired and configured it, who said he would monitor JMRI and correct improperly entered addtesses or dispatched locos.
still trying to understand the Digitrax philosophy and why it seems NCE doesn’t have the same problems
It’s just that NCE users aren’t as vocal. No DCC system is perfect as they all involve some sort of compromise. For instance, it is possible for two NCE PH Pro Cabs to have the same throttle enabled.
In the end, people have the systems they like and defend. That’s true whether it is Digitrax or NCE or Windows and MacOS.
When I first setup the Digitrax system I bought in 2005 I chose a “Loconet ID” number at random. Default is 00, I chose 15.
I don’t have any neighbors using Digitrax so there are no conflicts. If I did, I could choose another Loconet ID.
Devices and throttles recognize the Loconet ID automatically when first plugged in to the Loconet network. The throttle ID number is then randomly assigned (but can be overridden if there is a conflict).
I presently have ten Digitrax throttles. I have never made a concious effort to assign any ID numbers to them, I let Loconet and the command station do this for me.
I have four of the recent DT-602 and UT-6 throttles. Each one has been [physically] plugged into the Loconet network exactly once. I use them wirelessly since.
I did plug them in to the command station, which is also connected to my home network via USB in order to upgrade the firmware using the downloadable Digitrax application (Digi IPL) and it worked very well for me.
From my standpoint, I’m still using some of the original devices I installed in 2005 and some 18 years later I can upgrade to the latest throttles and network devices including Wi-Fi throttles (Engine Driver on Android devices) plus interface with JMRI and make many option changes through JMRI/USB/Loconet.
Again, I DID NOT exactly choose Digitrax but it was a system that a friend was selling cheap and I didn’t pas
I have a Digitrax Zephyr system that I bought in 2006. Have added a throttle and a Wifi system to it since then. Works great. The only annoyance is when all the slots are FULL. I’ve had problems resetting (flushing?) the system these last few years using the sw. 36 command. Lately, I’ve been doing the operation a bit more slowly, giving the system more time to clear the memory (before exiting the command). It seems to work.
Actually, historically “STEAL” would never give you absolute control (I say "historically because some of the newest systems when using extended slots will force the other throttle to release), if the throttle prompts you to steal, then the loco is currently assigned to another throttle. My biggest complaint with it is the use of the word “steal”, it would have been more descriptive of what is actually happening if they had used “share”.
That’s easy: It’s because the basic design philosophies of the two systems are quite different. Think in terms of a gasoline-powered car and an EV - Like DCC, the end results are the same (you get from point A to point B), but the pros and cons of each propulsion system are quite different. And whether anything is a pro or a con really depends on your point of view, as well as what you’re accustomed to.
See my above comments about what makes something a pro or a con. To play the devil’s advocate:
With NCE, each throttle needs to be assigned a unique address. To a Digitrax user that doesn’t need or use throttle ID’s, that’s a con.
And there is one ID range for tethered throttles, one range for radio throttles, and one range for AIU’s. Again, to a Digitrax user that doesn’t need or use throttle ID’s, that’s a con. But wait, what!!?? AIU’s need throttle ID’s?? They aren’t throttles! Yup, another con.
That means that there is a limited number of devices you can put on an NCE control bus. Since it’s a polled bus, too many devices and the command station would never get back around to polling device #1. Another con.
That limited ID capacity is why NCE users with larger layouts have to resort to an additional bus system, such as C/MRI, a stan
the Digitrax “SLOTMAX” problem at the club prevented members from running their trains. i doubt anyone would consider that a “pro”.
as an engineer, concepts that puzzled me made sense when someone more completely explained the problem being solved.
don’t understand why OpSw 44 which expands the # of slots to 120 isn’t the default. why would you want to limit the # of locos controlled by the command station?
pretty sure Digitrax has IDs for each throttle to identify which loco/slot a command (e.g. speed, light) is for. (don’t know of any communication protocol that doesn’t have addresses)
assigning unique throttle IDs doesn’t sound like a show stopper, any more than assigning unique decoder addresses is
the limited # of NCE cabbus IDs used for throttles does not limit the # of stationary decoders for controlling accessories. yes Loconet is a “built in” alternative that doesn’t use DCC for accessories.
whether it deletes the slot entry or simply marks it as availale (Idle) doesn’t matter. “Dispatching” a loco indicates the throttle no longer wants