This help page is presented as a set of "questions and answers". It is hoped that this presentation will answer the basic questions related to LocoNet "Enhanced" slots.
LocoNet implements the "slot" as the basic mechanism for:
This discussion focuses on the first two of these items, and ignores the last item.
Locomotive control and locomotive consisting slots are those slots which may contain valid locomotive information. Valid locomotive information includes the slot's status, a DCC mobile decoder address, the decoder's current speed and direction, some stored information on which functions are active, the type of DCC packet to be sent to the DCC mobile decoder, the "Throttle ID" reported by the last throttle to acquire the slot, and position in a consist (if consisted).
When a LocoNet throttle acquires a locomotive address, it effectively asks the command station for a slot number with which to control a locomotive address. Once acquired, the throttle uses that slot number reported by the command station.
Some guess that limited available memory in the microcontroller devices used in early Digitrax command stations forced a limit of the available number of slots and amount of information in each slot.
Some guess that LocoNet designers worried about available data throughput on LocoNet if locomotive control messages required more bytes.
While both of these arguments are logical, only the architects of LocoNet can really know. But it is known that the "traditional" slot architecture placed a practical limit of up to 120 addressable locos (whether separately controlled or consisted using "basic" consisting). The "enhanced" slot architecture has extended that capability to be greater than 120 in cases where the command station supports more than 120 locomotive-control slots.
Upon its introduction, the primary DCS240 selling point seen by users on the Digitrax-Users "Yahoo" list (now the Digitrax-Users "groups.io" list) was the ability to use up to 400 throttles and control up to 400 locomotives. This association was well-established before the release of the DCS210 and DCS52 command stations.
Why is this significant? Because neither the DCS210 nor the DCS52 could control more locomotives than a "standard-slot-only" command station, nor could they support any more throttles than such a command station. But both command stations use and understand the LocoNet messages which makes it possible for the DCS240 to support as many as 400 throttles and as many as 400 uniquely controllable locos.
This emphasized that the so-called "expanded" slot is more than simply a mechanism which allows a LocoNet-based system to use more than 120 throttles, and allow the system to control more than 120 unique locomotives. Instead, it is an "ecosystem" which allows different LocoNet messaging for loco control, different throttle "steal" behavior, different command station memory of function states, etc.
So, for the purposes of this discussion, an "enhanced" slot is one which uses newer LocoNet messaging to implement the additional features listed in the previous paragraph, regardless of the slot number value. So-called "enhanced" slot LocoNet messaging may use slot numbering in the "traditional" slot numbering range, as is done by the DCS210 and DCS52 command stations, or by the DCS240 if it is configured to limit its slots to a maximum of 120. That same "enhanced" slot LocoNet messaging may use slot numbers in the "expanded" slot numbering range to control those locomotives which are held in a DCS240 in a slot number which is above the "traditional" slot numbering range.
| Traditional slots: | Enhanced slots: |
| use locomotive control slot numbers between 1 and 120 (or less, depending on command station), using a 4-byte message; | use locomotive control slot numbers between 1 and 400 (or less, depending on command station), using 6-byte messages; |
| remember only F0 thru F8 | remember F0 thru F28 |
| can be "shared" between multiple throttles; | can be "stolen" by another throttle and the first enhanced-slot throttle no longer has control of the slot ("StealZap"); |
| can be controlled by "traditional-slot" throttles or by "enhanced-slot-capable" throttles; | can be controlled only by "enhanced-slot-capable" throttles; |
| can be managed by all Digitrax command stations. | can only be managed by newer Digitrax command station models. |
All LocoNet-compatible command stations implement traditional slots.
It is believed that a "LocoNet 2.0" specification defines the "enhanced" slot functionality. As of this writing, the Digitrax DCS52, DCS210, and DCS240 command stations implement "enhanced" slot functionality.
It is believed that all LocoNet-compatible throttles can make use of traditional slots to control locomotives and/or consists.
As of this writing, the Digitrax DT402-series and DT500-series throttles can make use of "enhanced" slots. It is believed that the throttle must be configured to allow it to request and use "enhanced" slots - if not configured to use "enhanced" slots, or if the command station does not support "enhanced" slots, the throttle will make use of "traditional" slots.
It is believed that those WiFi throttles managed by the Digitrax LNWI device can make use of "enhanced" slots, assuming that the command station supports "enhanced" slots.
It's hard to support "enhanced" slots for a variety of reasons. Primarily, "enhanced" slots add a large number of "boundary conditions" that are difficult to manage. And different Digitrax command stations seem to behave differently when "enhanced" slots are used and certain "boundary conditions" are exercised. Until these boundary conditions are fully understood, it has been deemed inappropriate to provide enhanced slot support in JMRI. This means that JMRI will not, at this time, control locomotives or consists using "enhanced" slot LocoNet messaging.
A few JMRI developers have reverse-engineered the apparent behavior of some aspects of "enhanced" slot functionality. As of this writing, that has been limited primarily to the "LocoNet Monitor" feature. It has been thought that any improper behavior of the "LocoNet Monitor" functionality at "boundary conditions" would only give an incorrect display in the LocoNet Monitor window but cannot cause JMRI to misbehave.
As of this writing, other places where JMRI makes use of "enhanced" slots is limited to usage where configuration and operations are done via "enhanced" slot messaging. Any improper behavior due to "boundary condition" cases for these implementations is thought to not affect the ability of JMRI to control trains.
There are a few things at play here. At a minimum, JMRI will require: