Developer website: JMRI Community
JMRI: DecoderPro is an essential utility for model railroad enthusiasts.
Modern DCC decoders are complicated beasts to program. The simple idea of "put the address in CV01" doesn't cope well when you program complicated functions using combinations of bit patterns. A friendlier interface is needed. There are programs that provide better ways of programming specific decoders. Unfortunately, they are limited to specific types of computers, and only their authors can customize them for new types of decoders.
The DecoderPro symbolic programmer is meant to improve this. It is configured using text files, so that it can be adapted to additional decoder types easily. It talks to the decoders using the JMRI programming interface, so that it can run on any computer and layout hardware that JMRI has been ported to. It's freely available for download. And since the code is available via open source, if you want to improve on it you can.
Required Migration Step
- JMRI was updated in JMRI 4.7.4 to use a new serial library. Depending on your exact circumstances, you may need to do some migrations:
- If you are using JMRI on Linux or Mac OS X and are updating from an older JMRI version, you must open the JMRI preferences and make sure that the selections are correct for your serial device(s). Be sure to save the changes. In general, previous versions used serial device names like "/dev/cu.usbserial-ABC123FG". This version will generally omit the prefix, and use serial device names like "cu.usbserial-ABC123FG". (If given the choice if a name starting with "tty" and one starting with "cu", pick the "cu" one). See the before and after images to the right.
- If you are using Linux and have previously used the "JMRI_SERIAL_PORTS" option to make sure your serial device is visible to JMRI, you'll have to change that to use the "purejavacomm.portnamepattern" option instead. See the JMRI Linux install page for more information.
- If you have your own JMRI scripts to access a serial device, you'll have to update their library references:
- Any import gnu.io statements will have to be replaced by import purejavacomm statements.
- More generally, any reference to gnu.io (e.g.m a reference to a class like gnu.io.SerialPort) statements will have to be replaced by a reference to the corresponding purejavacomm class.
- This version of JMRI (and all later) writes a slightly streamlined version of panel file contents. Older files should still be readable by this version of JMRI, but files written by this version may not be readable by versions before JMRI 4.2 depending on their contents.
- Since JMRI 4.7.5 The LocoNetOverTCP server has changes that may break scripts that reference it. Scripts refering to the class jmri.jmrix.loconet.loconetovertcp.Server need to refer instead to jmri.jmrix.loconet.loconetovertcp.LnTcpServer.
- Since JMRI 4.7.3 This release will not start cleanly if installed over earlier versions of JMRI (the Windows installer ensures this is not an issue). Remove the JAR files jackson-annotations-2.0.6.jar, jackson-core-2.0.6.jar, and jackson-databind-2.0.6.jar from the lib directory within the previous installation directory to resolve this.
- Since JMRI 4.7.1 JMRI no longer supports the portable paths resource: or file: that were deprecated in JMRI 2.13. When loading a panel, an error message will be displayed if the panel contains a path that starts with resource: and the panel will not load until changed using an external editor. Paths starting with file: cannot be automatically flagged because JMRI allows file: URLs.
- Since JMRI 4.7.1 The LocoNet Server (the LocoNetRMI service; not the LocoNetOverTcp service) in this version of JMRI doesn't properly interoperate with JMRI 4.7.1 through JMRI 4.7.4. It does work fine with JMRI version 4.6 or before. If you encounter a problem with version compatibility, you'll see an error message that includes "local class incompatible". The workaround is to update both client and server JMRI machines to the same JMRI version.
- Since JMRI 4.7.1 JMRI applications will not load a panel file that fails XML validation; an error will be shown that should explains the error, allowing it to be fixed using an editor. (The explanations remain a work in progress.) The usual cause of something like this is (imperfect) manual editing of the file, but it can happen for multiple reasons. If you encounter this, either ask for help fixing the file on the JMRIusers list; use a copy of JMRI 4.6 to load and rewrite the file into the proper format; or set your preferences to execute the "TurnOffXmlValidation.py" script before JMRI loads your panel file.