|
I am running JMRI 4.17.3 with Digitrax and Loconet. My layout has signals implemented with RR-Cirkits SignalMan boards and detection with their WatchMan and BOD-8 dectectors. I've built panels with Layout Editor which show the turnout position and occupancy correctly on them (and they correctly show feedback from LocoNet). The signals have logic in the boards which sends "change aspect" messages. I see these as "send packet immediate" messages in the Loconet monitor window. If I click on the panel signal icon, I see those messages go out and the signal changes (as well as the display on the panel). But if the logic on a board sends the message, the panel doesn't reflect the result. I see messages from way back in 2011 that that was the case. Is there any chance that the feedback might get implemented? And perhaps the message completely decoded (or is that part of the Digitrax proprietary part)?
Scott Walton?
|
Scott,
A lot depends on exactly which type of signal message is being used. In
general, signals were either driven as turnouts, heads, or masts. The issue
is if the panel is a higher level object, like a head, but the board is
sending messages as turnouts, it can't "drive up hill". I mean the panel
object can't listed to the lower level messages due to chance of race
conditions. So if the panel is masts, then the messages would have to be
driving masts for example.
-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.org
www.syracusemodelrr.org
|
The signals are using masts. JMRI obviously understands the signal message format as I can click on the signal, choose "set aspect" and send any of aspects and the signal displays the results. The message appears to be identical to what the boards send. It sounds like one of those things that hasn't been implemented. It shouldn't be all that different from turnouts, sensors and reporters.?
Scott Walton
|
Scott,
What Ken is referring to is that JMRI can not receive signal data
from another source (than itself) if that data is using turnout
information. (i.e. SE8c mode, Output mode, LDT mode, etc.) There
have been numerous attempts to make that work over the years, but
it simply can not be done without adding time stamps to the
turnout commands. The reason is that you can not tell what aspect
is desired simply by looking at the current state of the turnouts.
You need to know the LAST sent command for each head and only
consider it.
However if the signals are being controlled with NMRA aspect
commands, then it should be able to work OK. However to make
things work with aspects requires a different underlying mast
type. This has been implemented for LCC/OpenLCB which normally
operates as aspects, but may not be available for LocoNet which
normally works as turnouts. I do notice that there are new
appearing selection options in the current test releases. It is
possible that someone has recently been working on this again. Try
4.17.5 or 4.17.6 to see if that changes anything.
Dick :)
On 11/20/2019 8:20 AM, Scott Walton
wrote:
toggle quoted message
Show quoted text
The signals are using masts. JMRI obviously understands the signal
message format as I can click on the signal, choose "set aspect"
and send any of aspects and the signal displays the results. The
message appears to be identical to what the boards send. It sounds
like one of those things that hasn't been implemented. It
shouldn't be all that different from turnouts, sensors and
reporters.?
Scott Walton
|
Scott wrote:
"The signals have logic in the boards which sends "change aspect" messages. I see these as "send packet immediate" messages in the Loconet monitor window. If I click on the panel signal icon, I see those messages go out and the signal changes (as well as the display on the panel). But if the logic on a board sends the message, the panel doesn't reflect the result."
A different way of saying this is that JMRI can _control_ that hardware which is controlled by the NMRA "Extended Accessory Decoder Control Packet" format and defined within JMRI as a "DCC Signal Mast Decoder". But a JMRI mast defined as a "DCC Signal Mast Decoder" _does not_ update its internal mast status based on externally-generated LocoNet messages, such as those generated by the SignalMan's internal logic. So JMRI does not show a correct on-screen icon to match the externally-generated aspect message, and JMRI logic does not follow the mast's current aspect.
It has been said before, and will likely be said again - JMRI _could_ be modified to provide the appropriate forwarding of such LocoNet message information to the appropriate JMRI signal mast object. But JMRI code does not do so.
There is one obvious solution - define the JMRI mast as an "LNCP Signal Mast Decoder" instead of "DCC Signal Mast Decoder", and configure the SignalMan in "DCC Signal Decoder Mode". This is an acceptable solution for the SignalMan as both mast types use the same LocoNet messaging. The LNCP signal mast type already follows externally-generated LocoNet messages which change the mast aspect. JMRI can display the correct icon when the SignalMan changes an aspect, and JMRI Logix and other logic features will also see the aspect change as an aspect change on the JMRI mast.
Regards,
Billybob
|
I¡¯m not at all expert on the DCC message structure. Is it really known to be true that there¡¯s enough information in the DCC messages to do that for "DCC Signal Mast Decoder"? I.e. there¡¯s a way to tell held or not, lit or not from just the messages? If that really can be done, modifying the code is straightforward. If that can¡¯t be done, there¡¯s no modification that could do it. Bob On Nov 24, 2019, at 8:21 AM, billybob experimenter <jawhugrps@...> wrote:
It has been said before, and will likely be said again - JMRI _could_ be modified to provide the appropriate forwarding of such LocoNet message information to the appropriate JMRI signal mast object. But JMRI code does not do so. -- Bob Jacobsen rgj1927@...
|
Bob J. wrote: "Is it really known to be true that there¡¯s enough information in the DCC messages to do that for "DCC Signal Mast Decoder"? I.e. there¡¯s a way to tell held or not, lit or not from just the messages?"
Generally, the NMRA standard for "Extended Accessory Decoder Control Packet"s defines a signal mast number and a five-bit aspect value (for up to 32 possible aspects). Other than aspect 0 being "absolute stop", it does not define any specific aspect/value pairing - the user or the hardware implementation gets to decide the other aspect/value pairings.
Specifically, JMRI's "Dark" aspect is typically conveyed to a DCC extended accessory decoder as a unique "aspect number", with the mast hardware using that aspect number to turn off all lamps in the signal. Presumably the DCC extended accessory decoder supports a dark mast. JMRI already has the capability to express "dark" as a signal mast aspect. For those system JMRI configurations which support monitoring externally-generated aspect changes, such as "LNCP Signal Mast"s when operating on a LocoNet connection, JMRI will follow such external aspect changes.
Specifically, JMRI's "Held" condition is an internal state of JMRI and, so far as I can tell, is not (typically) exposed in the DCC message.
There is no reason why one could not map the "held" condition to an aspect on an extended accessory decoder, so long as there is only one aspect used in the "held" case. That "held" aspect could duplicate the appearance of another aspect, such as "absolute stop", but use a different, unused DCC aspect number. Hardware would interpret that new aspect number as an appropriate appearance. This would allow communication of the "held" state on the control communication media.
In the user's specific case, with the suggestion made above, this unique LocoNet message for the "held" state would be uniquely conveyed via LocoNet, and JMRI would be able to "detect" the message, regardless of the message's source. A JMRI mast configured as an LNCP Signal Mast, via a LocoNet connection, would have this capability, without any JMRI Java coding changes, for any signal system which defined a unique aspect for the "held" state.
So far as I know, no existing JMRI Signal System definition defines the "held" aspect as a unique aspect; I believe they all simply declare the "held" state to be equivalent to the "Stop" aspect or some similar aspect. But a simple set of changes to the user's "signal system definition" would enable this functionality.
The only limitation I can think of to such a solution to convey "held" information on the communication media is that there are only 32 possible mast aspect numbers in the DCC Extended Accessory Decoder packet. Any existing mast which implements 32 unique aspects without a defined "held aspect" would not allow adding an additional aspect for the "held" case.
Regards,
Billybob
|
If you wanted to have signal logic in only one place (perhaps a good idea for a model railroad, but not what the prototype does in most CTC cases), then having Held be one of the set of aspects might work sometimes. JMRI could display the ¡°Held¡± state on its panels, which is the default behavior. There¡¯s an option to display the underlying aspect, which wouldn¡¯t be available, but I¡¯m not sure how often that¡¯s used. I don¡¯t know how CTC would work in this case as JMRI wouldn¡¯t be able to tell ¡°Held-but-otherwise-Clear¡± from ¡°Held-but-otherwise-Approach¡±, for example, but that¡¯s a problem for the logic which would (have to be) fully outside JMRI. Lit vs dark is another matter. They¡¯re not the same. Of the people using e.g. approach lighting for their signals (including at least one local layout), some large fraction have their panels display the current appearance of the signal even when it¡¯s set to ¡°unlit¡±. I¡¯m not sure how many of them use a true ¡°dark¡± appearance for an aspect, though. So JMRI could _mostly_ follow, with some exceptions, the state of a signal mast driven externally. When we tried to do that with SE8c heads (not masts), the exceptions caused a lot of confusion and the layout listening was eventually removed. But perhaps the application of masts would be OK with limitations. Bob On Nov 24, 2019, at 11:01 AM, billybob experimenter <jawhugrps@...> wrote:
Bob J. wrote: "Is it really known to be true that there¡¯s enough information in the DCC messages to do that for "DCC Signal Mast Decoder"? I.e. there¡¯s a way to tell held or not, lit or not from just the messages?"
Generally, the NMRA standard for "Extended Accessory Decoder Control Packet"s defines a signal mast number and a five-bit aspect value (for up to 32 possible aspects). Other than aspect 0 being "absolute stop", it does not define any specific aspect/value pairing - the user or the hardware implementation gets to decide the other aspect/value pairings.
Specifically, JMRI's "Dark" aspect is typically conveyed to a DCC extended accessory decoder as a unique "aspect number", with the mast hardware using that aspect number to turn off all lamps in the signal. Presumably the DCC extended accessory decoder supports a dark mast. JMRI already has the capability to express "dark" as a signal mast aspect. For those system JMRI configurations which support monitoring externally-generated aspect changes, such as "LNCP Signal Mast"s when operating on a LocoNet connection, JMRI will follow such external aspect changes.
Specifically, JMRI's "Held" condition is an internal state of JMRI and, so far as I can tell, is not (typically) exposed in the DCC message.
There is no reason why one could not map the "held" condition to an aspect on an extended accessory decoder, so long as there is only one aspect used in the "held" case. That "held" aspect could duplicate the appearance of another aspect, such as "absolute stop", but use a different, unused DCC aspect number. Hardware would interpret that new aspect number as an appropriate appearance. This would allow communication of the "held" state on the control communication media.
In the user's specific case, with the suggestion made above, this unique LocoNet message for the "held" state would be uniquely conveyed via LocoNet, and JMRI would be able to "detect" the message, regardless of the message's source. A JMRI mast configured as an LNCP Signal Mast, via a LocoNet connection, would have this capability, without any JMRI Java coding changes, for any signal system which defined a unique aspect for the "held" state.
So far as I know, no existing JMRI Signal System definition defines the "held" aspect as a unique aspect; I believe they all simply declare the "held" state to be equivalent to the "Stop" aspect or some similar aspect. But a simple set of changes to the user's "signal system definition" would enable this functionality.
The only limitation I can think of to such a solution to convey "held" information on the communication media is that there are only 32 possible mast aspect numbers in the DCC Extended Accessory Decoder packet. Any existing mast which implements 32 unique aspects without a defined "held aspect" would not allow adding an additional aspect for the "held" case.
Regards,
Billybob
-- Bob Jacobsen rgj1927@...
|
Bob J.,
Without JMRI Java code changes, differentiating something like "held, but would be clear if not held" from other "held" aspects would indeed be impossible to differentiate via watching the DCC Extended Stationary Decoder (or equivalent) traffic on the communication media.
With code changes, and signal system definition changes, one could include "Held-but-would-be-clear", "Held-but-would-be-Approach", etc. as unique aspects with unique DCC Extended Accessory Decoder aspect numbers, in the signal system definition. That would likely cause follow-on problems, though, especially for any code that monitors signal aspect information to determine how to run a train.
At least in the common prototype "approach-lit" signal circuits I have seen, the "aspect" information is always calculated, and is always reported to the signal(s) protecting movements in the approach to the signal, regardless of its lit/dark state. Whether or not a given signal is lit is not reported to the signals in the approach to the signal. JMRI models this at the mast level, but it does not model this behavior as part of DCC Extended Stationary Decoder (or equivalent) aspects.
One could spend a LOT of effort trying to model these kinds of behavior as part of the JMRI signal system definition, the DCC Extended Stationary Decoder traffic, and the Extended Stationary Decoder configuration. And face all of the issues of "too few aspects" available in the DCC packet, and the coding issues associated with all of the other JMRI features that rely on signal aspects for proper movement of trains and calculation of signals.
Such a JMRI coding effort seems like too much effort for dubious gain.
Regards,
Billybob
|
It should be mentioned that when a signal is dark, it would still have an
aspect, like stop or clear, it just would not be lighting the output. This
is needed because other signals next to it would base their aspects on the
aspect of this signal. If the concept of signal logic is integrated inside
the signal, it being dark should hide what state it would show should it
become lit.
Held is kind of different, while it isn't really an aspect, it causes a
specific aspect regardless of the signal logic. Typical case is stop (or
danger) even when the logic would otherwise has computed clear.
I think this is why Bob J was pointing out that simply knowing the
appearance (displayed aspect) does not let you know about these other
features. So depending on what is known or not about the signal determines
if you can accurately represent it externally to that signal. Granted for
some people, it will need the extra details to be considered right. Others
will not require that high of an accuracy about the signal. I think this
ambiguity is part of why JMRI doesn't do some things others might consider
simple.
-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.org
www.syracusemodelrr.org
|
At least in some systems, ¡°dark¡± is a valid appearance, at least for parts of a mast. So JMRI uses the lit vs unlit language to try to separate ¡°the signals lamps are not powered due to e.g. approach lighting¡±; ¡°dark¡± is used to mean ¡°this signals appearance includes this lamp not showing any light¡± On Nov 24, 2019, at 2:27 PM, Ken Cameron <kcameron@...> wrote:
to
It should be mentioned that when a signal is dark, it would still have an
aspect, like stop or clear, it just would not be lighting the output. This
is needed because other signals next to it would base their aspects on the
aspect of this signal. If the concept of signal logic is integrated inside
the signal, it being dark should hide what state it would show should it
become lit. -- Bob Jacobsen rgj1927@...
|
Bob,
As I remember it, the issue with the SE8c, LDT, etc. devices was that they use turnout commands in a way that requires remembering the last sent message information rather than the last state of each turnout's information. I.e. there is no way to look at the turnout table entries and deduce the aspect because the granularity is wrong. (the number of turnouts used does not match the number of aspects displayed)
In the case of a DCC signal mast the last mast command always matches the current aspect. (same for an OpenLCB/LCC aspect command)
As for the alleged lack of sufficient mast aspects in the NMRA extended accessory message range of 32 that someone mentioned, I would like to hear about the rule set that requires more than 32 aspects. (I'm not holding my breath) Granted there are way more than 32 aspect names in the world, but not found in the same rule book, so we probably don't need to expend a lot of electrons worrying about that issue.
Dick :)
toggle quoted message
Show quoted text
On 11/24/2019 2:32 PM, Bob Jacobsen wrote: If you wanted to have signal logic in only one place (perhaps a good idea for a model railroad, but not what the prototype does in most CTC cases), then having Held be one of the set of aspects might work sometimes. JMRI could display the ¡°Held¡± state on its panels, which is the default behavior. There¡¯s an option to display the underlying aspect, which wouldn¡¯t be available, but I¡¯m not sure how often that¡¯s used. I don¡¯t know how CTC would work in this case as JMRI wouldn¡¯t be able to tell ¡°Held-but-otherwise-Clear¡± from ¡°Held-but-otherwise-Approach¡±, for example, but that¡¯s a problem for the logic which would (have to be) fully outside JMRI.
Lit vs dark is another matter. They¡¯re not the same. Of the people using e.g. approach lighting for their signals (including at least one local layout), some large fraction have their panels display the current appearance of the signal even when it¡¯s set to ¡°unlit¡±. I¡¯m not sure how many of them use a true ¡°dark¡± appearance for an aspect, though.
So JMRI could _mostly_ follow, with some exceptions, the state of a signal mast driven externally. When we tried to do that with SE8c heads (not masts), the exceptions caused a lot of confusion and the layout listening was eventually removed. But perhaps the application of masts would be OK with limitations.
Bob
On Nov 24, 2019, at 11:01 AM, billybob experimenter <jawhugrps@...> wrote:
Bob J. wrote: "Is it really known to be true that there¡¯s enough information in the DCC messages to do that for "DCC Signal Mast Decoder"? I.e. there¡¯s a way to tell held or not, lit or not from just the messages?"
Generally, the NMRA standard for "Extended Accessory Decoder Control Packet"s defines a signal mast number and a five-bit aspect value (for up to 32 possible aspects). Other than aspect 0 being "absolute stop", it does not define any specific aspect/value pairing - the user or the hardware implementation gets to decide the other aspect/value pairings.
Specifically, JMRI's "Dark" aspect is typically conveyed to a DCC extended accessory decoder as a unique "aspect number", with the mast hardware using that aspect number to turn off all lamps in the signal. Presumably the DCC extended accessory decoder supports a dark mast. JMRI already has the capability to express "dark" as a signal mast aspect. For those system JMRI configurations which support monitoring externally-generated aspect changes, such as "LNCP Signal Mast"s when operating on a LocoNet connection, JMRI will follow such external aspect changes.
Specifically, JMRI's "Held" condition is an internal state of JMRI and, so far as I can tell, is not (typically) exposed in the DCC message.
There is no reason why one could not map the "held" condition to an aspect on an extended accessory decoder, so long as there is only one aspect used in the "held" case. That "held" aspect could duplicate the appearance of another aspect, such as "absolute stop", but use a different, unused DCC aspect number. Hardware would interpret that new aspect number as an appropriate appearance. This would allow communication of the "held" state on the control communication media.
In the user's specific case, with the suggestion made above, this unique LocoNet message for the "held" state would be uniquely conveyed via LocoNet, and JMRI would be able to "detect" the message, regardless of the message's source. A JMRI mast configured as an LNCP Signal Mast, via a LocoNet connection, would have this capability, without any JMRI Java coding changes, for any signal system which defined a unique aspect for the "held" state.
So far as I know, no existing JMRI Signal System definition defines the "held" aspect as a unique aspect; I believe they all simply declare the "held" state to be equivalent to the "Stop" aspect or some similar aspect. But a simple set of changes to the user's "signal system definition" would enable this functionality.
The only limitation I can think of to such a solution to convey "held" information on the communication media is that there are only 32 possible mast aspect numbers in the DCC Extended Accessory Decoder packet. Any existing mast which implements 32 unique aspects without a defined "held aspect" would not allow adding an additional aspect for the "held" case.
Regards,
Billybob
--
Bob Jacobsen
rgj1927@...
|
Dick wrote "I would like to hear about the rule set that requires more than 32 aspects."
FIY - The following existing JMRI mast definitions implement more than 30 aspects:
- CROR-2008 - 3A-Hi : 31 aspects - see .
- CROR-2008 - 3D-Hi : 31 aspetcts - see .
- CROR-2008 - 3-Hi: 31 aspects - see .
If one were to add duplicate aspects to reflect "Dark but would otherwise be displaying XXX" aspects as I have suggested for discussion purposes, it would double the count of aspects, and exceed the available number of DCC Extended Accessory Decoder aspect values.
I would not be surprised to find that one or more non-US signal system would have a mast which could display more than 32 aspects...
A few other existing JMRI signal mast definitions appear to implement more than 30 aspects but are named as "test" masts or appear to include images for multiple mast types where they would typically define only a single mast type per "appearance" file, so the actual aspect count is suspect.
Regards,
Billybob
|
Bob,
My gut reaction is that arbitrarily adding 'aspects' to cover the lit and not lit cases is probably not a good idea. My feeling is that we should always move closer to the prototype, not away from it. I appreciate what you are trying to accomplish by this, and that is central control of everything by JMRI. However if that is the case, then JMRI can simply keep the information internally, and control the signal by sending 'dark'. If you add in an extra set of 'aspects' to include the lit/unlit information then the local signal logic would need to somehow sort that information back out of the aspect data, and I wouldn't want to send any users down that path. Too many orcs and goblins.
I also seriously doubt that any given CROR mast would ever be called upon to show all 31 signal aspects that would be possible to display, but that begs the question.
Dick :)
toggle quoted message
Show quoted text
On 11/24/2019 11:04 PM, billybob experimenter wrote: Dick wrote "I would like to hear about the rule set that requires more than 32 aspects."
FIY - The following existing JMRI mast definitions implement more than 30 aspects:
- CROR-2008 - 3A-Hi : 31 aspects - see .
- CROR-2008 - 3D-Hi : 31 aspetcts - see .
- CROR-2008 - 3-Hi: 31 aspects - see .
If one were to add duplicate aspects to reflect "Dark but would otherwise be displaying XXX" aspects as I have suggested for discussion purposes, it would double the count of aspects, and exceed the available number of DCC Extended Accessory Decoder aspect values.
I would not be surprised to find that one or more non-US signal system would have a mast which could display more than 32 aspects...
A few other existing JMRI signal mast definitions appear to implement more than 30 aspects but are named as "test" masts or appear to include images for multiple mast types where they would typically define only a single mast type per "appearance" file, so the actual aspect count is suspect.
Regards,
Billybob
|
Bob,
Oh no :( Our hardware can not properly control this signal using aspect messages because we do not have any internal control on flash rate options. This is the first time that I have heard of a signal system that differentiated aspects by flash rate.
Dick :)
toggle quoted message
Show quoted text
On 11/24/2019 5:48 PM, Bob Jacobsen wrote:
|
Ken Cameron
Bob Jacobsen