Topics

Setting up hardware signals with a Signalman and CATS

Gary Hinshaw
 

I am trying to make the transition from virtual signals to hardware signals and I have come to a bridge I don't know how to cross.  I hope some patient soul here can point me in the right direction.  My layout is Digitrax DCC system with a LocoBuffer-USB interface to JMRI and CATS.  I have a Layout Editor panel in JMRI and a CTC panel in CATS and I have been using virtual signal heads, driven by CATS, for several months now.  This gives me working signal aspects on my panel and it all seems to work as expected.

I am now ready to make the jump to hardware signals using RR-CirKits Signalman decoders and 3-color LED-based searchlight signals.  So far I can define signal masts in JMRI and I can use the DCC Signal Mast Decoder schema to program the Signalman in a way I understand, but I cannot figure how to bridge the gap between CATS and the Signalman, or more generically, how to link signal masts to signal heads.

On the one hand, the CATS schema makes working with signal heads very straightforward, but I can't figure out how to program the Signalman in the language of signal heads.  I have tried defining Signal Head Controlled Masts in JMRI using the heads that CATS knows about, but I can't understand what accessory (or mast) address to use when programming the Signalman in this scheme.  On the other hand, I don't understand how to make CATS address a signal mast as opposed to a signal head, and I'm not sure which, if either, approach is preferable.

Has anyone else here already crossed this bridge?  It seems like Signal Head Controlled Masts are the natural way to go, if I can figure out the Signalman programming for this mode.  

Thanks in advance,
Gary

Ken Cameron
 

Gary,

I think this would be better on the CATS list, but Rodney is likely to see
it here anyway. I don't recall if he got to where CATS knows how to do
masts.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org

Gary Hinshaw
 

Thanks Ken.  I believe the CATS group is inactive, as I was never able to register as a member (last attempted 2-3 months ago).  However, I have Rodney's email address, so I have sent him a copy of this query directly.  I will report back with any progress.

As a bit of additional info, if I define a DCC Signal Mast Decoder mast, I get a system name like:

LF$dsm:UP-2008:SL-2AA(25)

and I can use accessory address 25 to successfully program the Signalman.  However, if I define a Signal Head Controlled Mast, I get a system name  like:

IF$shsm:UP-2008:SL-2AA(LH102)(LH103)

where LH102 and LH103 are the two heads on this mast (which CATS knows about).  How can I address this mast when programming the Signalman?  Alternatively, how can I program the heads individually?  If there is a way, I think I have a solution to my problem.

-gfh

Dave Sand
 

Gary,

You should be able to define the signal heads as a DCC Signal Decoder type.  You assign each head an address.  Each signal head appearance has a number, 0 to 8.

The SignalMan would be defined using the address and the appearance numbers to set the appropriate LED.  The masts would be defined using Signal Head Controlled Mast.

Dave Sand



On Jun 11, 2018, at 4:01 PM, Gary Hinshaw <gary.f.hinshaw@...> wrote:

Thanks Ken.  I believe the CATS group is inactive, as I was never able to register as a member (last attempted 2-3 months ago).  However, I have Rodney's email address, so I have sent him a copy of this query directly.  I will report back with any progress.

As a bit of additional info, if I define a DCC Signal Mast Decoder mast, I get a system name like:

LF$dsm:UP-2008:SL-2AA(25)

and I can use accessory address 25 to successfully program the Signalman.  However, if I define a Signal Head Controlled Mast, I get a system name  like:

IF$shsm:UP-2008:SL-2AA(LH102)(LH103)

where LH102 and LH103 are the two heads on this mast (which CATS knows about).  How can I address this mast when programming the Signalman?  Alternatively, how can I program the heads individually?  If there is a way, I think I have a solution to my problem.

-gfh

Gary Hinshaw
 

Hi Dave,

I see how to define heads as DCC Signal Decoder type, and I'm able to do so.  I'm also able to define a Signal Head Controlled Mast with these heads.  The piece I'm missing is how to program the Signalman to set the appearance of an individual head from 0 to 8, since the Decoder Pro panes only know about mast aspects (or Loconet/Turnout/Sensor states).  Alternatively, I'd like to know how to address a Signal Head Controlled Mast in the Signalman mast pane.  There must be some accessory number convention for these masts, no?

(Recall that I am able to program the Signalman using the DCC Signal Mast Decoder schema, but I don't know how to make that work with CATS.)

Thanks,
Gary

rodneyblack2000
 

Gary,

CATS does not understand JMRI SignalMasts, yet.  So the way to use the Signalman with CATS is as a collection of turnouts (see Section 4.2.4 of the Signalman manual).  You would define the Turnouts that comprise a JMRI SignalHead in either designer or a JMRI panel.  Then, in CATdesigner you would construct each SignalHead by telling it which Turnouts are used for Red, Green, Yellow, etc.  This does not utilize the Signalman's internal aspect processing, but it is the most obvious way that I see for using a Signalman with CATS.  Someone reading this may have a better way.

The piece that I can't help you on is associating a JMRI Turnout number with a Signalman driven LED.  I will guess that each Signalman has a board ID and each LED can be addressed based on the board ID and LED number driven by the board.  Section 4.3.1 of the Signalman manual talks about this.  I looked for some table in the manual or some equation, but didn't see either.  However, I just skimmed the manual.

I hope that helps with building the bridge.

Rodney

______________________________________________________________________________________
  Setting up hardware signals with a Signalman and CATS
From: Gary Hinshaw
Date: Mon, 11 Jun 2018 13:08:50 PDT

I am trying to make the transition from virtual signals to hardware signals and I have come to a bridge I don't know how to cross.  I hope some patient soul here can point me in the right direction.  My layout is Digitrax DCC system with a LocoBuffer-USB interface to JMRI and CATS.  I have a Layout Editor panel in JMRI and a CTC panel in CATS and I have been using virtual signal heads, driven by CATS, for several months now.  This gives me working signal aspects on my panel and it all seems to work as expected.

I am now ready to make the jump to hardware signals using RR-CirKits Signalman decoders and 3-color LED-based searchlight signals.  So far I can define signal masts in JMRI and I can use the DCC Signal Mast Decoder schema to program the Signalman in a way I understand, but I cannot figure how to bridge the gap between CATS and the Signalman, or more generically, how to link signal masts to signal heads.

On the one hand, the CATS schema makes working with signal heads very straightforward, but I can't figure out how to program the Signalman in the language of signal heads.  I have tried defining Signal Head Controlled Masts in JMRI using the heads that CATS knows about, but I can't understand what accessory (or mast) address to use when programming the Signalman in this scheme.  On the other hand, I don't understand how to make CATS address a signal mast as opposed to a signal head, and I'm not sure which, if either, approach is preferable.

Has anyone else here already crossed this bridge?  It seems like Signal Head Controlled Masts are the natural way to go, if I can figure out the Signalman programming for this mode.  

Thanks in advance,
Gary


dick bronson
 

Hi,
The problem may be that CATS still doesn't understand how to control signals using the NMRA DCC signal aspect commands. (used by the SignalMan and other devices) If that is the issue, then change the SignalMan to respond to turnout commands like some legacy hardware uses. CATS surely can do that.

Dick :)

On 06/11/2018 06:14 PM, Gary Hinshaw wrote:
Hi Dave,

I see how to define heads as DCC Signal Decoder type, and I'm able to do so.  I'm also able to define a Signal Head Controlled Mast with these heads.  The piece I'm missing is how to program the Signalman to set the appearance of an individual head from 0 to 8, since the Decoder Pro panes only know about mast aspects (or Loconet/Turnout/Sensor states).  Alternatively, I'd like to know how to address a Signal Head Controlled Mast in the Signalman mast pane.  There must be some accessory number convention for these masts, no?

(Recall that I am able to program the Signalman using the DCC Signal Mast Decoder schema, but I don't know how to make that work with CATS.)

Thanks,
Gary

Gary Hinshaw
 

Thanks Rodney and Dick.  I was starting to think this was the way to go, but I still have a puzzle about how to fill in the final section of the bridge.  I can program individual 3-color LEDs with 2 turnout addresses (e.g. 9T, 9C, 10T, 10C), but I don't see how to associate two turnout addresses (in the Signalman) with 1 signal head address (in CATS).  Any tips?

If the Signalman could speak the language of heads or CATS could speak the language of masts (or both) this would be much more obvious.  But I'll play with the TO commands and report back.

In any event, nice to have all these experts on call! :)
-gfh

Gary Hinshaw
 

By the way, is "turnout" in this context just a figure of speech?  I'm thinking these turnout commands are just a mnemonic for binary switches.  Is that correct?

dick bronson
 

Gary,
The SignalMan is a LocoNet compatible device, and Digitrax calls all output drivers 'Turnouts', even if they are controlling signals. If we didn't comply, then we would confuse even more folks.

Dick :)

On 06/11/2018 11:21 PM, Gary Hinshaw wrote:
By the way, is "turnout" in this context just a figure of speech?  I'm thinking these turnout commands are just a mnemonic for binary switches. Is that correct?

Gary Hinshaw
 

Success! 

I was able to define a signal head using the LDT LS-DEC definition which requires 4 virtual turnouts to define 7 appearances.  The Signalman is programmed using the 4 turnout addresses and CATS employs the corresponding signal head address, and is able to properly drive the head from the CTC panel.  This gives me a straightforward path to define all of the signal heads in hardware that CATS needs to use.  The scheme is not quite as elegant as the signal mast formalism, but it works which is 99% of the game.  (And the flashing appearances are implemented in hardware with this definition.)

Thanks!
Gary

Gary Hinshaw
 

A small follow-up question: things are mostly working as expected except that the initialization of the signal states is a bit odd.  If I start CATS, all signal heads initialize to red as expected for CTC, but only the turnout states associated with a red appearance show a known state; the rest are unknown.   Then, when I turn on track power, some signal heads remain red while others turn to flashing red, but all the states in the signal head table still show red (as do the head icons on my panel).  All turnout states appear to remain the same as before track power was turned on (many are still unknown), so it seems that something is happening in the Signalman to change head states in a way that is not reported back to JMRI.   

Does this make sense?  Is there an obvious remedy?

Thanks,
Gary

P.S. FWIW, the turnouts addresses in question all have their Feedback Mode set to Monitoring.

Gary Hinshaw
 

BTW, the reason this is problematic is because the signal logic thinks that all signals are still red after track power-up even though many are not, and since that is the default state for CTC, the logic does not send a change command when, e.g. a train enters an opposing block.  

Gary Hinshaw
 

One more tidbit: if I turn on track power from a throttle before starting CATS, the signals initialize properly: they all appear steady red and they match the signal head table, so this is a simple startup solution for my layout.  (And I think the CATS/JMRI interaction is fine.)  However, if I start CATS first, then turn on track power all the signal heads revert to flashing red, while the JMRI head state still reads Red.  This mismatch between physical state and JMRI state causes logic problems, so it seems that I either have to follow the above recipe, or write a script to manually initialize the heads after power up.  I'm just puzzled by what action causes the heads to act this way at power up and would like to understand it.

BTW, I tried updating the Signalman firmware from 1.9 to 2.2, and also tried changing the turnout feedback mode from Monitoring to Direct.  Neither change affected the above behaviour.

rodneyblack2000
 

Gary,
Initializing any system - from cold to a known state can be "interesting" and challenging, particularly one involving a bunch of independent hardware components and some rather complex software, such as the JMRI/CATS combination.  First, there is how each piece handles how to get from an unknown state to a known state.  Then there is how to sequence them all.

The Loconet specification allows a Loconet device to report its state at power up.  For something like an SE8C, this means dumping the the state of each of its electrical switches on the Loconet.  Since the state of each switch is an individual message, that means each SE8C dumps a bunch of messages on the Loconet.  And, if all SE8Cs power up together, they are all dong the same thing.  It is like the crowd at a sporting event getting into their cars and trying to get out on the road at the same time.  Congestion and possibly lost messages can result.

Though the Loconet specification allows that behavior, it does not demand it.  Thus, each device vendor can chose to broadcast initial state at power on - or not.  Some devices have an Op Switch that enables the user to configure the behavior.  I don't know what the Signalman does.

The Loconet specification also defines a message that requests every device on the Loconet to report its state; however, there are six (maybe eight) addresses, so that 1/6 (1/8) of the devices on the Loconet can be queried at a time - spreading out the responses.  CATS uses the latter when attached to a Loconet interface, but I think it waits between interrogating addresses to spread out the congestion.

If CATS is started first, the final stages of initialization depend on the hardware devices reporting their state at power up.  If CATS hears nothing it makes no changes to the layout and the devices initialize however they initialize.  If the layout is powered up first, then any initial state changes from devices will be not be heard - like the a tree falling in the woods with no one to hear it.  But when CATS starts up, it interrogates the devices to find out what they are doing.  Something that you might rry is to start CATS first, then the layout, then use the CATS "Refresh Layout" menu item.  That should force CATS to interrogate each device.

So, the short answer to your concern is "the difference is not surprising".  The surprise would be if there was no difference.

Rodney
__________________________________________________________________________________________________________________________________________________________
  Re: Setting up hardware signals with a Signalman and CATS
From: Gary Hinshaw
Date: Wed, 13 Jun 2018 21:11:44 PDT

One more tidbit: if I turn on track power from a throttle before starting CATS, the signals initialize properly: they all appear steady red and they match the signal head table, so this is a simple startup solution for my layout.  (And I think the CATS/JMRI interaction is fine.)  However, if I start CATS first, then turn on track power all the signal heads revert to flashing red, while the JMRI head state still reads Red.  This mismatch between physical state and JMRI state causes logic problems, so it seems that I either have to follow the above recipe, or write a script to manually initialize the heads after power up.  I'm just puzzled by what action causes the heads to act this way at power up and would like to understand it.

BTW, I tried updating the Signalman firmware from 1.9 to 2.2, and also tried changing the turnout feedback mode from Monitoring to Direct.  Neither change affected the above behaviour.


Gary Hinshaw
 

Thanks for that background info Rodney.  It's always useful to know how things are working under the hood.  I have been watching some of this initialization traffic in the Monitor Loconet window and I see the command station requesting information from blocks of addresses in sequence, along the lines you indicate.

In my case, the turnout addresses for the signal heads on the Signalman are LT101-LT116, corresponding to heads LH101-LH104.    As far as I can tell, when I turn on track power, the command station starts polling and when it reaches the LT101-116 range, the Signalman goes into this flashing red mode, regardless of what state it was in prior to this.  It seems like a read-only operation is causing a state change in the Signalman, but it is not reflected in any JMRI tables.  If I look at the signal head table, LH101-104 correctly report Red (if I'm running CATS) or Dark (if I'm running Panel Pro), and the turnout states match the signal head states.  In addition, the signal head icons on the panel all match their JMRI state, but the LEDs are flashing red.

I'm pretty sure that I have the Signalman wired and programmed properly, per the manual.  If I manually command the heads from the head table, outputs behave as expected, so I can recover from this by writing a script to manually initialize all the signals, but it does seem like a quirk in the Signalman firmware, or a misconfigured OpSw (or similar) on my part.  I have sent Dick some additional info by email, and I'm sure he'll have some useful feedback.  He's very good with customer support.  :)

rodneyblack2000
 

Gary,
 
Signals could be considered "write only" - they accept commands, but do not report changes.  Thus, on power-on, they come up with some aspect, but have no capability to tell the rest of the system anything about their state.  If that is the case with the Signalman and the software does not initialize its internal state to the Signalman power up state, then there will be a mis-match and something will be required to synchronize everything.

Before writing a script to initialize your hardware,  from the CATS window, try Appearance->Refresh Layout.

Rodney
_________________________________________________________________________________________________________
Thanks for that background info Rodney.  It's always useful to know how things are working under the hood.  I have been watching some of this initialization traffic in the Monitor Loconet window and I see the command station requesting information from blocks of addresses in sequence, along the lines you indicate.

In my case, the turnout addresses for the signal heads on the Signalman are LT101-LT116, corresponding to heads LH101-LH104.    As far as I can tell, when I turn on track power, the command station starts polling and when it reaches the LT101-116 range, the Signalman goes into this flashing red mode, regardless of what state it was in prior to this.  It seems like a read-only operation is causing a state change in the Signalman, but it is not reflected in any JMRI tables.  If I look at the signal head table, LH101-104 correctly report Red (if I'm running CATS) or Dark (if I'm running Panel Pro), and the turnout states match the signal head states.  In addition, the signal head icons on the panel all match their JMRI state, but the LEDs are flashing red.

I'm pretty sure that I have the Signalman wired and programmed properly, per the manual.  If I manually command the heads from the head table, outputs behave as expected, so I can recover from this by writing a script to manually initialize all the signals, but it does seem like a quirk in the Signalman firmware, or a misconfigured OpSw (or similar) on my part.  I have sent Dick some additional info by email, and I'm sure he'll have some useful feedback.  He's very good with customer support.  :)

Gary Hinshaw
 

Ah yes.  I forgot to mention that I did try that, and it had no effect.  The problem there is that the state in the signal head table is Red, as it should be, and I think (correct me if I'm wrong) Refresh Layout will prompt CATS to issue Red again, but this has no effect because JMRI thinks the signal is already Red.  The only way to change the LEDs in this condition is to first change from Red to anything else (then back to Red if desired).  I can do this manually in the signal head table.

I agree that the Signalman should be write-only, and that is what I see in the polling results: when the command station polls all the turnout states when I turn on track power, the Motorman decoders all correctly report back the state of the physical turnouts, but the Signalman does not report the turnouts associated with the signal heads.  Nonetheless, based on watching the Monitor Loconet window, it seems the act of polling is what puts the board in the flashing red state.

I think CATS and JMRI are both behaving as expected here and my issue is with the Signalman going rogue, either because I have mis-programmed it, or because of a firmware glitch.  Hopefully Dick can help me sort this out.

Gary Hinshaw
 

Hi again Rodney,

Actually it looks like you have already written the script I need.  In CATS, under Appearance/Test Layout/Signal Aspect Test, I can set all the signals to any aspect I want and the Signalman correctly responds.  So that is a simple solution to properly initialize.

Thanks! :)

dick bronson
 

Gary,
A SignalMan knows its last aspect. However you can not report that in terms of turnout states because it would need to only report just the last turnout state that changed an aspect, not the last state of every turnout it uses. I.e. when using turnouts to control signals it is a one way relationship. JMRI and I presume CATS want to be in control of the signals, and not get 'corrected' by the hardware.

The bottom line is that a SignalMan will not report its 'turnout' states even though it uses and remembers them internally. I don't see that polling a node would ever change its internal state directly. (unless it was LT1017-LT1020) Of course when polled all turnouts and sensors will respond which surely would change some logic state in JMRI that could in turn send changes.

Dick :)

On 06/16/2018 11:43 AM, Gary Hinshaw wrote:
Ah yes.  I forgot to mention that I did try that, and it had no effect.  The problem there is that the state in the signal head table is Red, as it should be, and I think (correct me if I'm wrong) Refresh Layout will prompt CATS to issue Red again, but this has no effect because JMRI thinks the signal is already Red.  The only way to change the LEDs in this condition is to first change from Red to anything else (then back to Red if desired).  I can do this manually in the signal head table.

I agree that the Signalman should be write-only, and that is what I see in the polling results: when the command station polls all the turnout states when I turn on track power, the Motorman decoders all correctly report back the state of the physical turnouts, but the Signalman does not report the turnouts associated with the signal heads.  Nonetheless, based on watching the Monitor Loconet window, it seems the act of polling is what puts the board in the flashing red state.

I think CATS and JMRI are both behaving as expected here and my issue is with the Signalman going rogue, either because I have mis-programmed it, or because of a firmware glitch.  Hopefully Dick can help me sort this out.