Thanks for the advice on how to wire switches folks though completely irrelevant to OP, he is using servo position events for Turnout feedback, no switches involved.

MERG CBUS servo modules can send an event when the servo

• Starts its move - To make Turnout inconsistent
• Midway position - Can be used to trigger switching frog power
• End point reached - Turnout closed / thrown

An issue with JMRI Layout Editor logic which deals with supporting Turnout feedback ( for any hardware type ) has been confirmed with a fix uploaded.

No more posts about switches required thanks,

Steve.

Concur with Thomas on the QSI opinion.?? I remove QSI decoders when I encounter one.?? I do DCC installs for others and I won't touch them.? Too problematic, time consuming, and fickle.??? I had one loco that came back to me 3 times, with the complaint that it wouldn't respond to commands on the individuals NCE layout, but when I placed it on my Digitrax layout ran like a champ.

Yes Dave, that is exactly how I have always wired the feedback for points and when I get to wiring for JMRI will continue to do so.

Tony
https://ozfreemo.com

In our club, QSI was notorious for this. Even with DC off, still happened.
Someone puts a steam Lok on the layout (Beep, Beep, shorts) and any QSI decoder is scrambled.
Sometimes a reset did not bring that decoder back to life.
I Picked up sis QSI equipped Loks from an estate. They all have a new decoder.

Surprised this happened to a Tsunami. Never had that happen to Tsunami at the club.

Thomas
DeSoto, TX?

Jerry,

It is not possible to set Unknown directly, but you can indirectly using a script action:


IX:AUTO:0001C1 C1
[x] R1 IF Sensor "DOIT" state is "Sensor Active"
THEN
On Change To True, Execute Jython Command Jython Command sensors.getSensor('XYZ').setKnownState(UNKNOWN).


Dave Sand

A month ago I posted and got no response. ?Do any of the Logix experts or developers out there have any thoughts on my post:

My first try at LOGIX...I'm trying to set up a LOGIX to check a sensor for being Inactive for x seconds and then set it to Unknown.? I see how to check the sensor, but I don't see how to set it to Unknown (only see how to set to Active or Inactive).? Also, I see Delayed Set but that isn't what I want:? I want to check how long it has been in a certain state already and then set it to another state.? Can I do this?? Similarly, if the sensor is in the Inconsistent state for y seconds, I want to set it to Unknown.

I know how to do this with a script.? Trying to see if I can do it more easily (or at all) with LOGIX.


Thanks, Jerry
___________________________________
jerryg2003@...

Mike,

On 1 Aug 2019, at 12:22 AM, Mike Heintzman <mikeheintzman@...> wrote:

Running Windows 10 on both machines, data is shared on OneDrive. One thing I’ve noticed is that there are Roster.xml files in my older profiles (without the .jmri extension) and one of these (called no decoder) is usually what I open first to check the update. Might it be picking up this roster instead of where the real roster is? I’ve looked at the various Profile Configuration documents but I can’t tell if these roster files are supposed to be there or not.

- When JMRI opens, it looks for a "roster.xml" file in the "Roster Location" (refer Help->Locations). This purportedly contains an index of all ".xml" files in the "roster" folder at "Roster Location" and any attached image files.

- The "Roster Location" is usually the same as "User Files Location" and can be specific to every profile/machine or shared or any combination thereof.

- In earlier versions of JMRI, roster image files were stored in the "resources" folder in "User Files Location". Roster entries created by current JMRI versions copy the image files into the "roster" folder.

- Rebuild Roster Index writes a new "roster.xml" for the associated "roster" folder.

- If you've changed the "User Files Location"/"Roster Location" for all profiles/computers to OneDrive/Dropbox (as I have) there should be only one "roster.xml" file and "roster" folder being used by all your profiles. (There may be empty/unused copies in "Profile Location" from before you switched.)

- The presence or absence of a ".jmri" extension on a profile doesn't matter. For consistency's sake I added ".jmri" to all my old profile folder names, but there's no need to.

- The icon/image behaviour you are seeing may be because you have all/some images in a non-shared "resources" folder on some profiles/machines. This can be cured by making sure all profiles/machines are using a shared "User Files Location" (usually the same as "Roster Location") and putting the "resources" folder there (i.e. at the same level as the "roster" folder and "roster.xml".

<>
<>

Dave in Australia

On Wed, Jul 31, 2019 at 02:11 PM, Nigel wrote:

Hi Peter/Bob

Many thanks.

I have produced a worked example panel showing the problem and created an
issue on github and uploaded the panel with it.

Nigel

For those that want to follow along:
--
Peter Ulvestad

JMRI Users Group Moderator - ( )
Tam Valley Group Moderator - ( )
Sprog-DCC Group Moderator - ( )
Edmonton Model Railroad Association -

OK, this is strange.? I know stuff happens.? I put my engine(Walthers Proto GP-60) on an isolated programming track and started DP.? I went in and read CV 29 and lo and behold it was 2.. It was supposed to be 34.? So I changed it and the engine responded properly to its 4-digit address with both WiThrottle Lites and Digitrax DT-500 throttle.? Is possible that CV 29 spontaneously changed?? Yesterday I was running engine with WiThrottle Lite and the DT-500 when it quit responding to 4-digit address.? Is it possible the decoder(factory installed tsunami) is failng??
Thanks for any responses.
Bob

Hi Peter/Bob

Many thanks.

I have produced a worked example panel showing the problem and created an issue on github and uploaded the panel with it.

Nigel

Most of these responses are doing nothing to help the OPs problem. Please try and stick to the topic.


Nigel,

As Bob J. has suggested, create an issue in github and upload your panel for a developer to review.

--
Peter Ulvestad

JMRI Users Group Moderator - ( )
Tam Valley Group Moderator - ( )
Sprog-DCC Group Moderator - ( )
Edmonton Model Railroad Association -

I understood that error condition was defined by the poster as the "unknown" situation, not the the "inconsistent" situation. If the turnout doesn't have a known safe settling time, presumably defined in JMRI so as not to to act before the prior to acting required status is correctly settled, something has already gone wrong.

Andy


On 7/31/2019 7:38 AM, Bob Jacobsen wrote:

On Jul 31, 2019, at 7:20 AM, Andy Reichert<andy_r@...> wrote:

If JMRI needs to know that a turnout is an inconsistent (traversing) state, but doesn't also know the intended result, or the safe settling time to get there, there is something wrong with that logic.

If you always knew that the points are going to get to their commanded end point in a certain time, you wouldn’t need feedback hardware. People install feedback hardware (in part) to catch the case where the turnout is still in an inconsistent state after that “safe settling time”.

Bob
--
Bob Jacobsen
rgj1927@...

---
This email has been checked for viruses by AVG.

This is not prototypical, but it works and is fairly simple. When I have a configuration that requires multiple turnouts I arrange the feedback so that it is wired through all of the switch contacts. For instance, I have a three track staging yard on my layout. To get to track 3 in that yard, you only go through turnout 1 when it's normal, so I wire my common return (- in this case) to the common terminal on the Tortoise (the brand of switch motor I'm using for this). The terminal that closed in the normal position goes to input 3.

If the turnouts are lined for track 2, then turnout 1 is reverse and turnout 2 is reverse. The contact for turnout 1 reverse is connected to the common on turnout 2. Then the contact for turnout 2 reverse if connected to input 2. Similarly, the contact for turnout 2 normal is connected to input 1.

The logic is all taken care of in the turnout contacts. Therefore, I have three inputs, one for each track. When input x is active, I know that the ladder is lined for track x. Something similar could be applied to your crossover.

Tim Rumph
Lancaster, SC

开云体育

Nigel,

Since something like that Really Should Work, if you open a new Issue at GitHub ( ) and attach your panel file (might have to add .txt to the name) and instructions for how to recreate the problem, somebody will probably take a look at it pretty quickly.

Bob

On Jul 31, 2019, at 8:40 AM, Nigel <nigel@...> wrote:

Hi Dave

From what I think you are saying is that the feature of supported turnout (eg crossover) with full feedback does not actually work in JMRI.

Logically it could work if the code was sufficiently complicated but not in the current release.

Is there a development to address this ?

--
Bob Jacobsen
rgj1927@...

Hi Dave

From what I think you are saying is that the feature of supported turnout (eg crossover) with full feedback does not actually work in JMRI.

Logically it could work if the code was sufficiently complicated but not in the current release.

Is there a development to address this ?

Nigel

开云体育

Nigel,

On Jul 31, 2019, at 7:20 AM, Andy Reichert <andy_r@...> wrote:

If JMRI needs to know that a turnout is an inconsistent (traversing) state, but doesn't also know the intended result, or the safe settling time to get there, there is something wrong with that logic.

If you always knew that the points are going to get to their commanded end point in a certain time, you wouldn’t need feedback hardware. People install feedback hardware (in part) to catch the case where the turnout is still in an inconsistent state after that “safe settling time”.

Bob
--
Bob Jacobsen
rgj1927@...