Re: Turnout feedback

emmanuel ALLAUD

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

Le sam. 18 juil. 2020 à 00:42, RadSolution via <> 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?



Le 18/07/20 à 00:14, emmanuel ALLAUD via 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...


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



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





From: [] On Behalf Of Balazs Racz
Sent: Friday, July 17, 2020 12:05 PM
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.



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.




On Fri, Jul 17, 2020 at 11:23 AM Randall Wood via <> 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.

> Manu

Join to automatically receive all group messages.