Date   

Re: Turnout feedback

RadSolution
 

Emmanuel,

Understood, but you might still have 2 issues:
1. Unless the required turnout setting is read from eeprom and the turnout moved to that location it could lie the wrong way if moved manually whist power is off, and
2. Even if you do that, JMRI still won’t necessarily know the lie of the point, so will show it as ‘unknown’.

Dave


On 18 Jul 2020, at 07:38, emmanuel ALLAUD <eallaud@...> wrote:

Hi,
The save in eeprom is only for outputs and turnouts. For inputs they will be read on startup and reported when jmri connects. 
Manu

Le sam. 18 juil. 2020 à 00:42, RadSolution via groups.io <radsolution=yahoo.co.uk@groups.io> a écrit :
“Every arduino keeps the last turnout pos in eeprom” - which is great in a world where a big glass fish-tank lowers over the layout as it powers-down...
In the real world, people change turnouts, and add/remove stock over track detectors whilst the power is off....
How will your eeprom data cope with that?

That’s why you need SoD interrogation....


On 17 Jul 2020, at 23:18, emmanuel ALLAUD <eallaud@...> wrote:

Sorry just one more thing: in jmri I guess what I understand as "output sensor" is represented by a turnout?

Thanks,

Manu

Le 18/07/20 à 00:14, emmanuel ALLAUD via groups.io a écrit :

Just to give back a bit:

Every arduino keeps the last turnout pos in eeprom and when it starts and it is asked to read its eeprom, all turnouts are moved (fast, not the slow paced movt for normal operations) and then when they reached their pos they send their position. So in my case that means jmri will get its "event" and then states will be coherent between hard and software.

For sensors its different: for an input sensor I will have to read them all and send their state to jmri. For output sensors (turnouts are different as they are supposed to control servos) I will have to send their state saved in eeprom (they are put back to this state on startup when the config is loaded from the eeprom as for the turnouts).

That will need a lot of messages but it is a RS485 with one controller node, so it will take time but no reason (normally) to loose some of them.

Some more work then...

Manu

Le 17/07/20 à 20:15, wombat_rrnut a écrit :

FYI:

 

Init Sensors and CTC:

CTC Logic (the recent one) always assumes the worst case (fail safe) when not ACTIVE or INACTIVE.

For instance, if I’m trying to clear a route, it won’t clear.  I can’t think that I missed one or more,

but there may be “errors” of state I don’t process properly.  Won’t crash, just not “fail safe”.

(Well, no one dies, just grave site markers by the main line!) :-) :-) :-)

 

Regarding Big Layouts:

Mine is 2800’ sq ft., full CTC, 30 operators.  Using LocoNet.  Had to split LocoNet into two functions,

(two wires): Throttle (throttles, track), and Signals (Sensors, Turnout drivers, Signals).  When

JMRI starts up, the blast is big even if in 1/8’s at a time (JMRI / Digitrax design).

And while running, I have .py software to repeat a signal indication change to the field

once a second for 5 seconds.  LCC should get rid of this problem…. Someday…..

 

Greg

 

 

From: jmri@jmri-developers.groups.io [mailto:jmri@jmri-developers.groups.io] On Behalf Of Balazs Racz
Sent: Friday, July 17, 2020 12:05 PM
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] Turnout feedback

 

Unknown is a correctly supported state for JMRI Sensors, but if the user went to the length of configuring feedback with sensors, then having those sensors be in an Unknown state is arguably not very useful to the user.

For example turnout feedback or sensors in general might be watched by CTC logic. THat logic will not really know what to do if the sensors say unknown.

 

Therefore my suggestion would be to just read the state upon startup and not worry too much about the number of messages this takes. Make the reading as fast as possible. Through my interaction with large layout owners the feedback I've been getting is that they would like the state to be as consistent as possible between JMRI and reality. This is how they can ensure that the business logic functions correctly.

 

On Fri, Jul 17, 2020 at 6:23 PM emmanuel ALLAUD <eallaud@...> wrote:

Thanks for your answers.

Just to precise things: the hardware I want to connect jmri to is arduino based and has the ability to tell when the turnout is in the requested position and also can be queried for the turnout position if needed.

I will connect this through a jython script (the protocol I am using is not known to jmri).

So if I dont send "events" to tell jmri about the turnouts position or the sensors state, they will stay in "unknown" until jmri gets a state for my hardware or, in the case of turnouts if there is commanded state, right?

Any problem you can think of that this situation could create?

I have the solution to send all states on startup, it might create a storm of events though for big layouts.

Bye

Manu

Le 17/07/20 à 11:38, Balazs Racz a écrit :

There is a hidden possibility to make JMRI request the state of the sensor. You have to enable the state query actions checkbox in the bottom of the sensor table. Then you will have a button to press that will make JMRI trigger the hardware specific implementation to request the state. (Internal sensors don't have such an implementation of course as no hardware is behind them.)

However, the expectation is that the sensor implementation will automatically request the state once during startup, and from then on when the sensor changes an incoming message from the control bus will trigger the sensor to update its state and JMRI's listeners. So generally a "sensor.query" is not something that people run in a typical session ever -- this is why the buttons are hidden by default.

 

Balazs 

 

On Fri, Jul 17, 2020 at 11:23 AM Randall Wood via groups.io <rhwood=mac.com@groups.io> wrote:



> On 17-Jul-2020, at 05:10, emmanuel ALLAUD <eallaud@...> wrote:
>
> Hi all,
>
> a simple question: does jmri ever request the state of a sensor? Same for turnout with feedback?

JMRI requests the state of a sensor if the connection protocol (e.g. LocoNet, CMRI, OpenLCB…) allows it. The same is true for turnout feedback.

Internal sensors do not request state, but typical these are connected to buttons on panels or other scripted logic that sets the state as appropriate.

> I have the impression that if there is a sensor set up in jmri, it will be in "unknown state" until it gets the information from whereever it is supposed to come from.

That is correct.

> TIA
>
> Manu
>
>
>
>




Re: Turnout feedback

emmanuel ALLAUD
 

Hi,
The save in eeprom is only for outputs and turnouts. For inputs they will be read on startup and reported when jmri connects. 
Manu

Le sam. 18 juil. 2020 à 00:42, RadSolution via groups.io <radsolution=yahoo.co.uk@groups.io> a écrit :
“Every arduino keeps the last turnout pos in eeprom” - which is great in a world where a big glass fish-tank lowers over the layout as it powers-down...
In the real world, people change turnouts, and add/remove stock over track detectors whilst the power is off....
How will your eeprom data cope with that?

That’s why you need SoD interrogation....


On 17 Jul 2020, at 23:18, emmanuel ALLAUD <eallaud@...> wrote:

Sorry just one more thing: in jmri I guess what I understand as "output sensor" is represented by a turnout?

Thanks,

Manu

Le 18/07/20 à 00:14, emmanuel ALLAUD via groups.io a écrit :

Just to give back a bit:

Every arduino keeps the last turnout pos in eeprom and when it starts and it is asked to read its eeprom, all turnouts are moved (fast, not the slow paced movt for normal operations) and then when they reached their pos they send their position. So in my case that means jmri will get its "event" and then states will be coherent between hard and software.

For sensors its different: for an input sensor I will have to read them all and send their state to jmri. For output sensors (turnouts are different as they are supposed to control servos) I will have to send their state saved in eeprom (they are put back to this state on startup when the config is loaded from the eeprom as for the turnouts).

That will need a lot of messages but it is a RS485 with one controller node, so it will take time but no reason (normally) to loose some of them.

Some more work then...

Manu

Le 17/07/20 à 20:15, wombat_rrnut a écrit :

FYI:

 

Init Sensors and CTC:

CTC Logic (the recent one) always assumes the worst case (fail safe) when not ACTIVE or INACTIVE.

For instance, if I’m trying to clear a route, it won’t clear.  I can’t think that I missed one or more,

but there may be “errors” of state I don’t process properly.  Won’t crash, just not “fail safe”.

(Well, no one dies, just grave site markers by the main line!) :-) :-) :-)

 

Regarding Big Layouts:

Mine is 2800’ sq ft., full CTC, 30 operators.  Using LocoNet.  Had to split LocoNet into two functions,

(two wires): Throttle (throttles, track), and Signals (Sensors, Turnout drivers, Signals).  When

JMRI starts up, the blast is big even if in 1/8’s at a time (JMRI / Digitrax design).

And while running, I have .py software to repeat a signal indication change to the field

once a second for 5 seconds.  LCC should get rid of this problem…. Someday…..

 

Greg

 

 

From: jmri@jmri-developers.groups.io [mailto:jmri@jmri-developers.groups.io] On Behalf Of Balazs Racz
Sent: Friday, July 17, 2020 12:05 PM
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] Turnout feedback

 

Unknown is a correctly supported state for JMRI Sensors, but if the user went to the length of configuring feedback with sensors, then having those sensors be in an Unknown state is arguably not very useful to the user.

For example turnout feedback or sensors in general might be watched by CTC logic. THat logic will not really know what to do if the sensors say unknown.

 

Therefore my suggestion would be to just read the state upon startup and not worry too much about the number of messages this takes. Make the reading as fast as possible. Through my interaction with large layout owners the feedback I've been getting is that they would like the state to be as consistent as possible between JMRI and reality. This is how they can ensure that the business logic functions correctly.

 

On Fri, Jul 17, 2020 at 6:23 PM emmanuel ALLAUD <eallaud@...> wrote:

Thanks for your answers.

Just to precise things: the hardware I want to connect jmri to is arduino based and has the ability to tell when the turnout is in the requested position and also can be queried for the turnout position if needed.

I will connect this through a jython script (the protocol I am using is not known to jmri).

So if I dont send "events" to tell jmri about the turnouts position or the sensors state, they will stay in "unknown" until jmri gets a state for my hardware or, in the case of turnouts if there is commanded state, right?

Any problem you can think of that this situation could create?

I have the solution to send all states on startup, it might create a storm of events though for big layouts.

Bye

Manu

Le 17/07/20 à 11:38, Balazs Racz a écrit :

There is a hidden possibility to make JMRI request the state of the sensor. You have to enable the state query actions checkbox in the bottom of the sensor table. Then you will have a button to press that will make JMRI trigger the hardware specific implementation to request the state. (Internal sensors don't have such an implementation of course as no hardware is behind them.)

However, the expectation is that the sensor implementation will automatically request the state once during startup, and from then on when the sensor changes an incoming message from the control bus will trigger the sensor to update its state and JMRI's listeners. So generally a "sensor.query" is not something that people run in a typical session ever -- this is why the buttons are hidden by default.

 

Balazs 

 

On Fri, Jul 17, 2020 at 11:23 AM Randall Wood via groups.io <rhwood=mac.com@groups.io> wrote:



> On 17-Jul-2020, at 05:10, emmanuel ALLAUD <eallaud@...> wrote:
>
> Hi all,
>
> a simple question: does jmri ever request the state of a sensor? Same for turnout with feedback?

JMRI requests the state of a sensor if the connection protocol (e.g. LocoNet, CMRI, OpenLCB…) allows it. The same is true for turnout feedback.

Internal sensors do not request state, but typical these are connected to buttons on panels or other scripted logic that sets the state as appropriate.

> I have the impression that if there is a sensor set up in jmri, it will be in "unknown state" until it gets the information from whereever it is supposed to come from.

That is correct.

> TIA
>
> Manu
>
>
>
>




Re: Problem with Windows 10 and NetBeans 112, won't install

Steve_G
 

not sure how I did it, as I recall I didnt have to do anything special, but got
this setup. Netbeans 11.3
and java 11 from OpenJDK11U-jdk_x64_windows_hotspot_11.0.6_10.exe
Product Version: Apache NetBeans IDE 11.3
Java: 11.0.6; OpenJDK 64-Bit Server VM 11.0.6+10
Runtime: OpenJDK Runtime Environment 11.0.6+10
System: Windows 10 version 10.0 running on amd64; Cp1252; en_CA (nb)

Steve G.


Re: Problem with Windows 10 and NetBeans 112, won't install

danielb987
 

I don't know, but I would try to uninstall OpenJDK and then try to download and install JDK from this page:

https://www.oracle.com/java/technologies/javase-jdk11-downloads.html

Daniel

2020-07-18 02:38 skrev wombat_rrnut:

All:
I recently installed on a Windows 7 system:
OpenJDK11U-jdk_x64_windows_hotspot_11.0.7_10.msi
Followed directly by:
Apache-NetBeans-11.2-bin-windows-x64.exe
No problem.
Just got a Windows 10 system, have the EXACT same 2 install files on
it.
Installed no problem:
OpenJDK11U-jdk_x64_windows_hotspot_11.0.7_10.msi
Then
Apache-NetBeans-11.2-bin-windows-x64.exe
Get the following error (see attached .jpg)
Issue Java from command prompt, no problem, so Javahome set properly.
Tried Apache-NetBeans-11.2.-bin-windows-x64 -javahome C:\Program
Files\AdoptOpenJDK\jdk-11.0.7.10-hotspot\bin
(per screen instruction)
That didn't work either.
What gives?
Greg
Links:
------
[1] https://jmri-developers.groups.io/g/jmri/message/3932
[2] https://groups.io/mt/75624566/1303822
[3] https://jmri-developers.groups.io/g/jmri/post
[4] https://jmri-developers.groups.io/g/jmri/editsub/1303822
[5] https://jmri-developers.groups.io/g/jmri/leave/defanged


Problem with Windows 10 and NetBeans 112, won't install

wombat_rrnut
 

All:

 

I recently installed on a Windows 7 system:

OpenJDK11U-jdk_x64_windows_hotspot_11.0.7_10.msi

Followed directly by:

Apache-NetBeans-11.2-bin-windows-x64.exe

 

No problem.

 

Just got a Windows 10 system, have the EXACT same 2 install files on it.

Installed no problem:

OpenJDK11U-jdk_x64_windows_hotspot_11.0.7_10.msi

Then

Apache-NetBeans-11.2-bin-windows-x64.exe

Get the following error (see attached .jpg)

 

Issue Java from command prompt, no problem, so Javahome set properly.

 

Tried Apache-NetBeans-11.2.-bin-windows-x64 –javahome C:\Program Files\AdoptOpenJDK\jdk-11.0.7.10-hotspot\bin

(per screen instruction)

 

That didn’t work either.

 

What gives?

 

Greg

 

 

 

 


Re: Turnout feedback

RadSolution
 

“Every arduino keeps the last turnout pos in eeprom” - which is great in a world where a big glass fish-tank lowers over the layout as it powers-down...
In the real world, people change turnouts, and add/remove stock over track detectors whilst the power is off....
How will your eeprom data cope with that?

That’s why you need SoD interrogation....


On 17 Jul 2020, at 23:18, emmanuel ALLAUD <eallaud@...> wrote:

Sorry just one more thing: in jmri I guess what I understand as "output sensor" is represented by a turnout?

Thanks,

Manu

Le 18/07/20 à 00:14, emmanuel ALLAUD via groups.io a écrit :

Just to give back a bit:

Every arduino keeps the last turnout pos in eeprom and when it starts and it is asked to read its eeprom, all turnouts are moved (fast, not the slow paced movt for normal operations) and then when they reached their pos they send their position. So in my case that means jmri will get its "event" and then states will be coherent between hard and software.

For sensors its different: for an input sensor I will have to read them all and send their state to jmri. For output sensors (turnouts are different as they are supposed to control servos) I will have to send their state saved in eeprom (they are put back to this state on startup when the config is loaded from the eeprom as for the turnouts).

That will need a lot of messages but it is a RS485 with one controller node, so it will take time but no reason (normally) to loose some of them.

Some more work then...

Manu

Le 17/07/20 à 20:15, wombat_rrnut a écrit :

FYI:

 

Init Sensors and CTC:

CTC Logic (the recent one) always assumes the worst case (fail safe) when not ACTIVE or INACTIVE.

For instance, if I’m trying to clear a route, it won’t clear.  I can’t think that I missed one or more,

but there may be “errors” of state I don’t process properly.  Won’t crash, just not “fail safe”.

(Well, no one dies, just grave site markers by the main line!) :-) :-) :-)

 

Regarding Big Layouts:

Mine is 2800’ sq ft., full CTC, 30 operators.  Using LocoNet.  Had to split LocoNet into two functions,

(two wires): Throttle (throttles, track), and Signals (Sensors, Turnout drivers, Signals).  When

JMRI starts up, the blast is big even if in 1/8’s at a time (JMRI / Digitrax design).

And while running, I have .py software to repeat a signal indication change to the field

once a second for 5 seconds.  LCC should get rid of this problem…. Someday…..

 

Greg

 

 

From: jmri@jmri-developers.groups.io [mailto:jmri@jmri-developers.groups.io] On Behalf Of Balazs Racz
Sent: Friday, July 17, 2020 12:05 PM
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] Turnout feedback

 

Unknown is a correctly supported state for JMRI Sensors, but if the user went to the length of configuring feedback with sensors, then having those sensors be in an Unknown state is arguably not very useful to the user.

For example turnout feedback or sensors in general might be watched by CTC logic. THat logic will not really know what to do if the sensors say unknown.

 

Therefore my suggestion would be to just read the state upon startup and not worry too much about the number of messages this takes. Make the reading as fast as possible. Through my interaction with large layout owners the feedback I've been getting is that they would like the state to be as consistent as possible between JMRI and reality. This is how they can ensure that the business logic functions correctly.

 

On Fri, Jul 17, 2020 at 6:23 PM emmanuel ALLAUD <eallaud@...> wrote:

Thanks for your answers.

Just to precise things: the hardware I want to connect jmri to is arduino based and has the ability to tell when the turnout is in the requested position and also can be queried for the turnout position if needed.

I will connect this through a jython script (the protocol I am using is not known to jmri).

So if I dont send "events" to tell jmri about the turnouts position or the sensors state, they will stay in "unknown" until jmri gets a state for my hardware or, in the case of turnouts if there is commanded state, right?

Any problem you can think of that this situation could create?

I have the solution to send all states on startup, it might create a storm of events though for big layouts.

Bye

Manu

Le 17/07/20 à 11:38, Balazs Racz a écrit :

There is a hidden possibility to make JMRI request the state of the sensor. You have to enable the state query actions checkbox in the bottom of the sensor table. Then you will have a button to press that will make JMRI trigger the hardware specific implementation to request the state. (Internal sensors don't have such an implementation of course as no hardware is behind them.)

However, the expectation is that the sensor implementation will automatically request the state once during startup, and from then on when the sensor changes an incoming message from the control bus will trigger the sensor to update its state and JMRI's listeners. So generally a "sensor.query" is not something that people run in a typical session ever -- this is why the buttons are hidden by default.

 

Balazs 

 

On Fri, Jul 17, 2020 at 11:23 AM Randall Wood via groups.io <rhwood=mac.com@groups.io> wrote:



> On 17-Jul-2020, at 05:10, emmanuel ALLAUD <eallaud@...> wrote:
>
> Hi all,
>
> a simple question: does jmri ever request the state of a sensor? Same for turnout with feedback?

JMRI requests the state of a sensor if the connection protocol (e.g. LocoNet, CMRI, OpenLCB…) allows it. The same is true for turnout feedback.

Internal sensors do not request state, but typical these are connected to buttons on panels or other scripted logic that sets the state as appropriate.

> I have the impression that if there is a sensor set up in jmri, it will be in "unknown state" until it gets the information from whereever it is supposed to come from.

That is correct.

> TIA
>
> Manu
>
>
>
>




Re: Turnout feedback

emmanuel ALLAUD
 

Sorry just one more thing: in jmri I guess what I understand as "output sensor" is represented by a turnout?

Thanks,

Manu

Le 18/07/20 à 00:14, emmanuel ALLAUD via groups.io a écrit :

Just to give back a bit:

Every arduino keeps the last turnout pos in eeprom and when it starts and it is asked to read its eeprom, all turnouts are moved (fast, not the slow paced movt for normal operations) and then when they reached their pos they send their position. So in my case that means jmri will get its "event" and then states will be coherent between hard and software.

For sensors its different: for an input sensor I will have to read them all and send their state to jmri. For output sensors (turnouts are different as they are supposed to control servos) I will have to send their state saved in eeprom (they are put back to this state on startup when the config is loaded from the eeprom as for the turnouts).

That will need a lot of messages but it is a RS485 with one controller node, so it will take time but no reason (normally) to loose some of them.

Some more work then...

Manu

Le 17/07/20 à 20:15, wombat_rrnut a écrit :

FYI:

 

Init Sensors and CTC:

CTC Logic (the recent one) always assumes the worst case (fail safe) when not ACTIVE or INACTIVE.

For instance, if I’m trying to clear a route, it won’t clear.  I can’t think that I missed one or more,

but there may be “errors” of state I don’t process properly.  Won’t crash, just not “fail safe”.

(Well, no one dies, just grave site markers by the main line!) :-) :-) :-)

 

Regarding Big Layouts:

Mine is 2800’ sq ft., full CTC, 30 operators.  Using LocoNet.  Had to split LocoNet into two functions,

(two wires): Throttle (throttles, track), and Signals (Sensors, Turnout drivers, Signals).  When

JMRI starts up, the blast is big even if in 1/8’s at a time (JMRI / Digitrax design).

And while running, I have .py software to repeat a signal indication change to the field

once a second for 5 seconds.  LCC should get rid of this problem…. Someday…..

 

Greg

 

 

From: jmri@jmri-developers.groups.io [mailto:jmri@jmri-developers.groups.io] On Behalf Of Balazs Racz
Sent: Friday, July 17, 2020 12:05 PM
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] Turnout feedback

 

Unknown is a correctly supported state for JMRI Sensors, but if the user went to the length of configuring feedback with sensors, then having those sensors be in an Unknown state is arguably not very useful to the user.

For example turnout feedback or sensors in general might be watched by CTC logic. THat logic will not really know what to do if the sensors say unknown.

 

Therefore my suggestion would be to just read the state upon startup and not worry too much about the number of messages this takes. Make the reading as fast as possible. Through my interaction with large layout owners the feedback I've been getting is that they would like the state to be as consistent as possible between JMRI and reality. This is how they can ensure that the business logic functions correctly.

 

On Fri, Jul 17, 2020 at 6:23 PM emmanuel ALLAUD <eallaud@...> wrote:

Thanks for your answers.

Just to precise things: the hardware I want to connect jmri to is arduino based and has the ability to tell when the turnout is in the requested position and also can be queried for the turnout position if needed.

I will connect this through a jython script (the protocol I am using is not known to jmri).

So if I dont send "events" to tell jmri about the turnouts position or the sensors state, they will stay in "unknown" until jmri gets a state for my hardware or, in the case of turnouts if there is commanded state, right?

Any problem you can think of that this situation could create?

I have the solution to send all states on startup, it might create a storm of events though for big layouts.

Bye

Manu

Le 17/07/20 à 11:38, Balazs Racz a écrit :

There is a hidden possibility to make JMRI request the state of the sensor. You have to enable the state query actions checkbox in the bottom of the sensor table. Then you will have a button to press that will make JMRI trigger the hardware specific implementation to request the state. (Internal sensors don't have such an implementation of course as no hardware is behind them.)

However, the expectation is that the sensor implementation will automatically request the state once during startup, and from then on when the sensor changes an incoming message from the control bus will trigger the sensor to update its state and JMRI's listeners. So generally a "sensor.query" is not something that people run in a typical session ever -- this is why the buttons are hidden by default.

 

Balazs 

 

On Fri, Jul 17, 2020 at 11:23 AM Randall Wood via groups.io <rhwood=mac.com@groups.io> wrote:



> On 17-Jul-2020, at 05:10, emmanuel ALLAUD <eallaud@...> wrote:
>
> Hi all,
>
> a simple question: does jmri ever request the state of a sensor? Same for turnout with feedback?

JMRI requests the state of a sensor if the connection protocol (e.g. LocoNet, CMRI, OpenLCB…) allows it. The same is true for turnout feedback.

Internal sensors do not request state, but typical these are connected to buttons on panels or other scripted logic that sets the state as appropriate.

> I have the impression that if there is a sensor set up in jmri, it will be in "unknown state" until it gets the information from whereever it is supposed to come from.

That is correct.

> TIA
>
> Manu
>
>
>
>




Re: Turnout feedback

emmanuel ALLAUD
 

Just to give back a bit:

Every arduino keeps the last turnout pos in eeprom and when it starts and it is asked to read its eeprom, all turnouts are moved (fast, not the slow paced movt for normal operations) and then when they reached their pos they send their position. So in my case that means jmri will get its "event" and then states will be coherent between hard and software.

For sensors its different: for an input sensor I will have to read them all and send their state to jmri. For output sensors (turnouts are different as they are supposed to control servos) I will have to send their state saved in eeprom (they are put back to this state on startup when the config is loaded from the eeprom as for the turnouts).

That will need a lot of messages but it is a RS485 with one controller node, so it will take time but no reason (normally) to loose some of them.

Some more work then...

Manu

Le 17/07/20 à 20:15, wombat_rrnut a écrit :

FYI:

 

Init Sensors and CTC:

CTC Logic (the recent one) always assumes the worst case (fail safe) when not ACTIVE or INACTIVE.

For instance, if I’m trying to clear a route, it won’t clear.  I can’t think that I missed one or more,

but there may be “errors” of state I don’t process properly.  Won’t crash, just not “fail safe”.

(Well, no one dies, just grave site markers by the main line!) :-) :-) :-)

 

Regarding Big Layouts:

Mine is 2800’ sq ft., full CTC, 30 operators.  Using LocoNet.  Had to split LocoNet into two functions,

(two wires): Throttle (throttles, track), and Signals (Sensors, Turnout drivers, Signals).  When

JMRI starts up, the blast is big even if in 1/8’s at a time (JMRI / Digitrax design).

And while running, I have .py software to repeat a signal indication change to the field

once a second for 5 seconds.  LCC should get rid of this problem…. Someday…..

 

Greg

 

 

From: jmri@jmri-developers.groups.io [mailto:jmri@jmri-developers.groups.io] On Behalf Of Balazs Racz
Sent: Friday, July 17, 2020 12:05 PM
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] Turnout feedback

 

Unknown is a correctly supported state for JMRI Sensors, but if the user went to the length of configuring feedback with sensors, then having those sensors be in an Unknown state is arguably not very useful to the user.

For example turnout feedback or sensors in general might be watched by CTC logic. THat logic will not really know what to do if the sensors say unknown.

 

Therefore my suggestion would be to just read the state upon startup and not worry too much about the number of messages this takes. Make the reading as fast as possible. Through my interaction with large layout owners the feedback I've been getting is that they would like the state to be as consistent as possible between JMRI and reality. This is how they can ensure that the business logic functions correctly.

 

On Fri, Jul 17, 2020 at 6:23 PM emmanuel ALLAUD <eallaud@...> wrote:

Thanks for your answers.

Just to precise things: the hardware I want to connect jmri to is arduino based and has the ability to tell when the turnout is in the requested position and also can be queried for the turnout position if needed.

I will connect this through a jython script (the protocol I am using is not known to jmri).

So if I dont send "events" to tell jmri about the turnouts position or the sensors state, they will stay in "unknown" until jmri gets a state for my hardware or, in the case of turnouts if there is commanded state, right?

Any problem you can think of that this situation could create?

I have the solution to send all states on startup, it might create a storm of events though for big layouts.

Bye

Manu

Le 17/07/20 à 11:38, Balazs Racz a écrit :

There is a hidden possibility to make JMRI request the state of the sensor. You have to enable the state query actions checkbox in the bottom of the sensor table. Then you will have a button to press that will make JMRI trigger the hardware specific implementation to request the state. (Internal sensors don't have such an implementation of course as no hardware is behind them.)

However, the expectation is that the sensor implementation will automatically request the state once during startup, and from then on when the sensor changes an incoming message from the control bus will trigger the sensor to update its state and JMRI's listeners. So generally a "sensor.query" is not something that people run in a typical session ever -- this is why the buttons are hidden by default.

 

Balazs 

 

On Fri, Jul 17, 2020 at 11:23 AM Randall Wood via groups.io <rhwood=mac.com@groups.io> wrote:



> On 17-Jul-2020, at 05:10, emmanuel ALLAUD <eallaud@...> wrote:
>
> Hi all,
>
> a simple question: does jmri ever request the state of a sensor? Same for turnout with feedback?

JMRI requests the state of a sensor if the connection protocol (e.g. LocoNet, CMRI, OpenLCB…) allows it. The same is true for turnout feedback.

Internal sensors do not request state, but typical these are connected to buttons on panels or other scripted logic that sets the state as appropriate.

> I have the impression that if there is a sensor set up in jmri, it will be in "unknown state" until it gets the information from whereever it is supposed to come from.

That is correct.

> TIA
>
> Manu
>
>
>
>




Re: Turnout feedback

Ken Cameron
 

Greg,

Yes the same type of surge happens on LCC when all the signal nodes fire up.
But the network supports 100% utilization and they all figure it out and it
calms down after 5 or 10 seconds.

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


Re: Configuring Feedback Breaks DCC++ Output #sensors #arduino #turnouts #dccpp

robteed
 

If anyone can shed some light on this it would be greatly appreciated. I’m kind of beta testing this system and this is the only bottleneck he has run into.


Re: Turnout feedback

wombat_rrnut
 

FYI:

 

Init Sensors and CTC:

CTC Logic (the recent one) always assumes the worst case (fail safe) when not ACTIVE or INACTIVE.

For instance, if I’m trying to clear a route, it won’t clear.  I can’t think that I missed one or more,

but there may be “errors” of state I don’t process properly.  Won’t crash, just not “fail safe”.

(Well, no one dies, just grave site markers by the main line!) :-) :-) :-)

 

Regarding Big Layouts:

Mine is 2800’ sq ft., full CTC, 30 operators.  Using LocoNet.  Had to split LocoNet into two functions,

(two wires): Throttle (throttles, track), and Signals (Sensors, Turnout drivers, Signals).  When

JMRI starts up, the blast is big even if in 1/8’s at a time (JMRI / Digitrax design).

And while running, I have .py software to repeat a signal indication change to the field

once a second for 5 seconds.  LCC should get rid of this problem…. Someday…..

 

Greg

 

 

From: jmri@jmri-developers.groups.io [mailto:jmri@jmri-developers.groups.io] On Behalf Of Balazs Racz
Sent: Friday, July 17, 2020 12:05 PM
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] Turnout feedback

 

Unknown is a correctly supported state for JMRI Sensors, but if the user went to the length of configuring feedback with sensors, then having those sensors be in an Unknown state is arguably not very useful to the user.

For example turnout feedback or sensors in general might be watched by CTC logic. THat logic will not really know what to do if the sensors say unknown.

 

Therefore my suggestion would be to just read the state upon startup and not worry too much about the number of messages this takes. Make the reading as fast as possible. Through my interaction with large layout owners the feedback I've been getting is that they would like the state to be as consistent as possible between JMRI and reality. This is how they can ensure that the business logic functions correctly.

 

On Fri, Jul 17, 2020 at 6:23 PM emmanuel ALLAUD <eallaud@...> wrote:

Thanks for your answers.

Just to precise things: the hardware I want to connect jmri to is arduino based and has the ability to tell when the turnout is in the requested position and also can be queried for the turnout position if needed.

I will connect this through a jython script (the protocol I am using is not known to jmri).

So if I dont send "events" to tell jmri about the turnouts position or the sensors state, they will stay in "unknown" until jmri gets a state for my hardware or, in the case of turnouts if there is commanded state, right?

Any problem you can think of that this situation could create?

I have the solution to send all states on startup, it might create a storm of events though for big layouts.

Bye

Manu

Le 17/07/20 à 11:38, Balazs Racz a écrit :

There is a hidden possibility to make JMRI request the state of the sensor. You have to enable the state query actions checkbox in the bottom of the sensor table. Then you will have a button to press that will make JMRI trigger the hardware specific implementation to request the state. (Internal sensors don't have such an implementation of course as no hardware is behind them.)

However, the expectation is that the sensor implementation will automatically request the state once during startup, and from then on when the sensor changes an incoming message from the control bus will trigger the sensor to update its state and JMRI's listeners. So generally a "sensor.query" is not something that people run in a typical session ever -- this is why the buttons are hidden by default.

 

Balazs 

 

On Fri, Jul 17, 2020 at 11:23 AM Randall Wood via groups.io <rhwood=mac.com@groups.io> wrote:



> On 17-Jul-2020, at 05:10, emmanuel ALLAUD <eallaud@...> wrote:
>
> Hi all,
>
> a simple question: does jmri ever request the state of a sensor? Same for turnout with feedback?

JMRI requests the state of a sensor if the connection protocol (e.g. LocoNet, CMRI, OpenLCB…) allows it. The same is true for turnout feedback.

Internal sensors do not request state, but typical these are connected to buttons on panels or other scripted logic that sets the state as appropriate.

> I have the impression that if there is a sensor set up in jmri, it will be in "unknown state" until it gets the information from whereever it is supposed to come from.

That is correct.

> TIA
>
> Manu
>
>
>
>




Re: Turnout feedback

Ken Cameron
 

The advantage of current logic is that unknown for a turnout or block state
is treated the same as occupied, so signals will protect the item with stop
signals. That's the safe option of only treating things you know as ok as
being ok. This follows the prototype practice, at least in the US and
Canada. If you don't know it as being ok, then treat it the same as knowing
it is not ok.

So Balazs, the current CTC or other logic in JMRI knows exactly what to do
with unknowns, if correctly programmed.

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


Re: Turnout feedback

emmanuel ALLAUD
 

Hi Bob,
I'm in the b) case. I will just send sensors state and turnouts feedback when jmri connects.
Thanks to you all,
Manu

Le ven. 17 juil. 2020 à 19:42, Bob M. <jawhugrps@...> a écrit :
Manu,

You've received a bunch of different information in response to your question.  The key point here is that different systems handle things differently. 

So, from your standpoint, the following things apply:

a) is _your_ implementation based on some other implementation?  If so, your implementation lives within the constraints of that implementation.
b) is _your_ implementation "your own"?  If so, then "You can do whatever you want".
c) Does your Arduino implementation act as a DCC accessory decoder, controlled by the DCC track signal?

As an example of point a), if you are implementing your Arduino as a "LocoNet device", then the _only_ way that LocoNet specifies for requesting information from LocoNet sensors is via a response to the "interrogate" messages.  At start-up, JMRI issues the "interrogate" messages.  For large LocoNet-based railroads, this interrogate operation typically causes a HUGE storm of LocoNet activity.  And, due to the vagaries of LocoNet, its spec, and the way various LocoNet devices respond to the "interrogate" messages, it can result in "missed" sensor messages.

As an example of point b), if you are connecting your Arduino via USB cable to the computer, you can implement whatever communication protocol between the computer and Arduino that you want to.  You can implement a specific query operation message, to be sent by the computer, and you can implement a message that the Arduino passes back to the computer over USB.

If you are starting from point c), you will be challenged if you intend to send your turnout position "feedback" back to the computer via the DCC track signal.  But there isn't any practical way to send data back from a stationary decoder via the DCC track signal (except on the service-mode programming track).  If you follow Digitrax' lead, their stationary decoders can sense any of 8 specific turnout control packets on the DCC track signal, and they can respond with feedback information via LocoNet.  You could do something similar, within the constraints of whatever communication link(s) you have between the Arduino and the computer.

Regards,
Billybob






Re: Turnout feedback

Bob M.
 

Manu,

You've received a bunch of different information in response to your question. The key point here is that different systems handle things differently.

So, from your standpoint, the following things apply:

a) is _your_ implementation based on some other implementation? If so, your implementation lives within the constraints of that implementation.
b) is _your_ implementation "your own"? If so, then "You can do whatever you want".
c) Does your Arduino implementation act as a DCC accessory decoder, controlled by the DCC track signal?

As an example of point a), if you are implementing your Arduino as a "LocoNet device", then the _only_ way that LocoNet specifies for requesting information from LocoNet sensors is via a response to the "interrogate" messages. At start-up, JMRI issues the "interrogate" messages. For large LocoNet-based railroads, this interrogate operation typically causes a HUGE storm of LocoNet activity. And, due to the vagaries of LocoNet, its spec, and the way various LocoNet devices respond to the "interrogate" messages, it can result in "missed" sensor messages.

As an example of point b), if you are connecting your Arduino via USB cable to the computer, you can implement whatever communication protocol between the computer and Arduino that you want to. You can implement a specific query operation message, to be sent by the computer, and you can implement a message that the Arduino passes back to the computer over USB.

If you are starting from point c), you will be challenged if you intend to send your turnout position "feedback" back to the computer via the DCC track signal. But there isn't any practical way to send data back from a stationary decoder via the DCC track signal (except on the service-mode programming track). If you follow Digitrax' lead, their stationary decoders can sense any of 8 specific turnout control packets on the DCC track signal, and they can respond with feedback information via LocoNet. You could do something similar, within the constraints of whatever communication link(s) you have between the Arduino and the computer.

Regards,
Billybob


Re: Turnout feedback

emmanuel ALLAUD
 

Forgot to add: last state is saved in eeprom and restored via a command so I could even do without reloading on every restart.
Manu

Le ven. 17 juil. 2020 à 19:38, Emmanuel Allaud <eallaud@...> a écrit :
Ok thanks.
In my case a python script is responsible for being the middle man between jmri (through a jython script) and the rs485 bus with the different arduino nodes. So I guess I will just collect all states when jmri connects. The bus will be busy for a while but the comm with jmri is via network so it should be no problem.
Thanks,
Manu

Le ven. 17 juil. 2020 à 19:21, RadSolution via groups.io <radsolution=yahoo.co.uk@groups.io> a écrit :
There has been a LOT of discussion in the MERG community regarding obtaining the known state of electrical switches, occupancy detectors and rail turnouts when the layout is first powered-up (as any of these could be changed manually whilst the power is off).

The usual approach is for a ‘Start of Day’ (SoD) event to occur - either by a timer or a push button - which the modules monitoring those devices reacts to, and sends the state of devices back to the ‘central’ point (usually a control panel, or JMRI), so that indicators can be correctly set, and not show ‘unknown’...


On 17 Jul 2020, at 18:05, Balazs Racz <balazs.racz@...> wrote:

Unknown is a correctly supported state for JMRI Sensors, but if the user went to the length of configuring feedback with sensors, then having those sensors be in an Unknown state is arguably not very useful to the user.
For example turnout feedback or sensors in general might be watched by CTC logic. THat logic will not really know what to do if the sensors say unknown.

Therefore my suggestion would be to just read the state upon startup and not worry too much about the number of messages this takes. Make the reading as fast as possible. Through my interaction with large layout owners the feedback I've been getting is that they would like the state to be as consistent as possible between JMRI and reality. This is how they can ensure that the business logic functions correctly.

On Fri, Jul 17, 2020 at 6:23 PM emmanuel ALLAUD <eallaud@...> wrote:

Thanks for your answers.

Just to precise things: the hardware I want to connect jmri to is arduino based and has the ability to tell when the turnout is in the requested position and also can be queried for the turnout position if needed.

I will connect this through a jython script (the protocol I am using is not known to jmri).

So if I dont send "events" to tell jmri about the turnouts position or the sensors state, they will stay in "unknown" until jmri gets a state for my hardware or, in the case of turnouts if there is commanded state, right?

Any problem you can think of that this situation could create?

I have the solution to send all states on startup, it might create a storm of events though for big layouts.

Bye

Manu

Le 17/07/20 à 11:38, Balazs Racz a écrit :
There is a hidden possibility to make JMRI request the state of the sensor. You have to enable the state query actions checkbox in the bottom of the sensor table. Then you will have a button to press that will make JMRI trigger the hardware specific implementation to request the state. (Internal sensors don't have such an implementation of course as no hardware is behind them.)
However, the expectation is that the sensor implementation will automatically request the state once during startup, and from then on when the sensor changes an incoming message from the control bus will trigger the sensor to update its state and JMRI's listeners. So generally a "sensor.query" is not something that people run in a typical session ever -- this is why the buttons are hidden by default.

Balazs 

On Fri, Jul 17, 2020 at 11:23 AM Randall Wood via groups.io <rhwood=mac.com@groups.io> wrote:


> On 17-Jul-2020, at 05:10, emmanuel ALLAUD <eallaud@...> wrote:
>
> Hi all,
>
> a simple question: does jmri ever request the state of a sensor? Same for turnout with feedback?

JMRI requests the state of a sensor if the connection protocol (e.g. LocoNet, CMRI, OpenLCB…) allows it. The same is true for turnout feedback.

Internal sensors do not request state, but typical these are connected to buttons on panels or other scripted logic that sets the state as appropriate.

> I have the impression that if there is a sensor set up in jmri, it will be in "unknown state" until it gets the information from whereever it is supposed to come from.

That is correct.

> TIA
>
> Manu
>
>
>
>





Re: Turnout feedback

emmanuel ALLAUD
 

Ok thanks.
In my case a python script is responsible for being the middle man between jmri (through a jython script) and the rs485 bus with the different arduino nodes. So I guess I will just collect all states when jmri connects. The bus will be busy for a while but the comm with jmri is via network so it should be no problem.
Thanks,
Manu

Le ven. 17 juil. 2020 à 19:21, RadSolution via groups.io <radsolution=yahoo.co.uk@groups.io> a écrit :
There has been a LOT of discussion in the MERG community regarding obtaining the known state of electrical switches, occupancy detectors and rail turnouts when the layout is first powered-up (as any of these could be changed manually whilst the power is off).

The usual approach is for a ‘Start of Day’ (SoD) event to occur - either by a timer or a push button - which the modules monitoring those devices reacts to, and sends the state of devices back to the ‘central’ point (usually a control panel, or JMRI), so that indicators can be correctly set, and not show ‘unknown’...


On 17 Jul 2020, at 18:05, Balazs Racz <balazs.racz@...> wrote:

Unknown is a correctly supported state for JMRI Sensors, but if the user went to the length of configuring feedback with sensors, then having those sensors be in an Unknown state is arguably not very useful to the user.
For example turnout feedback or sensors in general might be watched by CTC logic. THat logic will not really know what to do if the sensors say unknown.

Therefore my suggestion would be to just read the state upon startup and not worry too much about the number of messages this takes. Make the reading as fast as possible. Through my interaction with large layout owners the feedback I've been getting is that they would like the state to be as consistent as possible between JMRI and reality. This is how they can ensure that the business logic functions correctly.

On Fri, Jul 17, 2020 at 6:23 PM emmanuel ALLAUD <eallaud@...> wrote:

Thanks for your answers.

Just to precise things: the hardware I want to connect jmri to is arduino based and has the ability to tell when the turnout is in the requested position and also can be queried for the turnout position if needed.

I will connect this through a jython script (the protocol I am using is not known to jmri).

So if I dont send "events" to tell jmri about the turnouts position or the sensors state, they will stay in "unknown" until jmri gets a state for my hardware or, in the case of turnouts if there is commanded state, right?

Any problem you can think of that this situation could create?

I have the solution to send all states on startup, it might create a storm of events though for big layouts.

Bye

Manu

Le 17/07/20 à 11:38, Balazs Racz a écrit :
There is a hidden possibility to make JMRI request the state of the sensor. You have to enable the state query actions checkbox in the bottom of the sensor table. Then you will have a button to press that will make JMRI trigger the hardware specific implementation to request the state. (Internal sensors don't have such an implementation of course as no hardware is behind them.)
However, the expectation is that the sensor implementation will automatically request the state once during startup, and from then on when the sensor changes an incoming message from the control bus will trigger the sensor to update its state and JMRI's listeners. So generally a "sensor.query" is not something that people run in a typical session ever -- this is why the buttons are hidden by default.

Balazs 

On Fri, Jul 17, 2020 at 11:23 AM Randall Wood via groups.io <rhwood=mac.com@groups.io> wrote:


> On 17-Jul-2020, at 05:10, emmanuel ALLAUD <eallaud@...> wrote:
>
> Hi all,
>
> a simple question: does jmri ever request the state of a sensor? Same for turnout with feedback?

JMRI requests the state of a sensor if the connection protocol (e.g. LocoNet, CMRI, OpenLCB…) allows it. The same is true for turnout feedback.

Internal sensors do not request state, but typical these are connected to buttons on panels or other scripted logic that sets the state as appropriate.

> I have the impression that if there is a sensor set up in jmri, it will be in "unknown state" until it gets the information from whereever it is supposed to come from.

That is correct.

> TIA
>
> Manu
>
>
>
>





Re: Turnout feedback

RadSolution
 

There has been a LOT of discussion in the MERG community regarding obtaining the known state of electrical switches, occupancy detectors and rail turnouts when the layout is first powered-up (as any of these could be changed manually whilst the power is off).

The usual approach is for a ‘Start of Day’ (SoD) event to occur - either by a timer or a push button - which the modules monitoring those devices reacts to, and sends the state of devices back to the ‘central’ point (usually a control panel, or JMRI), so that indicators can be correctly set, and not show ‘unknown’...


On 17 Jul 2020, at 18:05, Balazs Racz <balazs.racz@...> wrote:

Unknown is a correctly supported state for JMRI Sensors, but if the user went to the length of configuring feedback with sensors, then having those sensors be in an Unknown state is arguably not very useful to the user.
For example turnout feedback or sensors in general might be watched by CTC logic. THat logic will not really know what to do if the sensors say unknown.

Therefore my suggestion would be to just read the state upon startup and not worry too much about the number of messages this takes. Make the reading as fast as possible. Through my interaction with large layout owners the feedback I've been getting is that they would like the state to be as consistent as possible between JMRI and reality. This is how they can ensure that the business logic functions correctly.

On Fri, Jul 17, 2020 at 6:23 PM emmanuel ALLAUD <eallaud@...> wrote:

Thanks for your answers.

Just to precise things: the hardware I want to connect jmri to is arduino based and has the ability to tell when the turnout is in the requested position and also can be queried for the turnout position if needed.

I will connect this through a jython script (the protocol I am using is not known to jmri).

So if I dont send "events" to tell jmri about the turnouts position or the sensors state, they will stay in "unknown" until jmri gets a state for my hardware or, in the case of turnouts if there is commanded state, right?

Any problem you can think of that this situation could create?

I have the solution to send all states on startup, it might create a storm of events though for big layouts.

Bye

Manu

Le 17/07/20 à 11:38, Balazs Racz a écrit :
There is a hidden possibility to make JMRI request the state of the sensor. You have to enable the state query actions checkbox in the bottom of the sensor table. Then you will have a button to press that will make JMRI trigger the hardware specific implementation to request the state. (Internal sensors don't have such an implementation of course as no hardware is behind them.)
However, the expectation is that the sensor implementation will automatically request the state once during startup, and from then on when the sensor changes an incoming message from the control bus will trigger the sensor to update its state and JMRI's listeners. So generally a "sensor.query" is not something that people run in a typical session ever -- this is why the buttons are hidden by default.

Balazs 

On Fri, Jul 17, 2020 at 11:23 AM Randall Wood via groups.io <rhwood=mac.com@groups.io> wrote:


> On 17-Jul-2020, at 05:10, emmanuel ALLAUD <eallaud@...> wrote:
>
> Hi all,
>
> a simple question: does jmri ever request the state of a sensor? Same for turnout with feedback?

JMRI requests the state of a sensor if the connection protocol (e.g. LocoNet, CMRI, OpenLCB…) allows it. The same is true for turnout feedback.

Internal sensors do not request state, but typical these are connected to buttons on panels or other scripted logic that sets the state as appropriate.

> I have the impression that if there is a sensor set up in jmri, it will be in "unknown state" until it gets the information from whereever it is supposed to come from.

That is correct.

> TIA
>
> Manu
>
>
>
>





Re: Turnout feedback

Balazs Racz
 

Unknown is a correctly supported state for JMRI Sensors, but if the user went to the length of configuring feedback with sensors, then having those sensors be in an Unknown state is arguably not very useful to the user.
For example turnout feedback or sensors in general might be watched by CTC logic. THat logic will not really know what to do if the sensors say unknown.

Therefore my suggestion would be to just read the state upon startup and not worry too much about the number of messages this takes. Make the reading as fast as possible. Through my interaction with large layout owners the feedback I've been getting is that they would like the state to be as consistent as possible between JMRI and reality. This is how they can ensure that the business logic functions correctly.

On Fri, Jul 17, 2020 at 6:23 PM emmanuel ALLAUD <eallaud@...> wrote:

Thanks for your answers.

Just to precise things: the hardware I want to connect jmri to is arduino based and has the ability to tell when the turnout is in the requested position and also can be queried for the turnout position if needed.

I will connect this through a jython script (the protocol I am using is not known to jmri).

So if I dont send "events" to tell jmri about the turnouts position or the sensors state, they will stay in "unknown" until jmri gets a state for my hardware or, in the case of turnouts if there is commanded state, right?

Any problem you can think of that this situation could create?

I have the solution to send all states on startup, it might create a storm of events though for big layouts.

Bye

Manu

Le 17/07/20 à 11:38, Balazs Racz a écrit :
There is a hidden possibility to make JMRI request the state of the sensor. You have to enable the state query actions checkbox in the bottom of the sensor table. Then you will have a button to press that will make JMRI trigger the hardware specific implementation to request the state. (Internal sensors don't have such an implementation of course as no hardware is behind them.)
However, the expectation is that the sensor implementation will automatically request the state once during startup, and from then on when the sensor changes an incoming message from the control bus will trigger the sensor to update its state and JMRI's listeners. So generally a "sensor.query" is not something that people run in a typical session ever -- this is why the buttons are hidden by default.

Balazs 

On Fri, Jul 17, 2020 at 11:23 AM Randall Wood via groups.io <rhwood=mac.com@groups.io> wrote:


> On 17-Jul-2020, at 05:10, emmanuel ALLAUD <eallaud@...> wrote:
>
> Hi all,
>
> a simple question: does jmri ever request the state of a sensor? Same for turnout with feedback?

JMRI requests the state of a sensor if the connection protocol (e.g. LocoNet, CMRI, OpenLCB…) allows it. The same is true for turnout feedback.

Internal sensors do not request state, but typical these are connected to buttons on panels or other scripted logic that sets the state as appropriate.

> I have the impression that if there is a sensor set up in jmri, it will be in "unknown state" until it gets the information from whereever it is supposed to come from.

That is correct.

> TIA
>
> Manu
>
>
>
>





Re: Turnout feedback

emmanuel ALLAUD
 

Thanks for your answers.

Just to precise things: the hardware I want to connect jmri to is arduino based and has the ability to tell when the turnout is in the requested position and also can be queried for the turnout position if needed.

I will connect this through a jython script (the protocol I am using is not known to jmri).

So if I dont send "events" to tell jmri about the turnouts position or the sensors state, they will stay in "unknown" until jmri gets a state for my hardware or, in the case of turnouts if there is commanded state, right?

Any problem you can think of that this situation could create?

I have the solution to send all states on startup, it might create a storm of events though for big layouts.

Bye

Manu

Le 17/07/20 à 11:38, Balazs Racz a écrit :

There is a hidden possibility to make JMRI request the state of the sensor. You have to enable the state query actions checkbox in the bottom of the sensor table. Then you will have a button to press that will make JMRI trigger the hardware specific implementation to request the state. (Internal sensors don't have such an implementation of course as no hardware is behind them.)
However, the expectation is that the sensor implementation will automatically request the state once during startup, and from then on when the sensor changes an incoming message from the control bus will trigger the sensor to update its state and JMRI's listeners. So generally a "sensor.query" is not something that people run in a typical session ever -- this is why the buttons are hidden by default.

Balazs 

On Fri, Jul 17, 2020 at 11:23 AM Randall Wood via groups.io <rhwood=mac.com@groups.io> wrote:


> On 17-Jul-2020, at 05:10, emmanuel ALLAUD <eallaud@...> wrote:
>
> Hi all,
>
> a simple question: does jmri ever request the state of a sensor? Same for turnout with feedback?

JMRI requests the state of a sensor if the connection protocol (e.g. LocoNet, CMRI, OpenLCB…) allows it. The same is true for turnout feedback.

Internal sensors do not request state, but typical these are connected to buttons on panels or other scripted logic that sets the state as appropriate.

> I have the impression that if there is a sensor set up in jmri, it will be in "unknown state" until it gets the information from whereever it is supposed to come from.

That is correct.

> TIA
>
> Manu
>
>
>
>





Re: Turnout feedback

Balazs Racz
 

There is a hidden possibility to make JMRI request the state of the sensor. You have to enable the state query actions checkbox in the bottom of the sensor table. Then you will have a button to press that will make JMRI trigger the hardware specific implementation to request the state. (Internal sensors don't have such an implementation of course as no hardware is behind them.)
However, the expectation is that the sensor implementation will automatically request the state once during startup, and from then on when the sensor changes an incoming message from the control bus will trigger the sensor to update its state and JMRI's listeners. So generally a "sensor.query" is not something that people run in a typical session ever -- this is why the buttons are hidden by default.

Balazs 

On Fri, Jul 17, 2020 at 11:23 AM Randall Wood via groups.io <rhwood=mac.com@groups.io> wrote:


> On 17-Jul-2020, at 05:10, emmanuel ALLAUD <eallaud@...> wrote:
>
> Hi all,
>
> a simple question: does jmri ever request the state of a sensor? Same for turnout with feedback?

JMRI requests the state of a sensor if the connection protocol (e.g. LocoNet, CMRI, OpenLCB…) allows it. The same is true for turnout feedback.

Internal sensors do not request state, but typical these are connected to buttons on panels or other scripted logic that sets the state as appropriate.

> I have the impression that if there is a sensor set up in jmri, it will be in "unknown state" until it gets the information from whereever it is supposed to come from.

That is correct.

> TIA
>
> Manu
>
>
>
>