Re: Cannot start to read decoders
?
.started completely from scratch. Deleted all remnants from previous installs.
.Installed java 17 as suggested in windows installation
.installed jmri - no problem so far.
.Before using DecoderPro I verified connection with the central unit and programming track with loko placed on it
.Started up DecoderPro with empty roster/lokpark- clicked on New loko
.New loko window came up (it is rather small if that is of any significance - see later)
.Klicked read decoder type
.came back with list of decoders (where 4 zimo decoder)
. selected correct decoder (highlight took some seconds!)
. Then entered the id name on the right side - took another 2-4 seconds until decoder address was read and displayed
.Saved the loko to the roster / lokpark
.Status line: Pause
.Exited new lok window - clicked on "Identify"
.correct entry in the Roster (there is just one) is highlighted.
.Klicked exit and save!
.Restarted DecoderPro and klicked new loko
. This time a almost double wide New loko window came up
."Read decoder type" grayed out as well as "open detailed programmer" !
.Staus line: Pause
.Klicked exit and save the log files
Notes:
1) This is windows 11 24H2 all updates applied, iTrain, Central sation Mgmgt software, Anyrail all are working ok.
2) I tried English language as well as my own German - no difference
3) I have tried with the JMRI 5.11.4 test release as well as the current release
4) I have the same JMRI installation runing on another laptop? - Windows Version? is Windwos 11 22H2
Thanks for your patience - if you need more info/tests just let me know
Erik
?
|
The following items have been added to the Files area of the [email protected] group.
By: @EAR <erik@...>
Description:
Logfiles to Problem EAR #240916
|
Re: Experimental "Flatpak" distribution of JMRI
Bob and everyone,
I have no strong feelings about adding a flatpak (and my Linux distribution does not have great support for it, so I won't test - plus I prefer spending my development time on other parts of JMRI which I've been neglecting far too long already).
I'm just slightly wary of either dropping behind java releases or adding more flatpak releases to the JMRI schedule (i.e. 5.10-java17.0.13 on 5.10 release in Dec 2024, 5.10-java17.0.14 on Jan 21, 2025, 5.10-java17.0.15 on Apr 15, 2025 if things go as planned at Oracle).
OTOH, I don't know if this is of any real concern, considering we are already shipping dozens (?) of libraries which also may go out of date in between production releases, and it's not system java but JMRI java :)
Heiko
--
eMails verschlüsseln mit PGP - privacy is your right!
Mein PGP-Key zur Verifizierung:
|
Re: Experimental "Flatpak" distribution of JMRI
This seems like a "solution looking for a problem", at least for *Linux*. Since JMRI is in JAVA and requires nothing outside of JAVA's JRE and installing a suitable JRE under Linux is "trivial" (compared to MS-Windows or MacOS), I am not sure how truely useful or needful this is. I can see a flatpak (or similar) for MS-Windows or MacOS, since it appears that those two O/S's have the greatest problems with installing JMRI, mostly caused by confusion about installing the proper version of a JRE. *I* would find a Linux "Flatpak" distribution of JMRI to be far more hassle to deal with than the current Linux distribution methodolgy of JMRI. Actually, I expect that the current Experimental "Flatpak" distribution of JMRI won't work on my machine(s) anyway -- I expect it is a x86_64 Flatpak and all of my machines use ARM processors. And this brings up a *new* issue that will complicate things: there would need to be *four* Linux flatpaks: ix86, x86_64, armv7l, and aarch64. My only thought about "improvements" in the Linux distribution of JMRI would be the creation of .deb and .rpm distrubutions of JMRI. I realize that JMRI will never be in any Linux distro repo and I understand why that is, but a self-made .deb and .rpm with a proper openjdk-XX-jre depenency could be helpful. *I* could probably help with creating the necessary control files to help with this, if anyone is interested. At Fri, 4 Apr 2025 08:19:38 -0400 "Bob Jacobsen via groups.io" <rgj1927@...> wrote:
A user has been interested in possibly distributing JMRI as a ???FlatPak??? for Linux. I don???t know much about that method, but apparently the distribution file also includes the JRE, so it???s (at least in theory) easier to install.
As an experiment, you can find a 5.10 distribution in this form at
For more on this, see JMRI/JMRI Issue 11658:
Is anybody familiar enough with this distribution method to be able to try it?
Is this something that we should do on an ongoing basis?
Bob
???
Bob Jacobsen
rgj1927@...
-- Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software -- Custom Software Services -- Linux Administration Services heller@... -- Webhosting Services
|
Re: Experimental "Flatpak" distribution of JMRI
As long as it is an additional option for Linux users.? I run RPi and it is super easy right now to rename the existing JMRI folder and extract the replacement.? Yes, I do have to handle Java separately, but then how often is the Java requirements changed.? I would hate to see the existing process changed and/or complicated by something called Flatpak.
--
-splasher in somd
-NCE PowerCab with Raspberry Pi 3b+ and JMRI
-DCC-EX with Arduino Mega?w/motor shield, Raspberry Pi 3b+ and JMRI
-Using??Engine Driver with both
-Generally running the latest dev version of JMRI & Engine Driver
|
Re: Experimental "Flatpak" distribution of JMRI
Bob:
Correction on the JDK... The flatpak installed 5.10 is running on JDK 17.0.11...
Mint running a java --version is reporting the 21.0.6 the Mint distro java version...
More Linux users need to check in...
Jim
|
Re: Experimental "Flatpak" distribution of JMRI
Bob:
Just happen to be sitting in the lab and saw the email...
Using Linux Mint 22.0 which uses flatpak for installs during updates so it's right there to try.
Yes... Your URL downloaded and doing a flatpak install was good, just supplying password and Y when needed. There was a 5.8 on that machine and it seems to have been found when the 5.10 installed brought prefs forward.
I didn't check logs to see if the JDK was changed, quick check is version 21.0.6.
Obviously need to run more checks... this is a test machine and not in production...
Jim Albanowski
|
Experimental "Flatpak" distribution of JMRI
A user has been interested in possibly distributing JMRI as a “FlatPak” for Linux. I don’t know much about that method, but apparently the distribution file also includes the JRE, so it’s (at least in theory) easier to install.
As an experiment, you can find a 5.10 distribution in this form at
For more on this, see JMRI/JMRI Issue 11658:
Is anybody familiar enough with this distribution method to be able to try it?
Is this something that we should do on an ongoing basis?
Bob
—
Bob Jacobsen
rgj1927@...
|
Expanding on Dave Sand's idea, assign a virtual sensor to the block.
The sensor is set occupied by Logix or LogixNG when both blocks on either side are occupied, otherwise unoccupied.
This is the way I have been indicating occupied turnouts, without hardware detection, for years (before the creation of the "ghost" block).
--
Ken NYNH&H, Old Colony Division, Cape Cod Branch (1949-1959) Loconet * JMRI 5.11.4 * OSX,Win10,Ubuntu
Blog: ?
Youtube:
|
Phil G,
?
CV 1: 9, CV 17: 213, CV 18: 96, CV 29: 39, CV 19: 0. While there is a Primary Address of 9, I use the Long Address 5472. I ran the loco reversed.
?
And Acceleration and Deceleration are 25 and 15.
?
Regards
|
All,
?
The point about braking is certainly a good one. I've just never used anything more than braking sound effects, no actual slowing of the loco.
?
Regards
|
Bob,
?
It's in my OP.
?
Regards
|
I was suggesting one step at a time. Small ones
Phil G
toggle quoted message
Show quoted text
On 4 Apr 2025, at 07:44, Mick Moignard via groups.io <mick@...> wrote:
?
Writing CVs back to a decoder will not magically turn a function, like
brakes, back on.
I’d look at speed tables, inertia, stuff like that next if the OP is sure
his addressing is correct.
Mick
Mick
______________________________________
Mick Moignard
mick@...
p:+44 7774 652504
The week may start M, T, but it always ends WTF!
|
Writing CVs back to a decoder will not magically turn a function, like
brakes, back on.
I’d look at speed tables, inertia, stuff like that next if the OP is sure
his addressing is correct.
Mick
Mick
______________________________________
Mick Moignard
mick@...
p:+44 7774 652504
The week may start M, T, but it always ends WTF!
|
Well yeah! Delay to inactive should do the trick. I was not aware of that little tool.
I'll give it a try.
?
Tnx again
George
|
Hi folks
Well darn! As usual the answer is easy but I didn’t think of it
Thank very much! ?
John Stewart
Birmingham District MRR
|
Which decoder definition is this, exactly?
Bob
—
Bob Jacobsen
rgj1927@...
|
Wouter comments: ? “The question should really be asked as: - what does jmri write to these cvs? - what is read back on the programming track? That would rule out another type of error.” ? JMRI _should_ be writing that which is displayed on the screen when whatever command to write to the decoders is executed.? Hopefully it is either “Write all . . . “. ? Reading back the values of the CVs _after_ the “Write .? . “ to the decoder would be a good idea, but I suspect the OP has done the equivalent by using the compare process on the CV’s tab. ? Anything that sheds further light on what is occurring is a good idea. ? Best regards, ? Steve ? Steve Haas Snoqualmie, WA
|
John,
?
I would also recommend that you disable pickups on the staging arrivals track, so the program does not move the "moves" to the last movement.
?
Eric
|
The question should really be asked as: - what does jmri write to these cvs? - what is read back on the programming track? That would rule out another type of error.
Wouter
After writing back to the decoder, what’s in cvs 1, 17, 18, 29 and 19??
Phil G
?
Continuing the conversation, Don responds:
?
Not likely – CV19 is just another location in the decoder to be compared to the data stored in the record in the Decoder Pro Decoder index.
This could be tested by changing CV19 in either the decoder itself or in the record in Decoder Pro, then running the compare function on the CV page.
“You read the part where I say the settings had been working... for years in fact,
right? No mysterious brake, BEMF, consist, or the like. And
Economies don't, to my knowledge, have Drive Hold, Reverser Centered, or such features that could even accidentally
be activated.”
Yes, I did.
The symptoms are identical to those reported previously by others where the
braking functionality _has_
been revealed to be the cause.? While you are
adamant this is not the case (no reason to doubt you), the symptoms _do_
seem to match that possibility.
So, if not braking related, what is left?
From your description, a reset decoder
works fine until the values stored in Decoder Pro are written to the decoder,
at which time the decoder ceases to
respond.
I don’t recall the specifics;? Can you share the make
and model of both your DCC system and the decoder again??
After you issue the decoder reset
command, the loco/decoder responds at short address three, correct?
And after that you write the data
stored in Decoder Pro back to the decoder, correct?
Does writing the settings from Decoder Pro
back to the decoder itself result in the address being changed from short address 3 to some other address (short or long), and that is the address
the decoder is not responding to?
I’m starting to suspect some type of
potential disconnect between data loaded into the decoder
via the reset, and data the command station
has stored in regard to the address that doesn’t work after the decoder data is written to the decoder.
Various DCC systems store different pieces of data about a loco/decoder in their memory.
I’m not a specialist on the internal workings of various command stations, so folks with knowledge of your specific
system’s internal workings would have to chime in here.
Hopefully this will give you some additional
paths to explore.
Keep us posted.
Best regards,
Steve
Steve Haas
Snoqualmie, WA
?
Regards
|
splasher
Bob Jacobsen
Ken Heywood
George Hofmann
John Stewart