Release Notes for JMRI 4.7.3 release
Date: April 17, 2017
From: Bob Jacobsen
Subject: Test Release 4.7.3 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 middle 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.
Known problems with this release
- Under some conditions, in this release SE8c Signal Heads will "loop", sending an unending stream of Turnout messages. This most commonly hit LocoNet systems, but as SE8c boards can be used with any DCC system, it's a general problem. This is fixed in JMRI 4.7.4
New warnings for this release:
- 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 installation directory to resolve this.
Older warningsSee the JMRI 4.6 release note for warnings predating the 4.6 development series. These may be relevant to you if you're updating from an earlier version.
(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) 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.)
(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 JRMI 4.6 or before. The workaround is to update both client and server JMRI machines to the same JMRI version. We expect this will be fixed in JMRI 4.7.5.
(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.
(Since JMRI 4.3.3) You can now set the order of your startup items: If you're opening panel files, running scripts, etc as the program starts up, there's a preferences pane that lets you easily set the order in which those happen. If you've set the order manually (e.g. by editing configuration files) in the past, please check this preference to make sure it's set the way you want.
(Since JMRI 4.1.2) Jython has been upgraded to version 2.7.0 with the following potentially breaking changes:
- The decodeJmriFilename() function is no longer available by default. Use the FileUtil.getExternalFilename() method instead.
- The simple propertyListener object is no longer available by default. Create your own, following the examples provided in the jython folder in the JMRI distribution.
- jmri_defaults.py included in the JMRI distribution is no longer executed by default, but will be executed before any other Jython scipts if included in your User Files location.
- The default behavior of python.cachedir.skip is now true. If using a custom python.properties file, include "python.cachedir.skip=false" in that file.
- Certain Python scripts are too large to be evaluated in Jython. If a script fails with the
java.io.IOException: Mark invaliderror, set "jython.exec=true" in a custom python.properties file or rewrite the script to be less than 100,000 characters per file. Note that when using "jython.exec=true" it may be desirable to run the included script jmri_bindings.py as a startup action to emulate the evaluation environment used when jython.exec=false.
(Since JMRI 4.1.1) Decoder definitions that use the "ivariable" form are now deprecated. Definitions included with this release have been converted to the new form. If you have decoder definitions with the older "ivariable" form, they will no longer validate, but can still be used for the first couple of test releases in this series. Please ask on the JMRI users Yahoo group for help converting them, or just drop them and use the current definitions.
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.7.3/JMRI.4.7.3.R202c9ee.dmg
- Windows: https://github.com/JMRI/JMRI/releases/download/v4.7.3/JMRI.4.7.3.R202c9ee.exe
- Linux: https://github.com/JMRI/JMRI/releases/download/v4.7.3/JMRI.4.7.3.R202c9ee.tgz
Changes since production release 4.7.2:The list of included commits is available from our GitHub code repository.
DecoderPro now has two additional options for how it handles CV reads and writes. These are set via the Programmer section of the Roster preferences panel.
- "Allow caching when writing index CVs for read or write
operations": Some decoders require that specific values
be written to "index" CVs before certain other locations can be
read or written. QSI and ESU decoders use this extensively.
When doing a lot of reads or writes, for example an entire
decoder, the index CVs can end up being written with the
same value many times in a row. When selected, this
option allows DecoderPro to skip (save time on) writes
of the same index value that are otherwise redundant.
Don't use this (or use it only in combination with the
following operation) if you have reliability problems
writing decoders, as proper operation of this option depends on reliable writes.
More detail: A single bad write with this option off trashes one CV; writing a bad index with this option off trashes the CV that was supposed to be written and the wrong one addressed by the bad write, but the write to the next CV in the sequence is OK due to the redundant next write of the index; writing a bad index with this option on leaves that badly-written index value in place, so writes a sequence of bad CV values. Bottom line: If working with a complicated decoder with lots of CVs, you need a reliable programming connection, see next option.
- "When possible, confirm CV writes by following this with a read":
When selected, DecoderPro will read each CV after writing it.
If the value doesn't match, it marks the write as failed.
If you're having intermittent trouble writing to a decoder, this may improve reliability. If DecoderPro is never able to properly write, this won't help; it only helps if the problem is occasional, and retrying will get it right more often than not.
Some DCC systems will check for a "write acknowledge pulse" from the decoder before declaring the write a success. Those are almost as reliable as this, and much faster. So if you're using one of those DCC systems, this might not be needed. On the other hand, if you're using a DCC system that "writes blind", with no check, this might be really useful. To tell if you have one of those, try writing CVs with the locomotive off the track. If DecoderPro thinks the write succeeded, then the DCC system is writing blindly, without checking.
This doesn't help (but doesn't hurt) if you can't read back the decoder. Most DCC systems can't read during ops mode programming, for example. Some command stations (Digitrax DB150) can't read from the decoder. In those cases, this option just asks the command station to write without reading back.
Programming capability facades are little tools that are used to handle things like indexed CVs, special ways to write upper-address CVs not supported by a command station, etc. Previously, these would have trouble recovering when they encountered multiple errors. (This came up in the context of the time that the DCS240 command station takes to do writes, which JMRI thought was an error) This has now been greatly improved.
- Much work on the reliability of the C/MRI support, fixing bugs in both setting preferences and normal running.
- Having multiple C/MRI connections should now basically work, although there may still be some issues when starting up C/MRI tools from the Preferences, e.g. opening the C/MRI Monitor automatically at startup. Work on all this is proceeding.
- The Digitrax DCS240 command station sometimes takes a long time to write CVs It's thought that this is happening because it's doing a read-after-write to ensure the right value was stored in the right place. In any case, it takes so long that JMRI was timing out and and retrying while waiting for it to complete. This has now been improved. It's still slow, excruciatingly slow if writing indexed CVs, but the timing is properly handled.
- The DS64 configuration tool now has the ability to configure the addresses for the turnout outputs, and to configure the DS64 "routes".
New / Updated decoder definitions
programming capability facade
for handling indexed CVs has been improved to reduce the number of times that
it has to write values to the "PI" and "SI" index CVs. Some decoders require that e.g.
you write a value to CV31, then another value to CV32, then finally access the specific
CV you're looking for. This can take a long time, especially when using a command station
that writes slowly (see comment about DCS240 above)
The indexed CV support has been updated so that it can skip writes when the previous
operation was to an indexed CV with the exact same indexed values, and the command
station didn't report any errors. This speeds things up greatly (can save over an hour when reading
an ESU LokSound V4 decoder with a DCS240).
This option is under user control, see above, and defaults to off. If a decoder cannot do this, e.g. the index values really do have to be written every time, that should be signaled by setting "skipDupIndexWrite" to false in the decoder definition, see the documentation page.
- Name selection options — Two new methods for
selecting names for "State Variables" and "Actions"
have been added. Choose the desired option using the Logix Table
- Use Traditional Pick Lists — The default option uses a text field where the system or user name is entered, such as a turnout or sensor. This method also provides a Pick List window with tabs for each type of object. Drag a name from the pick list and drop it on the name field.
- Use Single Pick Lists — This option also uses a text field, but the Pick List only displays the names for the current object, such as sensors. Clicking on a name in the Pick List will automatically copy the name to the text field.
- Use Combo Name Boxes — The Combo Box option changes the text field to a drop down combo box. Clicking on an item selects the name.
- Conditional Browser — A Browse option has been added to the Select menu for each Logix in the table. Selecting this entry will open a window that contains a formatted list of the conditionals contained within the selected Logix.
- The Logix help documents have been updated.
- Egbert Broerse added a new type of panel, Switchboards. They provide a grid of buttons to control turnouts, lights or sensors. Existing items will show their current state and allow you to toggle their state. This first edition include German and Dutch translations.
- Greg McCartney provided new definitions for the Southern 1981 system
- SE8c Signal Heads now follow traffic on the layout, so if another signal system is setting the hardware SE8c signals, the JMRI panel signals will follow them.
- The Create/Edit Warrants help file was updated to explain the "Share Route" and "Don't Ramp" options.
- Implementation of these options was completed.
- A bug preventing restarts of cleared occupancy was fixed.
- New feature to upload new or updated Roster Entry xml files and images. At top of existing Roster page.
- Much more Danish translation from Sonnys Hansen.
- Print outs of roster reports from DecoderPro were updated by Egbert Broerse to use translatable headings (don't translate the word 'CV')
- User Names entered by the user are checked for spaces at the start and end before they are applied. We expect this will prevent some hard to spot errors.
- The naming scheme for JMRI builds has changed slightly. Build metadata (the building user, build date/time, and git revision at time of build) are now deliniated using plus (+) signs instead of hyphens. The build date/time is now ISO 8601 parsable. (#3253)
- The library used to identify connected systems on Windows has been updated. Although this should have no impact, scripts that accessed the Windows Registry using the WinRegistry should be updated to use Java Native Access. (#3353)