Mitch,

I looked at a recent version of your layout that I have. One thing that might help is simplifying the Logix to perform a specific function rather than the current mixed mode statement. Also, restricting triggers to specific variables can help.

For example using S01 -> S08. LT1 and LT6 are thrown and LT2 and LT4 are closed. When S01 displays other than Danger, enable the feather. The trigger would only be applied S01 aspect changes.

I don’t know if this meets the rules, but it works based on my limited understanding of British signaling.


IX:AUTO:0003C1 CO
[x] R1 IF Signal Mast "S01" Aspect is "Off"
THEN
On Change To False, Set Turnout, "LT259" to Closed

IX:AUTO:0003C5 S06
[x] R1 IF NOT Signal Mast "S01" Aspect is "Danger"
[ ] R2 AND Turnout "LT1" state is "Turnout Thrown"
[ ] R3 AND Turnout "LT2" state is "Turnout Thrown"
[ ] R4 AND Turnout "LT3" state is "Turnout Thrown"
[ ] R5 AND Turnout "LT5" state is "Turnout Closed"
THEN
On Change To True, Set Signal Mast Aspect, "S01F" to One

IX:AUTO:0003C3 S08
[x] R1 IF NOT Signal Mast "S01" Aspect is "Danger"
[ ] R2 AND Turnout "LT1" state is "Turnout Thrown"
[ ] R3 AND Turnout "LT2" state is "Turnout Closed"
[ ] R4 AND Turnout "LT4" state is "Turnout Closed"
[ ] R5 AND Turnout "LT6" state is "Turnout Thrown"
THEN
On Change To True, Set Signal Mast Aspect, "S01F" to Four

IX:AUTO:0003C4 Set Zero
[x] R1 IF Signal Mast "S01" Aspect is "Danger"
THEN
On Change To True, Set Signal Mast Aspect, "S01F" to Zero


Another approach is using scripting to get around the limitations of the Logix.

I have created script based feather logic. See the feather.py file:

/g/jmriusers/files/ProblemsBeingWorkedOn/dsand/feather.py

This replaces the Logix for implementing feathers.


Dave Sand

Rick,

On 29 Sep 2019, at 1:39 AM, Richard Stern <rjs8@...> wrote:

I think deleting decoder-index.xml has solved the problem. I've opened several programming windows.

Good to hear.

I'll inform of any further problems of they occur.

Hopefully not, but please do.

Dave in Australia

Unable to open a throttle.
Win 10, Locobuffer USB, DCS 50, BDL 168.
error is "Failed to get response from command station".
Note that programming track is working as expected, and track power can be turned off and on.
(This is on our programming table, not connected to the layout.)

Thomas
DeSoto, TX

Hi Bob
What is the feedback you are using?
Steve G.

I think deleting?decoder-index.xml has solved the problem. ?I've opened several programming windows. I'll inform of any further problems of they occur.?

Thanks so much for your help!
Rick

开云体育

It has been an ongoing but occasional issue. I had the problem occur with my previous layout. I am building a new one and it seems to be occasionally occurring again.?

Hi Bob
It sounds like the feedback mode, or feedback hardware, if any, is tad wrong. If you don't have feedback sensors then with loconet you can use "monitoring", "delayed" or "direct". Was everything working and suddenly the problem happened?
Steve G.

Easy way to initialize a layout is to use an LRoute that is set to be
'Initializer'. You can pick the turnouts and choose which setting you want
them to have. It will send the closed or thrown commands as you select.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.org
www.syracusemodelrr.org

Marc,

On 28 Sep 2019, at 5:52 PM, forfoum@... wrote:

You are correct that I have not changed the User Files location in any of my created Profiles. Where is the need to change this stated in JMRI ? I am well aware that YOU prone this change.

There is no need to change the User Files Location.

But many users change it for one or more of the following reasons:
- The desire to share roster and panels between profiles.
- The desire to share roster and panels between computers.
- The desire to have user-based roster separated from panels, such as at a club.

Instructions for doing so are at the link I often point users to, with the comment that it doesn't just apply to Dropbox:
<>
<>

If my setup is totally wrong it is a fault of JMRI and not me. I simply create the Profiles using the existing tools JMRI provides.

There is nothing major wrong with JMRI nor with you. If you create Profiles by simply using New or Copy options, your User Files may or may not be shared, depending on when you first installed JMRI on the computer.
See:
<>
(A link I intended to post earlier but called up the wrong shortcut.)

I tried changing the User File location so it was shared and that created issues with the ROSTER that I shared between Profiles.

That is of concern.

This is how JMRI set it up when I installed and created the 9 Profiles I have. Here is the first Profile

User Files Location: C:\Users\Marc\JMRI\01_None.jmri\
Roster Location: C:\Users\Marc\JMRI\01_None.jmri\
Profile Location: C:\Users\Marc\JMRI\01_None.jmri\
Settings Location: C:\Users\Marc\JMRI\
Current Config file:C:\Users\Marc\JMRI\01_None.jmri\ProfileConfig.xml
Scripts Location: C:\Program Files\JMRI\jython\
Program Location: C:\Program Files\JMRI
Temp Files Location:C:\Users\Marc\AppData\Local\Temp\
Log Files Location: C:\Users\Marc\JMRI\log\
C:\Users\Marc\JMRI\log\messages.log
C:\Users\Marc\JMRI\log\messages.log.1
C:\Users\Marc\JMRI\log\session.log

Now I have a surprise. The ROSTER location gets screwed up...

That is of concern that it happened in your case. I don't remember seeing anyone report it.

If can recreate every time it by a particular sequence of actions, we need to know details.

I opened a thread here for this

The best place to report such reproducible events is to raise an issue on GitHub. Issues raised here get lost in the noise and require effort from someone else to raise a new issue:
<>

but I got no answer from anyone, so I deleted it..

This is not what I would consider a mature and responsible attitude. Deleting a valid issue or post after raising it creates more problems.

Many people are under the impression that the JMRI developers are a paid helpdesk service. We are all (mostly busy) totally unpaid people with many other demands on our time and we sacrifice a lot of personal, family and hobby time to write and support this software.

Here is the same Profile after a restart of JMRI DP. notice the roster location which I did not change at all.

User Files Location: C:\Users\Marc\JMRI\01_None.jmri\
Roster Location: C:\Users\Marc\JMRI\ROSTER\
Profile Location: C:\Users\Marc\JMRI\01_None.jmri\
Settings Location: C:\Users\Marc\JMRI\
Current Config file:C:\Users\Marc\JMRI\01_None.jmri\ProfileConfig.xml
Scripts Location: C:\Program Files\JMRI\jython\
Program Location: C:\Program Files\JMRI
Temp Files Location:C:\Users\Marc\AppData\Local\Temp\
Log Files Location: C:\Users\Marc\JMRI\log\
C:\Users\Marc\JMRI\log\messages.log
C:\Users\Marc\JMRI\log\messages.log.1
C:\Users\Marc\JMRI\log\session.log

That is a concern and you need to raise an issue (and not delete it if we don't jump to deal with it immediately).

We appreciate your contributions and assistance on this list, but you need to take heed when developers question your judgment, maintain civility, report issues in the appropriate manner and certainly don't delete posts just because you didn't get an initial answer.

Dave in Australia

You are correct that? I have not changed the User Files location in any of my created Profiles. Where is the need to change this stated in JMRI ? I am well aware that YOU prone this change.

If my setup is totally wrong it is a fault of JMRI and not me.? I simply create the Profiles using the existing tools JMRI provides.?

I tried changing the User File location so it was shared? and that created issues with the ROSTER that I shared between Profiles.

This is how JMRI set it up when I? installed and created the? 9? Profiles I have. Here is the first Profile

User Files Location: C:\Users\Marc\JMRI\01_None.jmri\
Roster Location: C:\Users\Marc\JMRI\01_None.jmri\
Profile Location: C:\Users\Marc\JMRI\01_None.jmri\
Settings Location: C:\Users\Marc\JMRI\
Current Config file:C:\Users\Marc\JMRI\01_None.jmri\ProfileConfig.xml
Scripts Location: C:\Program Files\JMRI\jython\
Program Location: C:\Program Files\JMRI
Temp Files Location:C:\Users\Marc\AppData\Local\Temp\
Log Files Location: C:\Users\Marc\JMRI\log\
? C:\Users\Marc\JMRI\log\messages.log
? C:\Users\Marc\JMRI\log\messages.log.1
? C:\Users\Marc\JMRI\log\session.log

Now? I have a surprise. The ROSTER location gets screwed up...? I opened a thread here for this but I got no answer from anyone, so I deleted it..

Here is the same Profile after a restart of JMRI DP.? notice the roster location which I did not change at all.

User Files Location: C:\Users\Marc\JMRI\01_None.jmri\
Roster Location: C:\Users\Marc\JMRI\ROSTER\
Profile Location: C:\Users\Marc\JMRI\01_None.jmri\
Settings Location: C:\Users\Marc\JMRI\
Current Config file:C:\Users\Marc\JMRI\01_None.jmri\ProfileConfig.xml
Scripts Location: C:\Program Files\JMRI\jython\
Program Location: C:\Program Files\JMRI
Temp Files Location:C:\Users\Marc\AppData\Local\Temp\
Log Files Location: C:\Users\Marc\JMRI\log\
? C:\Users\Marc\JMRI\log\messages.log
? C:\Users\Marc\JMRI\log\messages.log.1
? C:\Users\Marc\JMRI\log\session.log

Marc

开云体育

On Fri, Sep 27, 2019 at 09:57 PM, Dave Heap wrote:

Not correct. The "decoderindex.xml " file is simply a re-creatable index of the amalgamation of definitions found in "<Program Location>/xml/decoders" and "<User Files Location>/decoders", ?with conflicting file names being resolved in favour of the user's definition. It does not delete any definition files.

On 28 Sep 2019, at 4:18 PM, forfoum@... wrote:

You read me wrong.

I did not read you wrong.

On Fri, Sep 27, 2019 at 09:57 PM, Dave Heap wrote:

Not correct. The "decoderindex.xml " file is simply a re-creatable index of the amalgamation of definitions found in "<Program Location>/xml/decoders" and "<User Files Location>/decoders", ?with conflicting file names being resolved in favour of the user's definition. It does not delete any definition files.

You read me wrong.

I do not change the USER files location, so it follows the PROFILE.

An imported definition file goes in the Profile location? into? "Profile"/decoders. The decoderindex.xml? is one level above in the "Profile".
The decoderindex.xml is an amalgamation, agree,? but it takes precedence over the decoderindex.xml that is in Program files\JMRI\XML?

If I delete the decoderindex.xml that is in the "Profile" location, then the default decoderindex.xml ( in Program file\JMRI\xml ) will not be aware ot the imported definition, hence it will NOT exist.?? The imported definition is still in the "Profile"\decoder but it is not part of the default decoderindex.xml in? Program files\jmri\xml.? so it will not be listed.

I have tested this and these are the result I have seen.

Marc

开云体育

Correct. If it made changes, they would be logged in the console.

I made big changes to this code in JMRI 4.9.5 (the existing code was broken in some circumstances) and now if JMRI can't determine automatically which upgraded definition to use, it will interact with the user and seek guidance.

There are four screenshot examples of this interaction. Take a look at them "Click Here" from the documentation page:

<>

My memory is that a successful run doesn't interact with the user, simply silently logs in the console which roster entries were changed.

开云体育

On Fri, Sep 27, 2019 at 06:00 PM, Dave Heap wrote:

"Rebuild Decoder Index" creates a user's "decoderIndex.xml" file in User Files Location. Deleting this file and restarting JMRI is a useful troubleshooting step. JMRI will then revert to using the distributed?"decoderIndex.xml" file in the JMRI installation.

?

This also, I discovered, only applies to the currently? ' Active Profile '. It does not carry over to other Profiles one might have defined.
So a NEW imported definition one adds to Profile A, will not show in Profile B.? Changing the User files location might help but it creates it's own set of problems I found.

This is by design. Profiles are sacrosanct in JMRI. No JMRI instance is permitted to access other User Files outside its profile unless explicitly instructed by the user to do so (by the user repointing "User Files Location" or "Roster Location" to within another profile). That won't change.

Is there any script that can send a signal to each tortoise upon startup to close so that JMRI can then see the position? (Or would that trigger the same problem?) Otherwise I believe you are proposing sending a closed or thrown signal via the throttle to each turnout individually. I have 36 turnouts so that could take a while.
Bob
Robert J. Perry, O.D.
540 Raintree Dr.
Avon, IN 46123
Home Phone: 317-707-7627
Cell: 954-675-2179
rjpod@...
rjpod@...

开云体育

On Fri, Sep 27, 2019 at 06:00 PM, Dave Heap wrote:

"Rebuild Decoder Index" creates a user's "decoderIndex.xml" file in User Files Location. Deleting this file and restarting JMRI is a useful troubleshooting step. JMRI will then revert to using the distributed?"decoderIndex.xml" file in the JMRI installation.

?

This also, I discovered, only applies to the currently? ' Active Profile '. It does not carry over to other Profiles one might have defined.
So a NEW imported definition one adds to Profile A, will not show in Profile B.? Changing the User files location might help but it creates it's own set of problems I found.

deleting the user's "decoderindex.xml " will? lead to loss of an IMPORTED definition if said definition was not submitted for inclusion in the JMRI distrib..

Marc

So that would involved files named like this :? SoundTraxx_Bachmann_SndVal_Dsl_deprecated.xml

I found the " Update Decoder Definition "? to not be very clear as to it's use:? when to use it. Also one runs it and sees nothing
going on; nothing in System Console. I assume it is? probably because it had nothing to do.?

Marc