LCC - Configuring a Push Button ~WITH~ Indication
A few months ago there was a post on the LCC Groups.IO forum talking about the ability for one of the LCC node I/O points to both act as an INPUT, that is, to accept a push button command, AND act as an output, such as to illuminate an indicating light. This is super cool! Why? Well at an all-in cost of around $3 per I/O point, it's hard to justify a lot of indicating lights on panels. BUT... if we can get a "free" output for each discrete input, well, that is just like having your cake and eating it too! (Never totally understood that analogy, but seems fitting.)
The way this works is the node runs the I/O point as an output for 63 milliseconds, and then for a few milliseconds, it converts the output to an input where it polls the input. So if it detects a "low" or a "high" in this window, it creates the appropriate event. Slick, huh? Timing at 63 ms is fast enough that even if the PB is just momentarily touched, it is enough to trigger, but not long enough for the eye to see a flicker.
So without further adieu, here is a simple tutorial on how to configure a push button with lights in LCC.
First of all the schematic and how to wire. Here is a schematic for a single point.
A few things to note:
So with this in hand, I made up a test panel with push buttons and LEDs. With only one indication per push button, I elected to illuminate the LED when in the non-normal or thrown state of the turnout. In this way an operator leaving the town would just need to look over the panel and see all the indications are OFF, and know the turnouts are thrown the to the normal or mainline position.
Back at the node, I simply made up a short jumper using the ribbon cable to a terminal block, and then out via CAT5 cable.
Once the wiring is done at the layout, it is time to go to the PC and start configuring the node. I am not going to repeat the info needed to get into PanelPro, connect to the LCC network, set up the node, etc. Check out some of my other posts for info on that.
Open the Configuration Dialog box for the I/O node with the push buttons with indication.
Note the tag I gave the point: PBI, which suggests it is a "Push Button with Indication." I have other I/O which is just a push button and for those I used "PB." I am learning, sometimes the hard way, to keep my designations clear. In this case, the PBI is for the ATSF junction.
Next line down is how you configure this magic. Select Alt. Sample Steady Active Lo. This means:
Alt: At first I thought this meant "alternate," as in an alternate way to output the signal. Nope. It means ALTERNATING; as in it will toggle between 2 states, creating 2 events. This is what we need to toggle the turnout position. Now this is very, very powerful. This command is not just toggling ITS OWN memory bit back and forth. If that were the case, if another signal threw the turnout, the PBI I/O would still be looking at what IT THOUGHT the position was and, when pushing the button, switch it to where it already is. But this is not the case in LCC. This command actually tracks the traffic on the LCC bus and remembers where it actually is... and then toggles to whatever the alternate position should be. Slick, eh? Very slick!
Sample: This generates the OUTPUT signal AND polls the input signal every so often.
Steady: Means the output is steady. The light stays on when active. There is an option for the LCC node to output a flashing indication. This could be helpful in some situations.
Active Lo: Defines what the INPUT needs to be to turn ON or ACTIVE. Since the I/O point is normally "high" (and we are not talking the Colorado definition), the push button grounds the I/O and goes to low when pressed. So it is "Active" when "Lo."
Whew! There you have it.
Next down is the Input Function. And yes, to make the magic happen, you HAVE TO turn this to Disabled. Yes. I know. It is functioning as an output. No. Don't configure this line. Trust me. The folks at RR-CirKits say so. It wont work if you configure it any other way.
OK, now on to configuring the events...
But before we talk that, we need to talk about how to keep track of Event IDs. I am not a fan of keeping massive log books or make up new event codes. But at the same time I ran into a bit of a snag configuring LCC nodes. Let me explain.
Up to this point I had always used the LCC node address and default event IDs for my inputs and outputs. But starting to work with a situation where multiple command locations are actuating an output, a turnout in this case, quickly gets confusing. Specifically I could create a turnout throw command from the PC via PanelPro, and I could initiate a turnout throw from the push button. But to make the "Alt" function work, somehow all three nodes (the PC, the turnout node and the push button node) all needed to be looking for the same event. It could even get more complex if I added additional push buttons on opposite sides of an aisle or via some kind of remote panel. Anyway, how to keep track of event IDs?
I settled on a standard to always point to the final control device events. That is to say, in this example, always to use the address of the turnout as the reference event. For example, see the snapshot of a part of my node list below:
Note the new panel I just installed has address 02.01.57.10.00.EF. The turnouts the PBs will operate are on 02.01.57.10.00.52. So I want to use the ...00.52 addresses for the events associated with throwing that turnout, regardless of where it originated from.
So to put this into practice, here is how I set up the Consumer and Producer events - note this is the configuration at the PBs with the ....00.EF node address:
Consumer events 1 and 2 are looking back at the turnout node to properly show the position, in this case whether the indicating lamp is off (normal or closed) or on (open or thrown). Producer events are pointing TO the turnout command to throw.
Keep in mind there is no reason to have to manually enter all these numbers. Have both nodes open and use the "Copy" and "Paste" features on the associate lines to simply copy and paste the right addresses where needed.
At the turnout, it looks like this:
Recall from previous posts, I am using "CP" to indicate a control point or switch. Below are the consumer and producer event configurations. Note the producers here tie back to the consumers of the push button I/O (well, if I got a screen shot of producer event 2, it would line up - they are events ...36 and ....37), while the consumers line up with producer events on the PB (events ....30 and ....31).
When it was all said and done, the lights lit up appropriately, regardless of whether the command to throw the switch came from the PC or the push button. And the indications on both the PC and the LEDs lined up, regardless of where the command came from. And keep in mind, on the panel, we are getting TWO I/O functions - an output and an input - off of one physical I/O point. A very powerful feature!
Hope this has been helpful. Let me know if you have any questions.
The way this works is the node runs the I/O point as an output for 63 milliseconds, and then for a few milliseconds, it converts the output to an input where it polls the input. So if it detects a "low" or a "high" in this window, it creates the appropriate event. Slick, huh? Timing at 63 ms is fast enough that even if the PB is just momentarily touched, it is enough to trigger, but not long enough for the eye to see a flicker.
So without further adieu, here is a simple tutorial on how to configure a push button with lights in LCC.
First of all the schematic and how to wire. Here is a schematic for a single point.
 |
| Red lead indicates positive (+), green is negative (-) and black is the I/O lead. |
A few things to note:
- The I/O point is sensing the difference in voltage between R1 and R2. As such, the two need to be enough different to assure a good "low" signal when pushing the PB. I show a 10K/1K pair, so figuring a 5VDC input, we would have 0.5V when the PB is pressed. Plenty low enough for low. When the PB is not pressed, the 5V level is fed directly to the I/O point via the R1 resistor and LED.
- The R1+R2 resistance should be set up for whatever you want for the LED. I used some amber LEDs that are incredibly efficient. Turns out 2mA is plenty bright for panel indication! So on 5VDC, 10K ohm worked great.
- Of course, you could daisy chain the +5VDC and Ground to as many push buttons as you like.
- Note the Tower-LCC and Signal-LCC nodes include +5 and ground right on the I/O connector, making it easy to get interrogation voltage.
- Keep in mind some of the I/O points on the Tower-LCC have a fairly low max allowable current, so those may not work with this circuit.
So with this in hand, I made up a test panel with push buttons and LEDs. With only one indication per push button, I elected to illuminate the LED when in the non-normal or thrown state of the turnout. In this way an operator leaving the town would just need to look over the panel and see all the indications are OFF, and know the turnouts are thrown the to the normal or mainline position.
 |
| A simple panel - masonite painted white, a 1/4" drill, an 1/8" drill, and a Sharpie! |
 |
| Amber indication shows "thrown" switches. |
 |
| All dark indication shows all switches lined for main or in closed position. |
 |
| The interrogation power was daisy chained between push buttons (red and green wires), with the current limiting resistors and LEDs wired at the panel. The blue and blue/white wire are for the actual I/O point. I simply used CAT5 cable between the LCC node and the panel. Don't look too closely at the quality of the woodwork or the painting... |
Back at the node, I simply made up a short jumper using the ribbon cable to a terminal block, and then out via CAT5 cable.
 |
| Since the panel was 10' or so from the LCC node, I elected to convert to CAT5 cable. |
Open the Configuration Dialog box for the I/O node with the push buttons with indication.
Note the tag I gave the point: PBI, which suggests it is a "Push Button with Indication." I have other I/O which is just a push button and for those I used "PB." I am learning, sometimes the hard way, to keep my designations clear. In this case, the PBI is for the ATSF junction.
Next line down is how you configure this magic. Select Alt. Sample Steady Active Lo. This means:
Alt: At first I thought this meant "alternate," as in an alternate way to output the signal. Nope. It means ALTERNATING; as in it will toggle between 2 states, creating 2 events. This is what we need to toggle the turnout position. Now this is very, very powerful. This command is not just toggling ITS OWN memory bit back and forth. If that were the case, if another signal threw the turnout, the PBI I/O would still be looking at what IT THOUGHT the position was and, when pushing the button, switch it to where it already is. But this is not the case in LCC. This command actually tracks the traffic on the LCC bus and remembers where it actually is... and then toggles to whatever the alternate position should be. Slick, eh? Very slick!
Sample: This generates the OUTPUT signal AND polls the input signal every so often.
Steady: Means the output is steady. The light stays on when active. There is an option for the LCC node to output a flashing indication. This could be helpful in some situations.
Active Lo: Defines what the INPUT needs to be to turn ON or ACTIVE. Since the I/O point is normally "high" (and we are not talking the Colorado definition), the push button grounds the I/O and goes to low when pressed. So it is "Active" when "Lo."
Whew! There you have it.
Next down is the Input Function. And yes, to make the magic happen, you HAVE TO turn this to Disabled. Yes. I know. It is functioning as an output. No. Don't configure this line. Trust me. The folks at RR-CirKits say so. It wont work if you configure it any other way.
OK, now on to configuring the events...
But before we talk that, we need to talk about how to keep track of Event IDs. I am not a fan of keeping massive log books or make up new event codes. But at the same time I ran into a bit of a snag configuring LCC nodes. Let me explain.
Up to this point I had always used the LCC node address and default event IDs for my inputs and outputs. But starting to work with a situation where multiple command locations are actuating an output, a turnout in this case, quickly gets confusing. Specifically I could create a turnout throw command from the PC via PanelPro, and I could initiate a turnout throw from the push button. But to make the "Alt" function work, somehow all three nodes (the PC, the turnout node and the push button node) all needed to be looking for the same event. It could even get more complex if I added additional push buttons on opposite sides of an aisle or via some kind of remote panel. Anyway, how to keep track of event IDs?
I settled on a standard to always point to the final control device events. That is to say, in this example, always to use the address of the turnout as the reference event. For example, see the snapshot of a part of my node list below:
Note the new panel I just installed has address 02.01.57.10.00.EF. The turnouts the PBs will operate are on 02.01.57.10.00.52. So I want to use the ...00.52 addresses for the events associated with throwing that turnout, regardless of where it originated from.
So to put this into practice, here is how I set up the Consumer and Producer events - note this is the configuration at the PBs with the ....00.EF node address:
Consumer events 1 and 2 are looking back at the turnout node to properly show the position, in this case whether the indicating lamp is off (normal or closed) or on (open or thrown). Producer events are pointing TO the turnout command to throw.
Keep in mind there is no reason to have to manually enter all these numbers. Have both nodes open and use the "Copy" and "Paste" features on the associate lines to simply copy and paste the right addresses where needed.
At the turnout, it looks like this:
Recall from previous posts, I am using "CP" to indicate a control point or switch. Below are the consumer and producer event configurations. Note the producers here tie back to the consumers of the push button I/O (well, if I got a screen shot of producer event 2, it would line up - they are events ...36 and ....37), while the consumers line up with producer events on the PB (events ....30 and ....31).
When it was all said and done, the lights lit up appropriately, regardless of whether the command to throw the switch came from the PC or the push button. And the indications on both the PC and the LEDs lined up, regardless of where the command came from. And keep in mind, on the panel, we are getting TWO I/O functions - an output and an input - off of one physical I/O point. A very powerful feature!
Hope this has been helpful. Let me know if you have any questions.
This is good stuff and I appreciate you posting this up. LCC information is still very much in its infancy.
ReplyDeleteHave you given any thought into how you might drive an set of LEDs so you can give color indications on the route that a turnout might be set to?
I've seen a fair amount of control panels where you get a green indication on the route selected or you get green on the turnout for closed and a red or yellow for thrown. I'm trying to puzzle that out right now. Thinking you would almost set them in series but I think that would require 2 I/O lines versus the single you are using now. Maybe a little logic IC (maybe a inverter?) would be the ticket there. Hmm.