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?
greg - Philadelphia & Reading / Reading
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.
gregcwondering how many Digitrax users are aware of this feature and what kinds of experiences they and other users have had that many be related?
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.
https://dccwiki.com/Slots
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.
Good Luck, Ed
gmpullmanhttps://dccwiki.com/Slots
gmpullmanLater 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.
"Pay no attention to that man behind the curtain"
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
gregc gmpullman https://dccwiki.com/Slots helpful, thanks gmpullman 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. yes, i've become familiar with several JMRI screens "Pay no attention to that man behind the curtain" 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
gmpullman https://dccwiki.com/Slots
helpful, thanks
gmpullman 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.
yes, i've become familiar with several JMRI screens
rrebellNCE just has other problems.
gregchaven't seen any when operating on various layouts
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.
Both Digitrax and NCE have their pros and cons.
jmbraddockFor instance, it is possible for two NCE PH Pro Cabs to have the same throttle enabled.
which raises a question of how throttles are ID'd on LocoNet?
gregcwhich raises a question of how throttles are ID'd on LocoNet?
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.
The Loconet architecture is a peer-to-peer CSMA/CD network. I can only surmise that this was their choice when they were first developing their DCC system plan.
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 pass up the deal.
The original Super Chief command station I bought used in 2005 is still working fine on my test track. I'm sure better systems are out there but for the time being, I'm not shopping for any.
Regards, Ed
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.
Simon
Some of the systems flush the slots on their own over time like the DCS51.
snjroy The only annoyance is when all the slots are FULL.
gregcapparently "STEAL" only results in absolute (by a single throttle) control of a loco if/when the loco on another throttle has been properly "dispatched"
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".
gregc still trying to understand the Digitrax philosophy and why it seems NCE doesn't have the same problems
gregc rrebell NCE just has other problems. haven't seen any when operating on various layouts
rrebell
NCE just has other problems.
haven't seen any when operating on various layouts
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 stand-alone LocoNet (Gasp!), or more recently, LCC. Yet another con.
Let's talk about firmware updates, too. With NCE, to get a bugfix you have to wait until they package it with a "feature upgrade", then buy and install a new chip. Digitrax, on the other hand, is designing their new products (not just command stations) with the ability to do firmware updates via download which they supply. Another con for NCE.
So again, yes, NCE has problems. As jmbraddock pointed out, they all have their pros and cons. Depends on your point of view, and what you're accustomed to.
gregc snjroy The only annoyance is when all the slots are FULL. do you "dispatch" a loco when you stop using it which i think makes the slot available for another loco?
do you "dispatch" a loco when you stop using it which i think makes the slot available for another loco?
No.
Dispatching the loco (Loco->Disp) leaves the loco in the slot, but makes the slot available for another throttle.
Releasing the loco (Loco->Exit) frees the slot.
MrMeAnd whether anything is a pro or a con really depends on your point of view, as well as what you're accustomed to.
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?
MrMeWith 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.
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
MrMeThat limited ID capacity is why NCE users with larger layouts have to resort to an additional bus system, such as C/MRI, a stand-alone LocoNet (Gasp!), or more recently, LCC. Yet another con.
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.
MrMeDispatching the loco (Loco->Disp) leaves the loco in the slot, but makes the slot available for another throttle. Releasing the loco (Loco->Exit) frees the slot.
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 to control the loco, shared or not. I believe neglecting to properly dispatch a loco is the cause of confusion on the club layout
Yes, I dispatch the locos.
gregcpretty 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)
Unless set by the user, Digitrax throttles do not have unique IDs.
gregcthe limited # of NCE cabbus IDs used for throttles does not limit the # of stationary decoders for controlling accessories
It does limit the number of inputs, however, such as turnout state and block occupancy.
gregc MrMe And whether anything is a pro or a con really depends on your point of view, as well as what you're accustomed to. the Digitrax "SLOTMAX" problem at the club prevented members from running their trains. i doubt anyone would consider that a "pro".
MrMe
And whether anything is a pro or a con really depends on your point of view, as well as what you're accustomed to.
It isn’t. But if you properly release (not just dispatch) locos when you’re done running them, you won’t ever have to worry about it.
gregc 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?
I didn’t design the system, so I don’t have an answer for that. But if you ask AJ, I’m sure he can tell you what his line of thought was.
gregc MrMe 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. 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
You can assign a different ID to each throttle, but it’s not necessary, and no, it’s not used to tie a throttle to a slot.
All my throttles still have their default throttle ID’s (eg, 527F for my DT500’s). I’ve never assigned unique ID’s simply because there’s no need for me to do so.
gregc MrMe That limited ID capacity is why NCE users with larger layouts have to resort to an additional bus system, such as C/MRI, a stand-alone LocoNet (Gasp!), or more recently, LCC. Yet another con. 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.
But it DOES limit the number of AIU’s you can have to report back on occupancy, switch position, etc.
On the other hand, you can have a virtually unlimited number of devices on the LocoNet, most of which report their own status (My DS64’s, BXP88’s, and BXPA1’s all do). Many also have external inputs that can be used to generate sensor messages on the LocoNet.
gregc MrMe Dispatching the loco (Loco->Disp) leaves the loco in the slot, but makes the slot available for another throttle. Releasing the loco (Loco->Exit) frees the slot. 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 to control the loco, shared or not. I believe neglecting to properly dispatch a loco is the cause of confusion on the club layout
Nope, you have that wrong. It DOES matter, because “dispatching” and “releasing” each result in a different status of the slot, with different operational implications.
“Dispatching” (Loco→Disp) keeps the contents of the slot (mobile address, speed, direction, etc) intact, and marks the slot as available to be acquired by another (or even the same) throttle to control that same mobile address.
On the other hand, “Releasing” (Loco→Exit) marks the slot as no longer holding valid information, and makes the slot available to be over-written with new information (ie, a different mobile address, etc).
Neglecting to properly RELEASE a loco is the cause of the Slot Max condition.
MrMeOn the other hand, “Releasing” (Loco→Exit) marks the slot as no longer holding valid information, and makes the slot available to be over-written with new information (ie, a different mobile address, etc).
gregc MrMe On the other hand, “Releasing” (Loco→Exit) marks the slot as no longer holding valid information, and makes the slot available to be over-written with new information (ie, a different mobile address, etc).
MrMe On the other hand, “Releasing” (Loco→Exit) marks the slot as no longer holding valid information, and makes the slot available to be over-written with new information (ie, a different mobile address, etc).
Hmm, forum seems hosed today and won't let me quote, using either FF or Edge. Oh well, here's the best I can do:
<quote>
we played with this while looking at the JMRI slot-monitor and saw no difference. both Loco->Dispatch and Loco->Exit changed the status of the slot from in-use to idle
</quote>
I'm not a JMRI developer, either, so I can't speak to what JMRI may or may not show in it's displays.
But I have an experiment for you to try:
Continue to "Dispatch" locos instead of "Releasing" them, until you get "Slot=Max" when trying to select a new loco. *See note below.
Then, instead of an OPSW36 or 39 to clear everything, just re-select one of the previous locos and "Release" it.
Then try again to select the loco that gave you "Slot=Max". I'll bet you'll be able to, because your "Release" of that other loco freed a slot.
*Note: If you're using a DCS100, you can speed this part up setting OPSW44 to T, to set it back to 22 slots.
And when looking that up, to be sure I had the correct OPSW, I found the answer to your previous question about "Why 22 slots?". It states right in the manual that it's for backwards compatibility with the Big Boy system, which preceeded the Super Chief (DCS100). I'm sure that made a lot of sense back in 1996 when the Super Chief was introduced. And since the DCS100 hasn't had (or needed!) a firmware update since the NMRA standards went from 8 functions to 12, that default has never been changed.