Re: FileRepMalware message when I try to execute the latest downloads. #malware

Hi Marcus,

I've been having the same problem, I cannot install on either of my Win 10 machines. I am using Avast anti virus. I have successfully installed on one Win 7 PC and? one Win 7 laptop. (I have 4 PCs and 2 Laptops). I am unable to install on 2 Win 7 machines.See my post on 11 Sept -Unable to load JMRI 4.17.4.

You are not alone!

Best, Mike.

On Saturday, 21 September 2019, 23:19:56 BST, Marcus Ammann <mammann@...> wrote:

Hi All

?

Why do I get this ” FileRepMalware” message when I try to “execute” (click on the .exe file) after downloading the latest two versions of JMRI when I try to upgrade Decoder Pro, using my NCE Power Pro system and Windows 7.

?

I am presently using 4.15.6 so I thought I get with the latest.

?

I haven’t seen any messages regarding my issue on this list over the last few months, so why am I the only one having issues.

?

Googling “FileRepMalware” says my AVG has found Malware and I should not use the file. I have used Decoder Pro for over 15 years. I am a computer novice and I don’t need to upgrade to Windows 10 just at this particular time. Version 4.15.6 programs my decoders just fine.

?

Can someone help me.

?

Regards

Marcus

Layout Video

Web Site

?

Re: Signal Mast Appearance definition file

#164171

Some of the systems include semaphores such as BR-2003 and BNSF-1996 for example - there may be others. Which system do you require?

FileRepMalware message when I try to execute the latest downloads. #malware

#164170

开云体育

Hi All

?

Why do I get this ” FileRepMalware” message when I try to “execute” (click on the .exe file) after downloading the latest two versions of JMRI when I try to upgrade Decoder Pro, using my NCE Power Pro system and Windows 7.

?

I am presently using 4.15.6 so I thought I get with the latest.

?

I haven’t seen any messages regarding my issue on this list over the last few months, so why am I the only one having issues.

?

Googling “FileRepMalware” says my AVG has found Malware and I should not use the file. I have used Decoder Pro for over 15 years. I am a computer novice and I don’t need to upgrade to Windows 10 just at this particular time. Version 4.15.6 programs my decoders just fine.

?

Can someone help me.

?

Regards

Marcus

Layout Video

Web Site

?

decoder definitions

#164169

Hi,
I have encountered a decoder that jmri reports back as a: Regal Way co. Version 106.
Is there a defintion for this one?
It is the OEM decoder in a powerline models T class locomotive

cheers
Stu

Re: Possible roster problem #zimo

#164168

开云体育

Don

Please refresh my memory - what version firmware do you have in the command station?

Gerry

On 22/09/2019 5:19 am, Don Weigt wrote:

Bob,

Thank you for the very helpful?information that the JMRI throttle message code doesn't know or care what decoder type is out there.

I thought the EasyDCC Command Station just added those JMRI throttle messages as packets to its queue. But, if what you wrote is true, then the Command Station must convert speed commands into the right packets for the various decoder speed step settings, such as 14 or 28, or 128, and format them for long or short addresses.

Bob Jacobsen: "The code in JMRI that creates the Throttle messages to the EasyDCC command station knows _nothing_ of the decoder type. No matter what decoder type is out there, in JMRI’s roster or not, JMRI will send the same message to the command station given the same address and same speed/function/whatever content.

The problem is somewhere in the EasyDCC command station, EasyDCC throttles, and/or decoders themselves."

And then: "The ones where it seem to work and then stop or are changed are almost certainly due to another throttle sending conflicting commands. Physically disconnect _all_ the EasyDCC throttles, remove the batteries from any that have them, reset (power off/on) the command station, and see if that class of problems remains."

I do understand that, and said so in different wording. I found it most significant simply because it was the first time I'd been able to make any JMRI throttle cause any action by an LE103 decoder.

I do think a packet sniffer is the next step. I need to compare packets to the LE103 decoders from EasyDCC throttles and JMRI throttles. Any differences in packets from my EasyDCC in response to JMRI messages would contain the problem. Once I know what's wrong, I should be able to zero in on the cause and fix. Yet, if packet formatting for both is done by my EasyDCC Command Station, it seems odd those from its throttles get formatted properly, and those from JMRI don't.

I do hope to get this to work. I want to keep my plug in EasyDCC throttles for most walkaround control of the trains. I don't want to replace the Command Station, walkaround throttles, and layout wiring to keep that function, simply to add guest train control via smart phones and JMRI. I'd probably give up JMRI train control first, using it only to replace hardware panels for route control and signalling.

Don Weigt.

Connecticut

-- 
Gerry Hopkins MMR #177 FNMRA
Great Northern Downunder




NMRA Australasian Region
Contest & AP Chairman
Web Administrator

Virus-free.

Re: Installing DecoderPro onto MacBookPro and ESU decoder?

#164167

开云体育

Steve,

On 21 Sep 2019, at 6:45 PM, [email protected] wrote:

Then it goes on to say in the Walthers "Basic Programming Notes":
"We recommend using Paged Mode programming to adjust CV settings - Please refer to your DCC system manual for more information. Programming track boosters are not necessary in order to program the decoders."

I'm afraid that advice from Walthers is incorrect and I've drawn ESU's attention to this a number of times.

Paged mode has significant problems with some systems, is very slow and should not be used for any ESU decoders. Use a Direct mode.

Jumping ahead - I just learned this week, from Walthers service tech, that a program track booster is required to deal with sound decoders and the need to use the ESU LokSound program on a PC in order to program the new ALCo PA units with ESU decoders. It was also suggested by one of the people who responded to my inquiry on Trainorders,com Model Railroad board. I received several other responses on Trainorders with ideas.
What do you recommend?

The advice that you need LokProgrammer and a PC to program an ESU decoder is also incorrect.

If you have an NCE Power Cab system, that advice from Walthers is again incorrect. You should not use a program track booster with an NCE Power Cab system.

If you have an NCE Power Pro system, you may need?a program track booster, depending on the age of the system. The SoundTraxx PTB-100 is the best for use with the NCE Power Pro. The alternative PowerPax offering is not as good with the NCE systems.

I am one of the JMRI development team and my particular areas of interest are ESU decoders and NCE systems.?I've done the majority of the ESU definitions for decoders released over the past few years (V4 onwards) and my development systems are NCE Power Pro (with PTB-100), NCE Power Cab and SPROG IIv3. All my development work is done on Mac computers (although I also sometimes test on Windows and Linux). I also have a LokProgrammer but that doesn't work with JMRI nor on macOS.

So the latest JMRI V4.17.4 will correctly uniquely identify any modern decoder made by ESU and I keep JMRI up-to-date with the supported decoders list in the latest LokProgrammer release.

Dave Sand's advice about macOS and the "Massoth" result are correct. Stay with us and we'll get you working.

I'm afraid you've been given lots of incorrect information from non-JMRI sources.

Dave in Australia

Re: Problem to reset slots with JMRI

#164166

Marc,

Thank you for clarifying your process.  I will respond separately with detailed JMRI behavior information for the _many_ use cases related to clearing of LocoNet slots.

Regards,
Billybob

Re: Problem to reset slots with JMRI

#164165

After reviewing the JMRI code, this makes sense to me.  Each different mechanism for "resetting slots" has different effects on JMRI and the command station.

- JMRI's Slot Monitor  "Clear all Non-InUse Slots" button on has had a couple of different implementations.  Initially implemented some time in 2013, current JMRI code (since some time in 2015) individually sends a LocoNet message to write the "slot status" to the "FREE" state for those slots JMRI thinks is un-consisted and "other than IN_USE".  JMRI code currently does nothing to those slots JMRI thinks are either consisted or "IN_USE".  ("FREE" and "IN_USE" have very specific meanings in LocoNet parlance.)

- Setting command station configuration using JMRI's Command Station Configuration tool to write OpSw36 to ask the command staiton to "reset the slots" (and/or command station OpSwitches 37, 38, and/or 39) uses a very specific LocoNet message to make the command station OpSw changes.  Since at least 2012, JMRI's Slot Monitor watches for this LocoNet message and checks to see if any of OpSw36, 37, 38, or 39 has been writen to ask the command station to reset the slots.  If so, it triggers a sequence of slot reads of every slot between 0 and 127.  If the command station has actually modified any of its slots as part of this process, then JMRI Slot Monitor will reflect the new slot information.  If the command station has not modified a slot, JMRI will read "old data".  (There is some question in my mind of exactly how long it takes the command station to reset its slots, and whether or not JMRI could be reading slot data before the command station either starts or finishes resetting the slot information.  This is likely useless speculation, since at least some users have great success with this process.)

- Setting command station configuration using JMRI's "Roster"-based programming methods for command station OpSw settings is identical to the previous comment about JMRI's Command Station Configuration tool - the Roster mechanism uses the same LocoNet messages as the Command Station Programming Tool; the effects on JMRI (and the command station) of that LocoNet message will be identical.

- Setting command station OpSw36 (or 37 or 38 or 39) using a throttle with the command station in "OpSw" mode is _ENTIRELY_ transparant to JMRI.  JMRI simply sees a LocoNet message to change turnout 36 (or 37 or 38 or 39) to "closed".  JMRI cannot determine that the LocoNet turnout control message was actually a change to the command station's OpSw36 (or whichever) setting.  So JMRI cannot react to that operation.  Slot monitor will therefore be tracking old slot data.  The easiest way to resolve this incoherency is to quit and restart JMRI.

- Resetting slot contents using a DT500 and its "SlotZero" operation, it sends a sequence of LocoNet messages which sequences through the available slots, and, according to my notes, for each one: 
a) reads the slot
b) writes the slot back, with speed 0, all functions off, and "slot status" set to "COMMON".  All other slot information is left as-is.

If this "SlotZero" feature is used with a command station which implements only "Standard" slots, JMRI will see each of these slot writes.  JMRI will not see any of these writes if the command station implements "enhanced" slots or "expanded" slots (i.e. DCS240, DCS210, DCS52 in normal operating modes).

- Setting command station OpSw36 (or 37 or 38 or 39) using the control panel on a DCS50, DCS51, or DCS52 is something I cannot address at this time.  My notes do not disclose what LocoNet activity is seen when command station OpSw 36 (or 37 or 38 or 39) is set to "closed", so I cannot assess JMRI's behavior in that case.

- According to my notes, pushing the "Loco Reset" button on the DCS240 or DCS210 does not generate any LocoNet "slot write" messages, so JMRI's Slot Monitor is ignorant of the pushbutton operation or its effect on LocoNet slots.  Slot monitor will be tracking old slot data.  The easiest way to resolve this incoherency is to quit and restart JMRI.

- Where possible, clearing the OpSw settings by powering the command station down, opening the case, and removing the battery for a period of time, then re-installing the battery and re-powering is something which JMRI cannot possibly have any visibility to.  If JMRI were running thru this process, Slot monitor will be tracking old slot data.  The easiest way to resolve this incoherency is to quit and restart JMRI.

- I do not use software packages other than JMRI, so I cannot speak to issues and/or features of those packages.

- I am not familiar with the mechanisms used by non-Digitrax LocoNet-based command stations to "reset their slots", so I cannot assess the effect on JMRI's slot monitor.

This is a complete list, to the best of my current knowledge, of ways to "clear the slots" or "clear the in-use" slots in a LocoNet-based system, and the effects and impacts upon JMRI.  Questions, corrections and clarifications are welcomed.

If you have detailed technical information for those cases where I have no information, I would love to see it, as would at least some other members of the community - especially the DCS50, DCS51, DCS52 control-panel OpSw36 (/37/38/39) operation behavior on LocoNet.

Regards,
Billybob

Re: NCE PowerPro Connection Issues

#164164

开云体育

Dave – yes, the errors are the same if the adapter is plugged into the serial port on the command station as when it’s not (but still plugged into the USB port on the computer), which are both the same as the errors which showed up when I shorted the 2 and 3 pins on the adapter.

?

Looking back at the original log I posted on Wednesday, I believe the errors are the same as I got back then, too.

?

-- Jeff

?

Show quoted text

From: [email protected] [mailto:[email protected]] On Behalf Of Dave Heap
Sent: Thursday, September 19, 2019 7:02 PM
To: [email protected]
Subject: Re: [jmriusers] NCE PowerPro Connection Issues

?

Jeff,

?

On 20 Sep 2019, at 8:30 AM, Jeff Mutter <jwmutter@...> wrote:

I’m not sure if it was the same set of errors but yes, I got several errors about three times before I saved the last one.

?

Do you still get the same errors if you aren't trying the loopback mode but just have it:

1) Unplugged from the Power Pro end.

or

2) Plugged into the Power Pro.

?
I did upgrade Java yesterday, too.? Could that be related?

?

Unlikely.

Re: NCE PowerPro Connection Issues

#164163

Dave -- I removed all the JMRI files and folders but the JMRI folders in the Users folder, rebooted the computer, reinstalled JMRI v.4.17.4, rebooted again, and still got the same thing.

-- Jeff

Show quoted text

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Dave
Sand
Sent: Thursday, September 19, 2019 7:03 PM
To: [email protected]
Subject: Re: [jmriusers] NCE PowerPro Connection Issues

Jeff,

Since you are using Windows, a JMRI upgrade may leave some old stuff
behind depending on how old the previous version was.

I always do a clean install.  This involves using the Control Panel to remove
the old JMRI version followed by manually deleting the residual JMRI
directory in C:\Program Files (x86).

Note:  If you have placed custom components, such as icons, in the install
location instead of the user files location, be sure to back them up before
doing the cleanup steps.

The user data, such as rosters, panels, operations files, etc., are located at
C:\Users\<username>\JMRI.

Dave Sand

On Sep 19, 2019, at 5:30 PM, Jeff Mutter <jwmutter@...>wrote:

I’m not sure if it was the same set of errors but yes, I got several errorsabout three times before I saved the last one.

I did upgrade Java yesterday, too.  Could that be related?

-- Jeff

From: [email protected] [mailto:[email protected]] On Behalf OfDave Heap
Sent: Thursday, September 19, 2019 6:16 PM
To: [email protected]
Subject: Re: [jmriusers] NCE PowerPro Connection Issues

Jeff,

On 20 Sep 2019, at 3:12 AM, Jeff Mutter <jwmutter@...>wrote:

Shorted the “2” and “3” pins on the serial adapter.  Didn’t see the“timeout flushes receive buffer: AA” message, but got a bunch of “ERROR”
messages (see log below).  Does that mean the adapter is bad, or do the
error messages mean something else is wrong?
It looks more like a transient error in the JMRI or the Pure Java Commlibrary we use. Or possibly a poor contact between pins 2 & 3.

Is it reproducible every time you start JMRI?

Dave in Australia

Re: Possible roster problem #zimo

#164162

Bob,

Thank you for the very helpful?information that the JMRI throttle message code doesn't know or care what decoder type is out there.

I thought the EasyDCC Command Station just added those JMRI throttle messages as packets to its queue. But, if what you wrote is true, then the Command Station must convert speed commands into the right packets for the various decoder speed step settings, such as 14 or 28, or 128, and format them for long or short addresses.

Bob Jacobsen: "The code in JMRI that creates the Throttle messages to the EasyDCC command station knows _nothing_ of the decoder type. No matter what decoder type is out there, in JMRI’s roster or not, JMRI will send the same message to the command station given the same address and same speed/function/whatever content.

The problem is somewhere in the EasyDCC command station, EasyDCC throttles, and/or decoders themselves."

And then: "The ones where it seem to work and then stop or are changed are almost certainly due to another throttle sending conflicting commands. Physically disconnect _all_ the EasyDCC throttles, remove the batteries from any that have them, reset (power off/on) the command station, and see if that class of problems remains."

I do understand that, and said so in different wording. I found it most significant simply because it was the first time I'd been able to make any JMRI throttle cause any action by an LE103 decoder.

I do think a packet sniffer is the next step. I need to compare packets to the LE103 decoders from EasyDCC throttles and JMRI throttles. Any differences in packets from my EasyDCC in response to JMRI messages would contain the problem. Once I know what's wrong, I should be able to zero in on the cause and fix. Yet, if packet formatting for both is done by my EasyDCC Command Station, it seems odd those from its throttles get formatted properly, and those from JMRI don't.

I do hope to get this to work. I want to keep my plug in EasyDCC throttles for most walkaround control of the trains. I don't want to replace the Command Station, walkaround throttles, and layout wiring to keep that function, simply to add guest train control via smart phones and JMRI. I'd probably give up JMRI train control first, using it only to replace hardware panels for route control and signalling.

Don Weigt.

Connecticut

Re: JythonAutomation and JythonSiglet use?

#164160

Correction
I use classes

jmri.jmrit.automat.Siglet

jmri.jmrit.automat.AbstractAutomaton

?

--
Petr ?ídlo
Czech Republic

Re: Signaling - strange message in apperance table

#164159

?SD Czechoslovakia signal definition is OK too

--
Petr ?ídlo
Czech Republic

Re: JythonAutomation and JythonSiglet use?

#164158

I am working on a project how to adapt the JMRI Entry-Exit tool to an Extry-Exit interlocking system used by the Czechoslovak State Railways. Most work is done in Jython. The project is not ready yet.

--
Petr ?ídlo
Czech Republic

Re: Installing DecoderPro onto MacBookPro and ESU decoder?

#164157

Steve,

I can’t help with decoder specific issues but I also run macOS, although Mojave not High Sierra.

From the Apple menu, select System Preferences >> Security & Privacy, General tab. ?Unlock if necessary and select App Store and Identified Developers. ?This should work, but an additional step is to do a right click on DecoderPro and select Open instead of doing a double click to launch. ?This allows confirmation that you want to run the program.

When you copy the JMRI folder to Applications, make sure to select Replace.

There are been a LOT of changes to support ESU decoders. ?I recommend that you use JMRI 4.17.4.

The “Massoth” reference and forced edit mode in DecoderPro indicates that you have a simulated connection to the layout hardware. ?This implies that you have a profile issue. ?As Wouter indicates in his response, doing a two step upgrade may address this issue. ? Another approach is creating a new profile but that does require some extra steps.

When working on the connection issues, you will want to look at the JMRI system console. ?Select Help >> System Console. ?It can be intimidating but it provides a lot of very useful information.

Dave Sand

Show quoted text

On Sep 21, 2019, at 3:45 AM, [email protected] wrote:

I am new to this group and have joined because I am stumped trying to install a newer version of DecoderPro. I have been a model railroader for almost?60 years but fairly new to DCC about 4 years with a lot of help from 3 different clubs Including using JMRI at the Columbia Gorge Model Railroad Club?in Portland, OR. So have had a diverse DCC training after a life of working on the ATSF/BNSF 12" to the foot scale for 40 years.
I had been working with DecoderPro 4.8 installed on my MacBook Pro with 10.13.6. It has been some time since I had used it on my own program?track. So have had some experience working with DecoderPro and was pleased with the ease of using the program. So, Yes, JMRI worked before on?this Mac Book Pro, MacOS High Sierra 10.13.6. I had a friend purchase a SPROG and he inclosed it into a box with his 3D printer. And the system?worked fine. I use NCE Power Cab for a controller, but preferred the JMRI DecoderPro to fine tune the DCC decoders instead of the hammerhead. The?DecoderPro operates by connections to the NCE cab thru the NCE standard hook up board without any additional power booster then thru the SPROG?into the USB port on the MacBook. The electronic boards are well protected in their own box.

I just purchased a new pair of HO Scale Walthers PA units ATSF 72L, 72A an A-B set. Unknown to me, until receiving them in the mail, Walthers?changed the decoder to an ESU LokSound decoder from the previous run of the PA model with Sound Traxx which I had purchased last year, ATSF?71L. My plan was to make an A-B-A set with 72L-72A-71L with the new units leading. Also, At some point just last month, I discovered the older 71L?had lost the address assigned to it and had defaulted to 3, so I waited until receiving the new 72L, 72A and work with them in DecoderPro speed?matching, sounds, etc. and assigning a new address.?

So I carefully read the Walthers instructions with the new 72L and according to Walthers instructions it is possible to use the DecoderPro to change the?address in the ESU decoder:
With the Walthers list of features on the new ESU decoder it states:
"Changes to these can be made manually using CV entries or JMRI, but please note that sound files cannot be changed using the ESU LokSound?Programmer." I understand the sound programming issue.
Then it goes on to say in the Walthers "Basic Programming Notes":
"We recommend using Paged Mode programming to adjust CV settings - Please refer to your DCC system manual for more information. Programming?track boosters are not necessary in order to program the decoders."
Jumping ahead - I just learned this week, from Walthers service tech, that a program track booster is required to deal with sound decoders and the need?to use the ESU LokSound program on a PC in order to program the new ALCo PA units with ESU decoders. It was also suggested by one of the people?who responded to my inquiry on Trainorders,com Model Railroad board. I received several other responses on Trainorders with ideas.
What do you recommend?
So following the Walthers instructions I opened JMRI DecoderPro and had the program set to Paged mode. Then did the routine DecoderPro process?of finding the decoder, noting it did have a list of some ESU decoders.?
I set the new Walthers PA 72L on the program track hooked up thru the SPROG and my own NCE Power Cab, clicked onto the top bar "New Loco" to?open the drop down box to let the program determine the decoder. Instead of an ESU decoder it selected "Massoth Elektronik, GmbH" with four drop?down folders for unknown decoders. Then I selected ESU maually. Still no response. Then the JMRI program is locked into Edit Only mode and did not?respond to multiple attempts to revive it.?
After a few more attempts (closing the DecoderPro completely) double checking my own methods using DecoderPro - Unfortunately the DecoderPro?picked the list of decoders for LGB every time. Plus it did not activate the box to advance into the actual program mode. So I tried the older 71L with?SoundTraxx decoder. It too read it as the "Massoth Electronik, GmbH" with the drop down of 4 specific decoders. So I could not even program non-ESU?decoders.?

So now on to the next problem. I figured JMRI team had an up dated DecoderPro that might work better for the new ESU decoders. Up-dating the?DecoderPro was also suggested in a response on Trainorders. So I removed the v.4.8 DecoderPro from my MacBook and went to the JMRI website?and found two new DecoderPros 4.16 and 4.17. I tried downloading and installing them. Downloading was no problem. Installing was a problem. I got?nothing when I tried to open the new JMRI. I even moved it into the Applications folder for JMRI. Nothing. Except at one point the Mac told me I would?have to go through the App Store in order to install the DecoderPro. I tried that using the search tool on the App Store. It did not find DecoderPro nor?JMRI. So I always have fairly good help from Apple Support. They had no clue why it would not let me install the DecoderPro. Of course the Apple tech?had never heard of it, so go figure.?
So now I'm stuck! I can't even install the JMRI DecoderPro that I really like on my MacBook Pro. At least when I brought the issue up at our weekly?model RR club meeting they decided to buy the ESU program and a power booster for our program track. Any suggestions??
Thank you for all this work to help us deal with these complications.?
Steve Rippeteau

Re: Installing DecoderPro onto MacBookPro and ESU decoder?

#164156

Hi Steve,

I honestly don't know whether this is the cause of the more recent JMRI not working for you, but you missed something in the release notes. The ones after 4.12 contain this little nugget:

"If you are currently using JMRI 4.9.6 or earlier, we strongly recommend that you update to JMRI 4.12 and make sure that's running OK before updating to <whatever number>."

If you did, in fact, do that - then I'm sorry I spoke.

Wouter

Show quoted text

On Sat, 21 Sep 2019 at 15:21, <[email protected]> wrote:

I am new to this group and have joined because I am stumped trying to install a newer version of DecoderPro. I have been a model railroader for almost 60 years but fairly new to DCC about 4 years with a lot of help from 3 different clubs Including using JMRI at the Columbia Gorge Model Railroad Club in Portland, OR. So have had a diverse DCC training after a life of working on the ATSF/BNSF 12" to the foot scale for 40 years.
I had been working with DecoderPro 4.8 installed on my MacBook Pro with 10.13.6. It has been some time since I had used it on my own program track. So have had some experience working with DecoderPro and was pleased with the ease of using the program. So, Yes, JMRI worked before on this Mac Book Pro, MacOS High Sierra 10.13.6. I had a friend purchase a SPROG and he inclosed it into a box with his 3D printer. And the system worked fine. I use NCE Power Cab for a controller, but preferred the JMRI DecoderPro to fine tune the DCC decoders instead of the hammerhead. The DecoderPro operates by connections to the NCE cab thru the NCE standard hook up board without any additional power booster then thru the SPROG into the USB port on the MacBook. The electronic boards are well protected in their own box.

I just purchased a new pair of HO Scale Walthers PA units ATSF 72L, 72A an A-B set. Unknown to me, until receiving them in the mail, Walthers changed the decoder to an ESU LokSound decoder from the previous run of the PA model with Sound Traxx which I had purchased last year, ATSF 71L. My plan was to make an A-B-A set with 72L-72A-71L with the new units leading. Also, At some point just last month, I discovered the older 71L had lost the address assigned to it and had defaulted to 3, so I waited until receiving the new 72L, 72A and work with them in DecoderPro speed matching, sounds, etc. and assigning a new address.?

So I carefully read the Walthers instructions with the new 72L and according to Walthers instructions it is possible to use the DecoderPro to change the address in the ESU decoder:
With the Walthers list of features on the new ESU decoder it states:
"Changes to these can be made manually using CV entries or JMRI, but please note that sound files cannot be changed using the ESU LokSound Programmer." I understand the sound programming issue.
Then it goes on to say in the Walthers "Basic Programming Notes":
"We recommend using Paged Mode programming to adjust CV settings - Please refer to your DCC system manual for more information. Programming track boosters are not necessary in order to program the decoders."
Jumping ahead - I just learned this week, from Walthers service tech, that a program track booster is required to deal with sound decoders and the need to use the ESU LokSound program on a PC in order to program the new ALCo PA units with ESU decoders. It was also suggested by one of the people who responded to my inquiry on Trainorders,com Model Railroad board. I received several other responses on Trainorders with ideas.
What do you recommend?
So following the Walthers instructions I opened JMRI DecoderPro and had the program set to Paged mode. Then did the routine DecoderPro process of finding the decoder, noting it did have a list of some ESU decoders.
I set the new Walthers PA 72L on the program track hooked up thru the SPROG and my own NCE Power Cab, clicked onto the top bar "New Loco" to open the drop down box to let the program determine the decoder. Instead of an ESU decoder it selected "Massoth Elektronik, GmbH" with four drop down folders for unknown decoders. Then I selected ESU maually. Still no response. Then the JMRI program is locked into Edit Only mode and did not respond to multiple attempts to revive it.?
After a few more attempts (closing the DecoderPro completely) double checking my own methods using DecoderPro - Unfortunately the DecoderPro picked the list of decoders for LGB every time. Plus it did not activate the box to advance into the actual program mode. So I tried the older 71L with SoundTraxx decoder. It too read it as the "Massoth Electronik, GmbH" with the drop down of 4 specific decoders. So I could not even program non-ESU decoders.?

So now on to the next problem. I figured JMRI team had an up dated DecoderPro that might work better for the new ESU decoders. Up-dating the DecoderPro was also suggested in a response on Trainorders. So I removed the v.4.8 DecoderPro from my MacBook and went to the JMRI website and found two new DecoderPros 4.16 and 4.17. I tried downloading and installing them. Downloading was no problem. Installing was a problem. I got nothing when I tried to open the new JMRI. I even moved it into the Applications folder for JMRI. Nothing. Except at one point the Mac told me I would have to go through the App Store in order to install the DecoderPro. I tried that using the search tool on the App Store. It did not find DecoderPro nor JMRI. So I always have fairly good help from Apple Support. They had no clue why it would not let me install the DecoderPro. Of course the Apple tech had never heard of it, so go figure.
So now I'm stuck! I can't even install the JMRI DecoderPro that I really like on my MacBook Pro. At least when I brought the issue up at our weekly model RR club meeting they decided to buy the ESU program and a power booster for our program track. Any suggestions??
Thank you for all this work to help us deal with these complications.
Steve Rippeteau

Installing DecoderPro onto MacBookPro and ESU decoder?

#164155

I am new to this group and have joined because I am stumped trying to install a newer version of DecoderPro. I have been a model railroader for almost 60 years but fairly new to DCC about 4 years with a lot of help from 3 different clubs Including using JMRI at the Columbia Gorge Model Railroad Club in Portland, OR. So have had a diverse DCC training after a life of working on the ATSF/BNSF 12" to the foot scale for 40 years.
I had been working with DecoderPro 4.8 installed on my MacBook Pro with 10.13.6. It has been some time since I had used it on my own program track. So have had some experience working with DecoderPro and was pleased with the ease of using the program. So, Yes, JMRI worked before on this Mac Book Pro, MacOS High Sierra 10.13.6. I had a friend purchase a SPROG and he inclosed it into a box with his 3D printer. And the system worked fine. I use NCE Power Cab for a controller, but preferred the JMRI DecoderPro to fine tune the DCC decoders instead of the hammerhead. The DecoderPro operates by connections to the NCE cab thru the NCE standard hook up board without any additional power booster then thru the SPROG into the USB port on the MacBook. The electronic boards are well protected in their own box.

I just purchased a new pair of HO Scale Walthers PA units ATSF 72L, 72A an A-B set. Unknown to me, until receiving them in the mail, Walthers changed the decoder to an ESU LokSound decoder from the previous run of the PA model with Sound Traxx which I had purchased last year, ATSF 71L. My plan was to make an A-B-A set with 72L-72A-71L with the new units leading. Also, At some point just last month, I discovered the older 71L had lost the address assigned to it and had defaulted to 3, so I waited until receiving the new 72L, 72A and work with them in DecoderPro speed matching, sounds, etc. and assigning a new address.?

So I carefully read the Walthers instructions with the new 72L and according to Walthers instructions it is possible to use the DecoderPro to change the address in the ESU decoder:
With the Walthers list of features on the new ESU decoder it states:
"Changes to these can be made manually using CV entries or JMRI, but please note that sound files cannot be changed using the ESU LokSound Programmer." I understand the sound programming issue.
Then it goes on to say in the Walthers "Basic Programming Notes":
"We recommend using Paged Mode programming to adjust CV settings - Please refer to your DCC system manual for more information. Programming track boosters are not necessary in order to program the decoders."
Jumping ahead - I just learned this week, from Walthers service tech, that a program track booster is required to deal with sound decoders and the need to use the ESU LokSound program on a PC in order to program the new ALCo PA units with ESU decoders. It was also suggested by one of the people who responded to my inquiry on Trainorders,com Model Railroad board. I received several other responses on Trainorders with ideas.
What do you recommend?
So following the Walthers instructions I opened JMRI DecoderPro and had the program set to Paged mode. Then did the routine DecoderPro process of finding the decoder, noting it did have a list of some ESU decoders.
I set the new Walthers PA 72L on the program track hooked up thru the SPROG and my own NCE Power Cab, clicked onto the top bar "New Loco" to open the drop down box to let the program determine the decoder. Instead of an ESU decoder it selected "Massoth Elektronik, GmbH" with four drop down folders for unknown decoders. Then I selected ESU maually. Still no response. Then the JMRI program is locked into Edit Only mode and did not respond to multiple attempts to revive it.?
After a few more attempts (closing the DecoderPro completely) double checking my own methods using DecoderPro - Unfortunately the DecoderPro picked the list of decoders for LGB every time. Plus it did not activate the box to advance into the actual program mode. So I tried the older 71L with SoundTraxx decoder. It too read it as the "Massoth Electronik, GmbH" with the drop down of 4 specific decoders. So I could not even program non-ESU decoders.?

So now on to the next problem. I figured JMRI team had an up dated DecoderPro that might work better for the new ESU decoders. Up-dating the DecoderPro was also suggested in a response on Trainorders. So I removed the v.4.8 DecoderPro from my MacBook and went to the JMRI website and found two new DecoderPros 4.16 and 4.17. I tried downloading and installing them. Downloading was no problem. Installing was a problem. I got nothing when I tried to open the new JMRI. I even moved it into the Applications folder for JMRI. Nothing. Except at one point the Mac told me I would have to go through the App Store in order to install the DecoderPro. I tried that using the search tool on the App Store. It did not find DecoderPro nor JMRI. So I always have fairly good help from Apple Support. They had no clue why it would not let me install the DecoderPro. Of course the Apple tech had never heard of it, so go figure.
So now I'm stuck! I can't even install the JMRI DecoderPro that I really like on my MacBook Pro. At least when I brought the issue up at our weekly model RR club meeting they decided to buy the ESU program and a power booster for our program track. Any suggestions??
Thank you for all this work to help us deal with these complications.
Steve Rippeteau

Re: Problem to reset slots with JMRI

#164154

Jacques wrote:

"Before last week we were using a DCS 200 and we always clear the slots with JMRI alone no interaction with the command station. It should be the same with the DCS 240 because the option is present in JMRI."

That last statement is best categorized as "falacious logic".  And it just ain't correct.

The statement _assumes_ that JMRI's LocoNet-related development is done in close concert with Digitrax technical personnel.  It _assumes_ that JMRI technical personnel have direct access to accurate documentation of Digitrax hardware operations and accurate descriptions of LocoNet protocols.  So far as I have been able to determine, none of these assumptions has been true since before the DCS240 was introduced, and, if I understand correctly, several years before that.

Remember - Digitrax creates their products and protocols.  In recent JMRI devopment history, JMRI developers _react_ to new Digitrax products.  When they can figure out how best to provide JMRI support, they add those features to JMRI's code base.

Regards,
Billybob

Re: Problem to reset slots with JMRI

#164153

All,

There are _several different_ methods available to clear LocoNet "slots".  Some are JMRI specific.  Some are defined in command station documentation.  Some are provided by other software packages.  They do not necessarily do the same things!

If you talk about "clearing slots" without stating exactly which method you are using, you are only injecting noise into the conversation and are not assisting in resolving the original poster's problem.

(And, where JMRI is concerned, JMRI version number _can_ be very significant, since JMRI's Slot Monitor "clear all slots" feature has undergone revision several times!)

Regards,
Billybob

Re: Problem to reset slots with JMRI

#164152

Before last week we were using a DCS 200 and we always clear the slots with JMRI alone no interaction with the command station. It should be the same with the DCS 240 because the option is present in JMRI.

Jacques