Release Notes for JMRI 4.17.5 release
Date: November 1, 2019
From: Bob Jacobsen
Subject: Test Release 4.17.5 of JMRI/DecoderPro is available for download.
Notes:
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 late in 2019.
(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.
JMRI is now only available under the
GNU General Public License. For more information, please
see our
copyright and licensing page.
Update From Older JMRI Versions
If you are currently using JMRI 4.11.9 or earlier, we strongly recommend that you update to
JMRI 4.12 and make sure that's running OK before
updating to this test release. Once you have JMRI 4.12 running OK,
store your configuration and panel files and use those from then on.
There have been a number of
changes in serial port support, panel file format and configuration options since those earlier releases,
and moving to the stable JMRI 4.12 release
is a good way to work through any possible problems.
If you are currently using JMRI 4.7.3 or earlier on Linux or macOS (Windows doesn't need this),
you must
update to JMRI 4.12 and
carrying out the migration process described in the JMRI 4.12 release note
before updating to this release.
Known problems with this release
- Since JMRI 4.17.5
Certain decoder definitions, particularly complex ones, have trouble
with data entry. Please use
JMRI 4.17.7 or later to avoid this problem.
New warnings for this release:
- JMRI's scripting support now defaults to the UTF-8 character encoding for all
script files on all platforms. This may require that some scripts be re-saved
using UTF-8.
- Windows Only The JMRI installer removes the existing
lib folder from a JMRI installation when upgrading JMRI. The
existing lib folder contents are retained in the backup folder.
This means that any files you have added to the lib
folder will be removed.
- macOS Only This version includes changes to how
the final .dmg file is built, signed and notarized. This was done to increase
compatibility with macOS 10.15 Catalina.
Please drag the JMRI icon to the Applications folder to install this release.
For more information on
Catalina compatibility,
see the
JMRI website.
Older warnings
See the JMRI 4.16 release note for more warnings predating the 4.17
development series. These may be relevant to you if you're updating from an earlier version.
- Since JMRI 4.17.4
Panel file NamedBean items such as Turnouts, Sensors, etc are now written to panel
files in order by their Manager system prefix and system name.
Previously, they had (roughly) been written in the order they'd be
read from the earlier file(s). This will result in a big change to the order
the first time a file is re-written, but after that it should be much more stable.
- Since JMRI 4.15.6
Remembering the location and size of layout panels created and maintained
using Layout Editor, Panel Editor, Control Panel Editor, and Switchboard
Editor is no longer dependent on saving the panel. The location and size
values are retained using the same processes used by other JMRI windows. This
makes the window management behavior consistent. To continue using the
old behavior, go to Preferences >> Display and enable
Use old location and size logic for editor panels.
- Since JMRI 4.15.6
Starting in JMRI 4.15.6, Memories
must have valid system names of the form "IM" folllowed by something.
"IM123" and "IMEAST" are both valid.
The system name "IM", all by itself, has never been valid, but JMRI
will now be enforcing that:
- You won't be able to create a memory with that name via
the Memory table or scripts
- If you have that name in a panel file, an error will be
logged and the panel file won't load. You'll have to
remove it from he file or rename it in the file
before loading it.
JMRI needs to start enforcing this in preparation for some
future code that will appear later this year.
- Since JMRI 4.15.5
The handling of Turnout system names has been updated
to be (more, hopefully completely) consistent with the
planned approach.
Specifically, case now (generally) matters in system names:
- You can now have an internal turnout named "ITsome lower case name".
- But note you can no longer refer to "ITSOME LOWER CASE NAME" or
"ITSome LoWeR cAse Name" and get the same one.
This should not require any migration for stored configurations or
panel files, as they have been automatically been being kept consistent
since JMRI 4.8. But you might have case errors in i.e. scripts which
will fixing inconsistent references in your scripts.
Of course, bugs are always possible. If you find a place where
names seem to be handled inconsistently, please let us know!
- Since JMRI 4.15.4
The calculation of Turnout Addresses for the
Direct DCC Accessory Command ("a" command) mode
has been fixed (commands are now sent to the correct accessory address rather
than 4 less than the nominated hardware address). For pre-existing panels,
changes will need to be made to either the actual decoder address or the panel.
If help is required, ask on the
jmriusers group.
- Since JMRI 4.15.3
The prefix that identifies a layout connection should be a single letter, like "N" or "L",
or a letter and some digits, like "K2" or "D3". Some older systems used to have
longer "legacy system prefixes" like "DX", "DCCPP", "DP", "MR", "MC", "PI", and "TM".
Those legacy system prefixes
will now cause JMRI to issues a warning at startup. In this release, JMRI will
still work with those prefixes, but they will need to be migrated to the proper form soon;
JMRI 4.17.1 and later will require that this have been fixed.
Therefore, this warning can't be suppressed
without migrating the prefix in the connection configuration (and any associated
panel files and scripts).
If you're getting this warning and therefore need to do that migration,
migration page.
- Since JMRI 4.11.4
There are issues with the Pi-SPROG One command station operation. A number of workarounds should be applied:
- Do not turn on the track power until the power supply to the Pi-SPROG ONE is turned on
- Do not enable extra debugging through default.lcf, nor open the system console window
- Do not open the SPROG console window
- Disable power conversion (CV 29) in all locos
- If connecting via VNC (or similar), setup the screen layout before turning on the track power
Pi-SPROG One with version 2.4 or earlier firmware will cause a timeout after a track short circuit. A dialog box will
open to inform the user of this. The track power will be turned off and must be turned on again using the power control.
Download links:
Please note that the download links in this and future JMRI releases link to
Github servers.
People are welcome to distribute the download files further via other websites, etc.
If you want to check that you've received original, unmodified versions, please
check the files against the checksums shown below.
The
list of included commits is available from our
GitHub code repository.
Hardware Support
LocoNet
- Since JMRI 4.17.5
Automatically refresh the slot information when the DCS240/DCS210/DCS52
"Loco Reset" feature is executed as a result of pressing the
"Loco Reset" button. This feature is active only when the
JMRI connection is configured for DCS240, DCS210, or DCS52
acting as the command station.
OpenLCB / LCC
- Since JMRI
4.17.5 The Traffic Monitor window has additional
options to make reading the log easier. A checkbox allows
showing the Node Name of the sender of a message. Another
checkbox allows showing for Event messages the name(s) that
JMRI can deduce about the specific Event ID. These are the
same names as shown in the CDI window, usually Sensor and
Turnout User Names, as well as references to currently open
CDI editor windows that contain the given Event ID.
Layout Editor
- Blocks can be automatically created when assigned to track components in the edit dialogs.
Scripting
- jmri_bindings.py is no longer needed by JMRI to inject default bindings into
Jython/Python scripts.
- Jython has been upgraded to version 2.7.1.
- JMRI's scripting support now defaults to the UTF-8 character encoding for all
script files on all platforms. This may require that some scripts be re-saved
using UTF-8.
- The jython/SetSignalFlashRate.py sample script shows how to
change the flashing on/off time for your signals. Just invoke
it before defining the signals, i.e. before loading your
configuration and panel files.
Signals
- The jython/SetSignalFlashRate.py sample script shows how to
change the flashing on/off time for your signals. Just invoke
it before defining the signals, i.e. before loading your
configuration and panel files.
Tracker
- A Tracker help page is added.
- Tracking can be done with intermediate cars unequippted to draw current.
- Tracker can recover occupation lost due to poor electrical contact.
- Tracking can be followed through dark OBlocks.
Miscellaneous
- Windows Only The JMRI installer removes the existing
lib folder from a JMRI installation when upgrading JMRI. The
existing lib folder contents are retained in the backup folder.
This means that any files you have added to the lib
folder will be removed.
- macOS Only This version includes changes to how
the distributed files are signed. This includes signing individual
libraries, signing libraries inside jar files, signing the three
app bundles, and signing the .dmg file itself, followed by
notarizing the .dmg file.
This was done to increase
compatibility with macOS 10.15 Catalina.
- Added basic support for developer architecture checks via
ArchUnit,
see the
Introduction to JMRI Library Structure
page.