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@...

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.

And a fixed diamond doesn't usually give intelligible feedback. But you need to know if the other path is selected or occupied. Especially in the case of a double junction.

Andy





On 7/31/2019 6:48 AM, Dave Roberts wrote:

Thanks for that Paul. I chose not to draw the distinction for simplicity but you are correct of course.
Dave

Sent from my iPhone - Dave

On 31 Jul 2019, at 14:10, Paul Bender <paul.bender@...> wrote:

Dave/Nigel,

On Jul 31, 2019, at 6:26 AM, Dave Roberts <dccdaveroberts@...> wrote:
A turnout actually has three states:
The two you are already familiar with - when the turnout is at either end of its travel - it’s Open or Closed position or Normal and Reversed. The third state is whilst the point is actually changing from one state to the other. This is the Unknown or Inconsistent state.

A minor point of correction, Unknown and Inconsistent are distinct states, so there are actually 4 states for JMRI turnouts.

Unknown means that we really don’t know what the state is. On a turnout with feedback, that generally means we have not received feedback from the feedback mechanism.

Inconsistent means the state is in transition, but hasn’t yet stabilized. On a turnout with a feedback sensor at both ends of travel, this means the feedback indicates the turnout is between the two endpoints.

Paul

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

Hi Dave

When you put a crossover on the layout you have the option of using two individual turnouts.
The first turnout system name goes in the first box.
If you tick the "supporting" turnout box the second turnout system name goes in the the second box.

Now if you do this with turnouts that have no feedback they work together properly.

But if you do it with turnouts that have feedback they do not work properly.

Nigel

I’ve noticed something odd after installing these last two upgrades. After the installation is complete I open DecoderPro and all of the icon images are blank. If I do a Rebuild Roster it brings them all back. It does this in both DP and when accessing the Roster through PanelPro.
?I’ve checked the session logs and message logs and everything appears to be starting normally. I looked at the roster.xml prior to doing the Rebuild and the code for pointing to the image file locations are blank.
This does this on both my laptop and desktop. It doesn’t seem to matter which I update first.
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.
Thanks.
--
Mike Heintzman

Hey Jason,

That sounds great ...

Here is the URL for Steve Todd's site ...?

You should find all you need on his RPi JMRI image. If you have an extra micro SD card available, you might burn his image and see what he has done. I know Steve is very busy with a real job, in addition to his work on model railroading. If you were not aware, he is the author of the Engine Driver app for Android phones/tablets that connects to the JMRI WiThrottle server.

Thanks again for your help,

Richard