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




Join jmri@jmri-developers.groups.io to automatically receive all group messages.