toggle quoted messageShow quoted text
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’.
On 18 Jul 2020, at 07:38, emmanuel ALLAUD <eallaud@...
The save in eeprom is only for outputs and turnouts. For inputs they will be read on startup and reported when jmri connects.
“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@...
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
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 :
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.