Sensors and CTC:
Logic (the recent one) always assumes the worst case (fail
safe) when not ACTIVE or INACTIVE.
instance, if I’m trying to clear a route, it won’t clear.
I can’t think that I missed one or more,
there may be “errors” of state I don’t process properly.
Won’t crash, just not “fail safe”.
no one dies, just grave site markers by the main line!)
:-) :-) :-)
is 2800’ sq ft., full CTC, 30 operators. Using LocoNet.
Had to split LocoNet into two functions,
wires): Throttle (throttles, track), and Signals (Sensors,
Turnout drivers, Signals). When
starts up, the blast is big even if in 1/8’s at a time
(JMRI / Digitrax design).
while running, I have .py software to repeat a signal
indication change to the field
a second for 5 seconds. LCC should get rid of this
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
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@...>
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
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
Any problem you can think of that this situation
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
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 17-Jul-2020, at 05:10, emmanuel ALLAUD
> Hi all,
> a simple question: does jmri ever request
the state of a sensor? Same for turnout with
JMRI requests the state of a sensor if the
connection protocol (e.g. LocoNet, CMRI,
OpenLCB…) allows it. The same is true for
Internal sensors do not request state, but
typical these are connected to buttons on panels
or other scripted logic that sets the state as
> 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.