On 3 Sep, Bob Jacobsen wrote:
> At 2:17 PM -0400 9/3/05, paul.bender@... wrote:
>> If you use decoders
>>with feedback for the turnouts through a Lenz Command Station, the
>>JMRI XPressNet code allows the track packets to repeat until the
>>feedback indicates the motion of the turnout is complete.
> Life is not always this simple, I think, though I'm not sure where
> the boundary lies.
> *) If you're using Lenz equipment out to the accessory decoders, but
> the feedback sensors are read via some other system (e.g. C/MRI),
> does it know to retry?
> *) If you're using Lenz equipment, but just they're normal (no
> feedback) accessory decoders & using another Lenz route to get sensor
> information, does it retry?
These two cases are identical. They feedback is handled through the
The XPressNet code actually sets up a listener to listen for changes of
the KnownState when it is not handling the feedback directly (i.e. when
in ONESENSOR or TWOSENSOR mode).
It tells the command station to STOP repeating the packets to the track
when it receives an update for the KnownState property where the old
value was INCONSISTENT.
> *) If you're using the Lenz accessory decoders with feedback, but no
> feedback bus, does it know to retry?
In this case, it treats the decoders exactly like it would a decoder
without feedback. If there is no feedback connections back to the
command station, the command station doesn't know the decoder doesn't
> In the end, we'll need to document how this all works so that people
> can understand it. And _when_ they should expect it to work is part
> of that.
> For example, there's a page that describes "feedback" at a similar
> level here:
> and then refers to a more detailed page for the complicated case of
> the DS54 (which seems to be quite similar to the Lenz situation, at
> least in the number of possible situations)
Well it is and it isn't...
Where it isn't is that the type of messages we get back from the command
station depend as much on the command station than how the decoders are
All of the feedback modes identified as "DIRECT" mode in the XPressNet
code are implemented as a side effect of determining when to tell the
command station to STOP repeating the commands on the track. (much of
this code was put in place to prevent burning out solenoid switch
machines from repeated firings, and to allow buttons on the fascia to
work the decoders properly).
Most of this code predates the Turnout Feedback modes. As a result, It
really doesn't fit into ANY of the feedback modes described in the page
linked above (it never has). This is actually a combination of DIRECT,
MONITORING and EXACT modes, but exactly what you get depends on how the
hardware is wired and what command station we're using.
The Lenz feedback is basically "DIRECT" feedback when the command
station doesn't respond to the commands at all, "MONITORING" feedback
when the Command Station replies with a status message for a turnout
without feedback, and "EXACT" when the Command Station replies for a
turnout with feedback. The feedback response messages can actually be
obtained asynchronously as well.
The reason we use "DIRECT" mode to describe this behavior for Lenz
turnouts is because, as it described in the page linked above, DIRECT
mode is "The default in many cases, and also the original behavior of
the program." i.e. this was the behavior of the program BEFORE the
feedback modes were added, so this is the default behavior now.
I should also point out, it would be fairly easy to split out the
"EXACT" mode behavior in the code. This would simply force a decoder
with feedback to act like a decoder without feedback in "DIRECT" mode
and use the current behavior for these decoders in "EXACT" mode.
Of course, this still doesn't behave exactly like "EXACT" mode for a
DS54 in the LocoNet case. If the turnout is thrown through external
means (a throttle or a pushbutton), then it behaves like the DS54
"EXACT" mode. If the computer sends the command to the command station,
then it will repeatedly ask for the feedback status of the decoder until
the status indicates the motion is complete. At that time, it will ask
the command station to STOP sending accessory decoder commands to the
decoder in question.
> Terminology is key in things like this. I've been corresponding with
> John a little about that offline. His view is that this code is
> intended to assure (to the extent possible) that the physical piece
> of track has actually moved to the right place, even if something
> goes wrong along the way. So I'd like to see the retry terminology
> (and if need be the feedback terminology) make it really clear how
> far down the line JMRI is extending that assurance:
> "We're absolutely certain that the command station heard us ask nicely"
> "We're certain the command station sent out the command, and we think
> it likely that the decoder heard it"
But how do we distinguish between these two cases if we only get an ACK
from the command station? (In the XPressNet case, even if a feedback
response is generated by the command station that's really just an ACK.)
> "We've got a notarized reply from the decoder, but that's it"
In other words an ACK from the decoder, which implies bi-directional
communications all the way from the computer to the decoder.
> "The decoder says that he's seen the Tortoise motor move, then stall
> out; of course, the points might still be stuck"
> "The microswitches say that the points are moved and locked"
Of course, we can't distinguish between these two cases. These both
depend on where the contacts giving us feedback are connected to the
mechanism. (i.e. Is the feedback on the linkage or on the throwbar?
Programmaticaly, we have no way to tell).
Now, with all this said, The complication we're really dealing with is
that some command stations repeat the accessory decoder commands until
told to stop while others repeat the commands for a fixed number of
iterations and then stop. This doesn't really fit into the whole
re-try mechanism that John has come up with.
Of course, this can get even more complicated depending on which command
station we're talking about. We don't actually know if the command
station is repeating the commands to the track or if the command station
repeated them for a fixed number of times, and then quit.
As an example, If we see an "OK" message as a reply to a request to
switch a decoder, there are three possible situations that could have
1) We're using a Lenz built command station like the Atlas Commander,
which simply repeats the accessory decoder packets some fixed number of
times to the track, but sends no response to the XPressNet Command
2) We're using an XPressNet command station like the Roco LocoMouse II,
which repeats the accessory decoder packets to the track until we tell
it to stop, but sends no response to the XPressNet Command
3) We're using an XPressNet command station like the LZV100, which
repeats the accessory decoder packets to the track until we tell it to
stop, but sent no response because it believes the decoder was already
in the requested state
We don't have any way to distinguish between the cases above. (OK, we
could find out if we have the third case by asking for the feedback
status for the accessory device - if we're in either of the first two
cases, the command station would respond with a message indicating it
didn't support the command we sent to it).
In our case, we are actually reducing all three cases to case 3 (since
that is the only safe thing to do). As a result, if we see an OK
message as a response to an accessory decoder operations request (and
we're using "DIRECT" feedback mode), we just ask the command station to
stop sending the accessory decoder commands to the track. (This is also
when we set the known state to equal the commanded state, which is where
"DIRECT" mode fits into the whole turnout feedback structure).
"Quality is a Characteristic of thought and statement that
is recognized by a nonthinking process. Because
definitions are a product of rigid formal thinking,
quality cannot be defined."
Robert M. Pirsig
Zen and The Art of Motorcycle Maintenance