Locked
Re: NCE PowerPro Connection Issues
Dave ¨C 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. ? ?
toggle quoted message
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?
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. 2) Plugged into the Power Pro.
? I did upgrade Java yesterday, too.? Could that be related?
?
|
Locked
Re: NCE PowerPro Connection Issues
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
toggle quoted message
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 errors
about 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 Of
Dave 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 Comm library we use. Or possibly a poor contact between pins 2 & 3.
Is it reproducible every time you start JMRI?
Dave in Australia
|
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
|
Locked
Re: JythonAutomation and JythonSiglet use?
Correction I use classes
jmri.jmrit.automat.Siglet
jmri.jmrit.automat.AbstractAutomaton
?
-- Petr ?¨ªdlo Czech Republic
|
Locked
Re: Signaling - strange message in apperance table
?SD Czechoslovakia signal definition is OK too
--
Petr ?¨ªdlo
Czech Republic
|
Locked
Re: JythonAutomation and JythonSiglet use?
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
|
Locked
Re: Installing DecoderPro onto MacBookPro and ESU decoder?
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
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
|
Locked
Re: Installing DecoderPro onto MacBookPro and ESU decoder?
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
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
|
Locked
Installing DecoderPro onto MacBookPro and ESU decoder?
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
|
Locked
Re: Problem to reset slots with JMRI
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
|
Locked
Re: Problem to reset slots with JMRI
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
|
Locked
Re: Problem to reset slots with JMRI
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
|
Locked
Re: Unsupported decoder: Uhlenbrock 74120
I just had a look at the definitions shipped and the docs for updating them. This is beyond my skill with XML to mess around with.
I don't suppose that a tool exists to simplify this process a bit? Other than a text editor of course...
|
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. 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. Bob On Sep 21, 2019, at 8:47 AM, Don Weigt <dweigt47@...> wrote:
I now have a printout of the JMRI to EasyDCC commands for two locos. One with a year old basic NCE decoder using long address 349 works. One with a Lenz LE103 using long address 1477 does not. I will try decoding them on paper to look for errors.
What I did was try to run forward, stop, run backward, stop, turn the light (CV0) on and off. Those should be easy to decode manually on paper.
Sorry to add confusion, but after reprogramming the LE103 in 1477, it now was sometimes able to switch the headlight on using CV0. It only seemed possible while the EasyDCC Command Station was still circulating the packet from the EasyDCC throttle that turned it off. This was right after unplugging the EasyDCC throttle.
I'd use JMRI to turn on the light, a couple seconds later it would turn off. I'd be able to turn the light back on, I think by pressing the light command twice on the JMRI throttle to get another "off to on" packet generated. After a second or two, it would turn off again. Once about two minutes had passed, and the other packet was cancelled, I couldn't control the light with JMRI. At no time could I make the loco move, forward or backward with JMRI.
I may have to build one of those Arduino based packet sniffers. Data would reduce the number of possible explanations. I appreciate all the analysis, but it's getting confusing. With data to compare to that analysis, some understanding might follow quickly.
If it were only the LE103s that didn't work, I might just replace them with the Zimos MX60 somethings I bought years ago. But, the one Zimo equipped loco I have tried has also not worked right. I could control functions, but not speed and direction. That may be something more easily solved.
I keep hoping I'm one "Ah hah!" moment from a solution. It's beginning to seem I'm just wasting more and more time. But, those decoders were Standard compliant when new, and they SHOULD work! I didn't imagine I might have to replace all my decoders with newer ones to use JMRI....
Don Weigt
Connecticut
-- Bob Jacobsen rgj1927@...
|
I now have a printout of the JMRI to EasyDCC commands for two locos. One with a year old basic NCE decoder using long address 349 works. One with a Lenz LE103 using long address 1477 does not. I will try decoding them on paper to look for errors.
What I did was try to run forward, stop, run backward, stop, turn the light (CV0) on and off. Those should be easy to decode manually on paper.
Sorry to add confusion, but after reprogramming the LE103 in 1477, it now was sometimes able to switch the headlight on using CV0. It only seemed possible while the EasyDCC Command Station was still circulating the packet from the EasyDCC throttle that turned it off. This was right after unplugging the EasyDCC throttle.
I'd use JMRI to turn on the light, a couple seconds later it would turn off. I'd be able to turn the light back on, I think by pressing the light command twice on the JMRI throttle to get another "off to on" packet generated. After a second or two, it would turn off again. Once about two minutes had passed, and the other packet was cancelled, I couldn't control the light with JMRI. At no time could I make the loco move, forward or backward with JMRI.
I may have to build one of those Arduino based packet sniffers. Data would reduce the number of possible explanations. I appreciate all the analysis, but it's getting confusing. With data to compare to that analysis, some understanding might follow quickly.
If it were only the LE103s that didn't work, I might just replace them with the Zimos MX60 somethings I bought years ago. But, the one Zimo equipped loco I have tried has also not worked right. I could control functions, but not speed and direction. That may be something more easily solved.
I keep hoping I'm one "Ah hah!" moment from a solution. It's beginning to seem I'm just wasting more and more time. But, those decoders were Standard compliant when new, and they SHOULD work! I didn't imagine I might have to replace all my decoders with newer ones to use JMRI....
Don Weigt Connecticut
|
Locked
Re: Problem to reset slots with JMRI
Unfortunately, my earlier upload had the wrong checksum in the LocoNet message.
It seems that I was not careful enough.
A corrected version has been uploaded to replace the previous attempt.
Even if the script execution is not useful for a DCS240, maybe my wordy comments can be useful.
For personal reasons, I choose not to participate in the discussion of the need to physical throw the toggle switch. Our club layout and workbench Digitrax installations both are always initialized with that action.
Cliff
|
Paul, ? Each movement of a car (spot) or (pull) takes one "move". If you want to allow both cars to be replaced with others, that will require 4 moves. Pulling one car and spotting another takes 2 moves. ? Dave Beidle St Louis
|
Locked
Re: Signaling - strange message in apperance table
I can confirm that this JMRI web site issue is resolved as of very late US Eastern Standard time Friday nite.
Regards,
Billybob
|
Locked
Re: Problem to reset slots with JMRI
Marc,
Are you using Slot Monitor's "clear all slots" pushbutton, or are you modifying command station OpSw36 in your test?
I ask because the Slot Monitor "clear all slots" pushbutton _does not_ fiddle with command station OpSw36. I just want to ensure that you are not conflating these two _different_ mechanisms!
Regards,
Billybob
|
Paul
A pick-up and a set out is 2 moves.. Set your moves to 4 and you
s/b ok.
Jim E.
toggle quoted message
Show quoted text
Hi. I just joined the group because I am new to JMRI (and model
railroading) and have questions about the program.
I have a location with one spur long enough to hold two flatcars.
All my trains (so far) stop at this location. I have the move
count set to two at this location and pick-up and drop off are
enabled. The spur only accepts loaded flatcars. Also, random is
set to off. However, the program creates switch lists which only
have one move at that location when two are possible.?
The only thing I can think of is it has something to do with the
fact that the train length in settings is set to the length of
trains I will want to run when the layout is finished and I have
all the rolling stock I will need (right now I probably have less
than half). Does the program prioritize train length (that is to
say try to keep the staging tracks being used full) over car
movement?
I would love to hear any ideas any of you have about why this
happens. Thanks
Paul
|
Petr ?¨ªdlo
Charles Meo
Bob Jacobsen