Support - DCC Programming Track

From Train Control Systems Documentation
Revision as of 19:55, 2 August 2021 by TCSDanM (talk | contribs) (redlink fix)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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.

    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!

Mainline Programming

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.