Release Notes for JMRI 4.9.7 release
Date: December 8, 2017
From: Bob Jacobsen
Subject: Test Release 4.9.7 of JMRI/DecoderPro is available for download.
This is a test release. Please post a note if you encounter any new or old bugs! And please back up your JMRI files before installing this, in case you want to go back to an earlier version.
This is the next in a series of test releases. We expect this series to end in the next JMRI production release around the end of 2017. (See the tentative release schedule)
Some of the changes involved are quite extensive. They may require a certain amount of experience before they are working well. Therefore, this test release should be considered experimental.
Required Migration StepSince JMRI 4.7.4JMRI 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:
import gnu.iostatements will have to be replaced by
- More generally, any reference to
gnu.io, e.g. a reference to a class like
gnu.io.SerialPort, statements will have to be replaced by a reference to the corresponding
Known problems with this release
New warnings for this release:
Older warningsSee the JMRI 4.8 release note for more warnings predating the 4.9 development series. These may be relevant to you if you're updating from an earlier version.
Since JMRI 4.9.4 Due to changes in the capitalization of some method and property names, some scripts may fail until adjusted to use the new capitalization. The Javadocs for any JMRI class will list the correct capitalization.
Since JMRI 4.9.4 For Windows users only: JMRI 4.9.3 (and all later) has a new version of the "LaunchJMRI.exe" program. It's used to set options as JMRI is starting up, and is a completely normal part of JMRI. Because it's new and different, however, your anti-virus program may reject it. You might get a message about "file removed" or "file quarantined" or similar and then JMRI might not start. The solution is to make sure that your anti-virus program doesn't interfere with JMRI's installation and running. There are so many of those, unfortunately, that we can't really provide useful instructions beyond that.
Since JMRI 4.9.2 JMRI saves the Uhlenbrock connection's "baud" rate as an Internationalized string, and, upon loading a configuration profile, requires an Internationalized "baud" rate in the .XML file. JMRI will fail to properly configure the serial port if the "baud" rate from the configuration profile does not match one of the baud rate strings for the current Internationalization "locale". If you experience problems where JMRI start-up of a Uhlenbrock-based connection does not configure the serial port, it may be necessary to edit the connection's preferences, select the appropriate "baud" rate, save the connection. This updates the configuration profile XML file to use one of the "baud" rate strings expected by the Uhlenbrock-specific code in JMRI. It is necessary to re-start JMRI for this change to take effect.
Since JMRI 4.7.6 If you're having trouble getting your DCC programmer to work, try checking that the "Defaults" under "Preferences" are set to your hardware system. The reason: This version of JMRI (and all later) provides more options for "default systems": If you have multiple sets of hardware attached, which should be used for throttles, for programming, etc. JMRI tries to guess the right settings for these when you upgrade to this version, but apparently it sometimes gets that wrong (we haven't been able to track that down yet). Setting them manually fixes any wrong guesses.
Since JMRI 4.7.5 JMRI 4.7.5 (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
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
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
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.) If you have a problem loading a panel file, please
- Configure your JMRI startup to first run the jython/TurnOffXmlValidation.py script which will suppress the error.
- Write out a new version of the panel file (after saving a backup!)
- Use that new version from now on.
- And drop use of the jython/TurnOffXmlValidation.py script.
Since JMRI 4.5.6 As part of fixing the TMCC throttle issue, the handling of TMCC preferences was changed. If you have a TMCC connection configured, please go to the "Defaults" pane in the Preferences window and make sure that the TMCC connection is selected for the appropriate device types.
Since JMRI 4.5.2 This and future releases of JMRI may not function on OS X if the Java SE 6 provided by Apple is installed. OS X operating system updates routinely remove this version of Java SE 6. Please raise any issues concerning this on the user's group. To remove Java SE 6 from OS X, follow these steps (these steps assume JMRI is installed in the folder /Applications/JMRI, if not, adjust the following paths as needed):
- Open Terminal.app.
El Capitan only: Reboot into Recovery Mode by restarting your Mac and pressing Cmd-R until the Apple logo appears. Once in Recovery Mode, select Terminal from the Utilities menu.
- Run the command
/Applications/JMRI/PanelPro.app/Contents/Resources/uninstall-java6.shIt can take up to a half hour to complete. Wait for the message Removed Apple Java SE6.
El Capitan only: Run the command
bash /Volumes/Macintosh\ HD/Applications/JMRI/PanelPro.app/Contents/Resources/uninstall-java6.sh /Volumes/Macintosh\ HDIt can take up to a half hour to complete. Wait for the message Removed Apple Java SE6.
- El Capitan only: Restart your Mac.
Since JMRI 4.5.2 Support for directly executing AppleScript within JMRI has been removed due to changes in macOS and Java outside our control. If you require the ability to use AppleScript, you may be able to add this capability on your own by visiting JMRI AppleScript Support, but please be aware that this may not work on upcoming releases of macOS or Java.
Since JMRI 4.5.1 Internal turnouts and sensors need to have complete, individual system names. The names "IT" and "IS" (without any suffix) are no longer permitted: "IT12" is fine, but just "IT" is not. Most panel files that contain these should automatically migrate them to new names when saved, but in some cases you might need to manually update them.
Download links:Please note that the download links in this and future JMRI releases link to Github servers. If that doesn't work for you, the files are also still available from the SourceForge.net servers. Please let us know of any problems.
- OS X / macOS: https://github.com/JMRI/JMRI/releases/download/v4.9.7/JMRI.4.9.7.R72446d4.dmg
- Windows: https://github.com/JMRI/JMRI/releases/download/v4.9.7/JMRI.4.9.7.R72446d4.exe
- Linux: https://github.com/JMRI/JMRI/releases/download/v4.9.7/JMRI.4.9.7.R72446d4.tgz
Changes since Test release 4.9.6:The list of included commits is available from our GitHub code repository.
DecoderProDave Heap made the following changes:
- Added "altsignal" as another possible "Address Type" in Accessory Decoder Ops Mode.
- Added "Delay" as a new optional parameter in Accessory Decoder Ops Mode.
- Added a new Ops Mode Delayed Programming mode to throttle the Program on Main rate for those decoders that need it. You will need to configure your definition to enable this, as per this link.
- JMRI now supports Roster-based programming of BDL16/BDL162/BDL168, DS64,
PM4/PM42, and SE8C devices. This makes programming of these devices very
much like programming a mobile decoder! Some limitations apply:
Some device features are not accessible via Roster entries, including DS64 output addresses, DS64 routes, and SE8C "alternate" addressing (i.e. SE8C address programming via OpSw17). These configurable features will not be saved, restored, or modified when using a Roster entry.
Each device type has limitations on which Board ID (or Board Address) values may be used.
The "old" tools, in the LocoNet menu item, are still in-place. Those tools provide access to some aspects of device configuration which the Roster-based mechiansm does not.
New / Updated decoder definitions
- Support for the new Light-It and Illuminator multipurpose mobile/accessory/signal decoders. (Dave Heap)
- Dick Bronson updated the MotorMan definition
- Alain Le Marchand added the K7D4 for Kato N-Scale ACS-64
- Corrected the Aspect used when "Lit" is unchecked from Aspect 8 to the Aspect specified by the "Dark" appearance. (Dave Heap)
- Petr Šídlo updated the Czech translation