Support - DCC Programming Track
- 1 Command Station Cannot Read CV's
- 1.1 Problem 1: Trying to program a sound decoder on a low-power program track without a booster.
- 1.2 Problem 2: The motor is not connected to the decoder.
- 1.3 Problem 3: Locomotive is not on the programming track. (No, this is not a joke)
- 1.4 Problem 4: The programming track is not physically connected to the programming track outputs from the command station.
- 1.5 Problem 5: Decoder lock is active.
- 2 Using JMRI Decoder Pro
- 3 Mainline Programming
Command Station Cannot Read CV's
Question: My command station says it cannot read, or has failed to write, the CV's in my TCS decoder. Why?
There are a few reasons why your command station may not be able to read CV values. Here are the top problems:
Problem 1: Trying to program a sound decoder on a low-power program track without a booster.
Some systems on the market do not supply enough power for enough time on the programming track to allow for a programming operation to successfully take place. This is an issue especially for sound decoders or decoders with Keep Alive® which require more "juice" to program. This will result in erratic and periodic results of success or failure when reading or writing CV's on the programming track. The system may report errors such as "No Decoder," "No Ack," "No D," "No CV," etc. This issue can be solved in most cases with a programming Booster. In our experience, the PTB-100 from Soundtraxx is a reliable option when used with our decoders and Keep Alive® devices.
Problem 2: The motor is not connected to the decoder.
In order to communicate with the command station, a DCC decoder needs to generate a spike of current. This is done by pulsing the motor. If no motor is connected to the decoder, the decoder has no means by which it can "acknowledge" that a programming command has completed. Similarly, the decoder cannot communicate a CV value when requested that it be read. Therefore, it is important to make sure your motor connections are made and that they are free of short or open circuits. Shorts across the motor at this point can damage your decoder's motor outputs making them permanently unresponsive or run away! Open circuits will result in a similar lack of acknowledgement, and will also display an error on your system, but will not damage a decoder. For instructions on how to check your motor connections, visit the Multimeter Troubleshooting Guide on our website.
Excerpt from S-9.2.3, Section D of the NMRA Standards and Recommended Practices:
"Service Mode operations provide for an acknowledgment mechanism from the decoder to the command station/programmer. Acknowledgment refers to the ability of the Digital Decoder to respond to a Service Mode instruction issued by a Programmer. Service Mode instructions can be executed regardless of whether or not the acknowledgment mechanism is detected by the command station/programmer."
What does this mean? What this means, is that a command station or dedicated decoder programmer will always send programming commands, regardless of whether or not a decoder provides an acknowledgement. On the flip side, this also means that a decoder will also always accept and ac upon any programming instruction(s) received, regardless of its ability to provide an effective acknowledgment. Suffice to say, if you know your decoder is powered, receives a valid programming command, it will always accept that command (unless Decoder Lock is active).
If a decoder is not physically capable of providing an acknowledgement to the programmer/command station that it has completed a programming instruction successfully, your programmer/command station will most likely display an error message to you that the instruction failed. This error message can be false if the decoder successfully processed the command but was unable to provide an acknowledgement. If the decoder is not physically capable of providing an acknowledgement, and is being asked to read out the value of a CV, the programmer/command station will always produce an error message, as there is no possible way for the decoder to communicate with the command station.
Problem 3: Locomotive is not on the programming track. (No, this is not a joke)
Without using a two-way communications method such as RailCom it is not possible to read CV values on your DCC mainline track. Writing CV's is possible, but not reading. This is because the command station and decoder do not have a method by which to communicate CV information on the main. Only command stations and decoders which support RailCom can communicate data on the main. If you are attempting to read CV values, place your model on the programming track first.
Problem 4: The programming track is not physically connected to the programming track outputs from the command station.
On some DCC systems, your main track and programming track might be combined; however, most systems use a second set of connections for dedicated programming tracks. If you have not connected your programming track to these outputs, or if there is a loose/broken connection, your programming track will not function. If you use an isolation switch to swap between mainline and programming for the same section of track, ensure the switch is in the correct position. If Problem 1 also applies to you, ensure that your booster is connected properly, powered, and functioning properly.
Problem 5: Decoder lock is active.
Decoder Lock is a NMRA standard which allows for a decoder programming to be "locked" and therefore disallowed. When a decoder is locked, all CV values other than CV 15 and CV 16 will report "Cannot Read CV" or similar. More information on Decoder Lock can be found in the NMRA CV Standards or on their respective pages on this wiki:
Using JMRI Decoder Pro
Question: I use JMRI for my decoder programming. Does all of the above information still apply for programming tracks?
Yes! JMRI Decoder Pro relies on your command station to do all the heavy lifting of reading and writing CV's. All of the issues and advice above still applies even if you use JMRI to program your decoders.
However, it is also important to keep in mind that JMRI is constantly evolving, and is a program developed by volunteers. As decoder manufacturers such as TCS continue to release new Decoder Types, Versions, and features, those options will be added to the JMRI as "decoder definitions" over time. As such, it is imperative that you keep your Decoder Pro and JMRI software up to date with the current release. The latest bug fixes and decoder definitions can make the difference between quick success and endless frustration when programming a decoder.
JMRI Cannot Identify Decoder Type/Model
Question: Why can't Decoder Pro identify my decoder?
Reason 1 - Technical/Electrical Issue
See the above points about CV read-back and troubleshooting steps. Often the solution is a simple electrical or mechanical one, and no fault of the decoder. If you are having connectivity issues with your command station, visit the JMRI Helpdesk for support, or post a question on the JMRI User Forum
Reason 2 - Decoder Definition Missing
If your version of Decoder Pro does not have the specific decoder or decoder version available in its list of definitions, the program will not be able to successfully identify your installed decoder. Make sure that your JMRI version is up to date with the latest available. You can download the latest version from JMRI's Website
Decoder definitions are created through volunteerism, and as such not all products and decoder variants have definitions created. If you are technically savvy, you can even create your own decoder definition! For more information on decoder definitions for JMRI, Click Here!
Programming "on the main" is complicated for a few reasons. The first complication is that CV number 1 may never be programmed on a mainline in OPS mode - This is a DCC standard set by the NMRA. Therefore, if you plan to program a short address, you MUST use a programming track. If you want to program a long address into a decoder using your mainline, see above. An important consideration about Mainline Programming is that it is 100% reliant on the address of the locomotive/decoder to perform programming. Here are the problems with that:
- Having multiple decoder on the same address
- Having multiple decoders in the same engine (See Decoder Lock)
- Not knowing what the address is/Accidentally scrambled the address
- Selecting the wrong address and instead programming a different decoder by mistake
When setting addresses, TCS recommends only using a programming track and never re-configuring the address on the main.
The only benefit of mainline programming is the speed at which programming operations can be performed. It is not necessary to wait for confirmation or read-back on each operation. Unfortunately, the trade-off is that without the technology such as RailCom it is not possible to perform mainline program read operations. Mainline programming is only recommended for on-the-fly changes that need to be performed in real time or if you are experienced with CV programming.