Bosse,

Please confirm that JMRI is having problems with the L2T112 item? That would make sense to me, as JMRI sees L2T112 as a LocoNet "turnout" item (as specified by the "T" in the system name). LocoNet Turnout items cannot be interpreted by JMRI as "Sensor" items, and JMRI cannot interpret LocoNet turnout messages for the purpose of receiving block occupancy information.

If you are indeed having difficulties with L2T112, then the solution will likely be to configure the MGP device so that the input that generates the L2T112 message is using different LocoNet messaging and generating L2Snnn messaging. How to re-configure the device will be very specific to the MGP device, and I have no direct experience in reconfiguring those devices.

Note that LocoNet devices sometimes "pair" two inputs for the purposes of reporting "exact" feedback of turnout position. When using LocoNet "Exact" feedback, each of two paried inputs is connected to a "microswitch", and each of the switches is activated physically by opposite ends of the turnout point throw. A specific type of LocoNet messaging is used when "exact" feedback is configured.

If you configure the LocoNet device to report via "exact" feedback messaging but are using only one of the inputs (as "single-sensor" feedback reporting), then the other input of the pair will generally _also_ use that messaging type. If you use that other input for some other purpose, like occupancy detection, you will likely get the "exact" feedback message type.

Many software packages make it difficult to make use of information found in "exact" feedback messages for purposes other than turnout position feedback. JMRI is one of those packages which do not (easily) allow interpretation of LocoNet "exact" turnout messaging for anything other than turnout position reporting.

If you are implementing "single-sensor" turnout position feedback using "exact" turnout position LocoNet messaging, then it would be better to configure the MGP so that the inputs are treated as "general sensors", and simply configure JMRI's L2Txxx turnout's feedback to be sensitive to one of the "L2Syyy" messages. With that configuration, the "L2Syyy" would be for turnout position feedback and "L2S(yyy+1)" could be used for other purposes, such as a block occupancy input.

With your MGP device properly configured to report via general sensor LocoNet messaging, it is necessary to configure JMRI properly. Any JMRI turnout which uses two microswitches to report "exact" feedback via general sensor LocoNet messaging needs to be configured for JMRI "two sensor" feedback. Any JMRI turnout which uses one microswitche to report "exact" feedback via general sensor LocoNet messaging needs to be configured for JMRI "one sensor" feedback.

Regards,
Billybob

On August 4, 2019 at 10:51 PM Dave Heap <dgheap@...> wrote:

James,

?

?

On 5 Aug 2019, at 12:10 PM, James Koretsky < jameskoretsky@...> wrote:

Can CV's be read in Direct Mode, and is this true for all decoder brands, trying to idiot proof how to do this, without having to switch between paged and direct mode?

?

Almost (if not) all modern decoders support Direct mode programming (read/write). Direct mode is very much faster and (for many DCC systems and decoders) gives more reliable results. JMRI is coded to know what mode(s) each decoder definition supports.

Most modern DCC systems support Direct mode. JMRI is coded to know what mode(s) each system supports) and in many cases the list has been ordered to prioritise the fastest.

Trying to read a modern ESU decoder in Paged mode can take an hour or more depending on DCC system. A V4/Select has ~1,000 CVs and a LokSound 5 has ~2,000 CVs.

Dave in Australia

?

Hi.
I have JMRI PanelPro - Z21 - MGB sensor (loconet). All feedback works except the feedback from the sensor when a locomotive passes the block.

The feedback that does not arrive I can see the log on the loconet where the sensor is located but not in the log on JMRI Z21LocoNet or Z21XpressNet

The feedback name is: INPUT_REP: address: 202 state: LO

"SW_REP: address 201 state: closed" goes well.

Is that the address I have to recalculate?

Any experience with the above problems?

?

bossevest@...

On August 4, 2019 at 6:52 PM Dave Heap <dgheap@...> wrote:

James,

?

?

On 5 Aug 2019, at 3:57 AM, James Koretsky < jameskoretsky@...> wrote:

It gets through reading CV8 and CV7, and then goes on to reading Set SI and Set PI before it comes up with Stopping due to error: No Acknowledge from Locomotive (308).

?

It sounds like a DCC system-specific issue, or a loco-specific issue.

Try turning off the caching options in Preferences->Roster->Programmer. (Enable Show CV numbers in tooltips but turn the rest off).

I assume the loco doesn't have a keep-alive?

Don't assume a Select, ScaleTrains also used the ESU Essential Sound Unit (a cut-back 5) and may now be using the 5. JMRI knows about identifying all these.

Just now doing ?some tests with my test decoders, I found that one Select I had been recently identifying correctly was having trouble (indicated by switching to Paged mode). Switched decoder tester to track power, made coupler activation noises and then went silent. Switched back to Program Track and all was well. Seemed as if decoder was trying to use program track power to activate coupler sound (ESU decoders remember function states) and upsetting CV reading! First time I've seen that particular problem.

Always use Direct mode with all ESU decoders, despite some OEMs' advice to the contrary.

Dave in Australia

?

?

Jason,

- Copy ShutDownExample.py to your user files location. ?See Help >> Locations for the actual path.

- Edit your private copy with a text editor. ?Avoid NotePad if using Windows. ?I use WordPad.

- Add a line after the "def execute(self):" line:

? ? ? ? turnouts.getTurnout(’turnout name’).setCommandedState(THROWN)

- Replace turnout name with the user or system name for the turnout that controls the funicular. ?Keep the quotes around the name.

- Make sure that the added line has the same number of leading spaces as the following lines.

- Go to Preferences >> Start Up

- Select Add >> Run script…

- Navigate to your user files location and select the shutdown script.

- Save your preferences change and restart.

The script will start when you start JMRI. ?It will then wait until JMRI is stopped, at which time it will send the turnout command.

Dave Sand

On Aug 3, 2019, at 2:11 PM, Jasen Krueger via Groups.Io <jasenk2@...> wrote:

Hi all,

I’m wanting to set a turnout to throw when I shutdown JMRI. I’m using a turnout control to turn on and off an automated funicular and when I shutdown I?want it to default to “THROW” so it stops running even if the Arduinos still have power.

I see an example ?“ShutDownExample.py” but I don’t understand where it should go and how to activate it since there is only a Start Up” in preferences.

Any help is much appreciated!

Thank you,

Jasen

On Aug 4, 2019, at 14:10, David Klemm <davidklemm7511@...> wrote:

Dave/Ken;

My hunch last night was confirmed today. ?I started up DP and after a bit I attempted to go to get the log file and still got an error. ?I uploaded a screen shot of the error in the folder David K under problems being worked on.

I did go to the roster folder and it has 1195 entries. ?Though about half would be duplicates as they have a .bak extension. ?I know that there are a lot of Lok Sound decoders in there as well. ?I don’t believe there are photographs. ?I forgot to look at the amount of RAM on the PC before I left.

David Klemm

On Aug 4, 2019, at 01:29, Dave Heap <dgheap@...> wrote:

David K,

On 4 Aug 2019, at 12:15 PM, David Klemm <davidklemm7511@...> wrote:

What I meant earlier was after starting DP, I clicked on an entry and then open programmer. Things stall and then the error.?

That's a further clue.

Were you opening one of the new LokSound 5 decoder models? These need 512MB of Java Heap Space (over 2,000 CVs and around 10,000 individual settings to configure and display) and some low-memory machines can't provide this much heap space.

The problem is likely to be worse if you combine this with large roster image files.

Dave in Australia

On Aug 4, 2019, at 01:29, Dave Heap <dgheap@...> wrote:

David K,

On 4 Aug 2019, at 12:15 PM, David Klemm <davidklemm7511@...> wrote:

What I meant earlier was after starting DP, I clicked on an entry and then open programmer. Things stall and then the error.

That's a further clue.

Were you opening one of the new LokSound 5 decoder models? These need 512MB of Java Heap Space (over 2,000 CVs and around 10,000 individual settings to configure and display) and some low-memory machines can't provide this much heap space.

The problem is likely to be worse if you combine this with large roster image files.

Dave in Australia

Hi All,

I had one thought, could this be related to the firmware version contained in the LokSound Select decoders themselves, not being at a level high enough, or the reverse, that the firmware level is to new and JMRI is having an issue reading the decoder?

Regards

James

On August 4, 2019 at 1:57 PM James Koretsky <jameskoretsky@...> wrote:

Hi All,

I am having some issues with JMRI for the first time while I have been programming a Loksound Select decoder as part of using the Read type from decoder function. I am trying to standardize a process for some people to program their locomotives, and if they all do the same thing it might make them programming their own units simpler and not have to get me involved.

I am using a DCS52 (With USB Interface), a Lenovo Tablet running WIndows 10 Build 1803, JMRI Test Version 4.17.2+Re9dde08, and a Digirax for the System Manuifacturer, DCS52 USB Interface as the System Connection, the Serial Port is COM3, Command Station Type is DCS52 USB interface as standalone programmer, L as the Connection Prefix and LocoNet as the Connection Name.

Anyway, as part of the standard programming features for a new locomotive, I use the Read type from decoder button on the Create New Loco window, to keep things standard.

We had programmed some 15 units without sound, and all was going well. I knew there were limitations with some Soundtraxx Sound decoders due to the power requirements needed on to power up the decoder on the Programming track. Most of these locomotives are N Scale and there's very few N Scale units owned by members with Soundtraxx so wasn't worried about the setup for that, then I went to program our first Scaletrains N Scale unit with Factory Sound from ESU, a select I believe in N Scale, and ran into the problem.

It gets through reading CV8 and CV7, and then goes on to reading Set SI and Set PI before it comes up with Stopping due to error: No Acknowledge from Locomotive (308).

I added a Soundtraxx Programming booster, thinking that there wasn't enough power on the programming track to power the decoder, which by the way, I have never seen before on a LokSound Select not be able to have the cv values be read from the programming track before, but then again, I always use the LokProgrammer.

I am getting the same error with the programming track booster, as I was getting before adding the programming booster. This is happening on 3 different locomotives, one from Scale Trains, One from Kato and One from Rapido (HO Scale), all have Loksound Decoders. I myself use the LokProgrammer to program my LokSound decoders, and I don't want a different setup for Loksound units, as we're trying to build a roster of all lococomotives.The LokProgrammer reads the decoders without issue.

Non Sound decoders function just fine, as they should, I have ruled out the porgramming track wiring, as well as the USB connection to the Command station, as we've tried different cables, etc...

Using a throttle in JMRI, and setting the Command Station type to DCS52 (Zephyr Express), I am able to run locomotives on the track outputs of the DCS52, without any issue. So JMRI is communicating just fine with the DCS52 and all 3 Locomotives that I can't read the decoder value using the programming track function just fine with the throttle, in DCS52 (Zephyr Express) mode, but still get the same issue when trying to program..

So what is the issue here, is this an issue with the DCS52, or some other issue, and why can I read the decoders CV values with the LokProgrammer and not JMRI.

What am I missing here? Anyon

Regards

James

?