RSLogix 5000 Instruction Type Needed

[KoalaWala]

I really feel new to this reading this logic and not understanding the purpose of several things here but I plugged it all in and it seems to do what I want. I really appreciate you taking the time to write this, I really wasn't expecting that. So, thank you.

I'm assuming the storage bits I fill in myself? Like #ST9.7 =1 #ST9.8 =2 and #ST9.9=3?

Then I just make a rung if #ST9.1, #ST9.11, and #ST.13 all equal 1, output message for line loss, etc.

And yes, the PLC is responsible for actually sending out the texts messages directly. It seemed a little unnecessary to pay companies a ridiculous monthly fee for a service that I didn't see could be easily integrated into a PLC.

 

[drbitboy]

I would hope the comments would explain what is going on, but I find cogent comments are difficult to write when one is so close to the logic. See TL;DR below where I try to do a better describing the logic; I suspect the most difficulty comes from the TOF, hopefully that is resolved below.

Yes, ST9 is a "Data File" in RSLogix 500 that contains 18 string registers, ST9:0 through ST9:18; see page 18 of the PDF.

TL;DR

If I were going to replace them with a number, I would probably use a system like you seem to be working towards.

• 1 or 2 or 3 for the single-, double-, and triple-blinking reds, and 1 for the continuously blinking green
• 4 for Red unknown
  • I.e. a counted non-zero number of blinks that is not 1 or 2 or 3;
    • This should never happen, but it did help me find a bug while developing
    • It could perhaps happen if a triple-blink fault could be acknowledged before the 650ms timer expired and was immediately replaced by another blinking fault
• 0 for either light on solid (Green Normal ... and Red Reversal)
• -1 for "... is off"
• -2 for "... in transition"

There are three groups in ST9, horribly mixed up:

• GREEN_STATUS (ST9:16) and RED_STATUS 17) are the final interpretation that you can send somewhere else.
• GREEN_LATEST, GREEN_LAST, and GREEN_LAST_2 (ST9:0, :10 and :12) are a queue, or FIFO if you will, that implements a voting scheme using the last three interpretations of the green light.
  • When a new interpretation is made, usually at the expiry of a timer, the oldest interpretation, in _LAST_2, is lost as the value of _LAST is COPied into _LAST_2, and the most recent interpretation before the new current interpretation, in _LATEST, is COPied into _LAST, and the new current interpretation is COPied into _LATEST.
  • If they are all the same identical string, then GREEN_STATUS will be that value (e.g. "Green is off" ofr "Green Normal (Relay Off)").
  • If they are not all the same identical string, then GREEN_STATUS will be assigned the value "Green is in transition" from GREEN_TRANSITION ST9:14.
• RED_LATEST, RED_LAST, and GREEN_LAST_2 (ST9:1, :11, :13) are analogous to GREEN_LATEST, but for the red light.
• The rest are essentially static strings to be COPied into the other strings mentioned above.

All of the logic is based two types of timer instructions, TON and TOF, and CTU (CounT-Up) counters.

• The green light uses one TON timer and one counter.
  • The TON (T4:0; Rung 0001) implements a repeating 5s (5000ms = 5000 * 0.001s; T4:0.PRE is 5000) timing window,
    • During which window the behavior of the green light is interpreted by counting rising edges (light off to light on transitions).
  • The boolean T4:0/DN is 1 at the timer expiry for one-scan only (Vasily) every 5s,
    • during which scan
      • the action of the green light over the previous 5s is interpreted:
        • The count of rising edges of the green light determines the interpretation:
          • If 2 or more rising edges were counted while the timer was timing (T4:0/TT was 1) and the green light is flashing
            • This is detected by the counter being done (C5:0/DN is 1; C5:0.PRE is 2)
            • Note that T4:0/TT will be 1 from the time the timer starts until just before it completes i.e. when T4:0/DN is 1, T4:0/TT will be 0.
          • If 1 rising edge was counted while the timer was timing, then it is assumed that the green light was on at the start of timing and continued on solid throughout. N.B. this may be a bad assumption, e.g. if green was off and started flashing at the very end of the 5s, but that will be resolved via the queue/FIFO voting scheme.
          • If no rising edge was counted while the timer was timing, then the green light was off for the entire timer duration.
  • The counter (C5:0; Rung 0002) counts rising edges of the green light, while the timer is timing, i.e. while T4:0/TT is 1.
    • The counter preset (T4:0.PRE) is 2, so the result will be 0, 1, or 2, i.e. off solid, on solid, or flashing, respectively.
      • It might have been been less ambiguous to count falling edges, but then it would have to check the state of the light to distinguish between on solid and off solid.
  • The counter and timer are both reset at the end of the scan when the timer expires.
    • Note that the using a RESet instruction on counters does not always result in desired behavior
      • Specifically, if the signal that generates the rising edge on the input rung of the CTU instruction is still TRUE when the RESet executes, and remains TRUE on the next scan, then that CTU will immediately count to 1 on that next scan, even though there has been no rising edge of the signal.
      • In this case, however, the RESet occurs on the timer expiry event, so the XIC T4:0/TT will evaluate to FALSE on the current scan and there can be an true rising edge on the next scan.
• The red light uses one TOF and one CTU to count flashes, one TON to detect solid, and one TON to detect solid off
  • An interpretation of the red light status is made on expiry of any one of the timers (Rungs 0010-0013)
  • The TOF - Timer OFf delay - is an interesting beastie, and may take some time getting used to.
    • See the behavior of the TOF at this link.
    • It could be called a pulse stretcher; it's /DN bit
      • always follows the input rung high (TRUE) by assigning a 1 to T4:/DN,
      • but delays following the input rung's high-to-low (TRUE-to-FALSE) transition until the input rung has been continuously FALSE for the duration of the timer
        • which includes resetting the timing if the input rung goes TRUE again before timer expiry
  • In this case (Rung 0007), the TOF input rung is [XIC red-on], and the TOF T4:2.PRE(set) of 650ms is
    • longer than the duration of any single flashing pulse, on or off,
    • but shorter than the off-time following any singlet, doublet, or triplet of flashing pulses.
  • So the TOF will put, or keep, 1 as the value of T4:2/DN, and the timing will be reset, at every subsequent flash i.e. 0-to-1 transition of the red light,
    • And only when the light has been off for longer than 650ms, i.e. into the second second of the fault cycle, will the timer expire (T4:2/DN become 0).
    • So T4:2/DN transitioning from 1 to 0 is usually an indicator that one or more flashes have been detected
      • The exception is that if the light transitions from solid on to solid off, that will be interpreted as a single flash; again, that misinterpretation will be a single event and be filtered via the voting scheme.
    • In the meantime, counter object C5:1 has counting the falling edges (Rung 0008) of the red light while the TOF is timing, and each falling edge is one flash.
      • So the expiry of the TOF - i.e. end of presumed flash sequence - is when that count is interpreted (Rung 0011) as to the particular flashing fault (Unbalance or over- or under-voltage)
        • and the counter is RESet in anticipation of the next flashing sequence.
  • The two TON instructions are simple Timer ON delay devices; one detects red on solid; the other detects red off solid.
    • Both are repeating timers, with the repeats implemented via RESets on expiry.
    • T4:1 will never expire, and T4:1/DN will never be 1, unless the red light has been on solid for 5s (3000ms),
      • So T4:1/DN becoming 1 indicates Red Reversal (Rung 0012)
    • T4:3 behaves similarly, but detects 3000ms of red off solid,
      • So T4:3/DN becoming 1 indicates red solid off
    • Since all flashing fault sequences have a 2s cycle, which is shorter than these two TONs' .PREsets, neither TON can expire if the red light is flashing, as the off or on part of the flashing fault sequence will reset one or the other TON timer at some point.
      • There will probably be some edge cases when transitioning from one fault sequence to another, but the queue/voting scheme should keep that from being the final interpretation placed in string RED_STATUS (St9:17; Rung 0014).
  • There are also resets of the red counter as well as of the TON, but not TOF, timers on Rungs 0011-0013.
    • Hopefully that logic is obvious.
    • N.B. a TOF timer structure does not need to be reset; the rising edge of the TOF instruction's input rung is the only way to effect a reset.

 

[KoalaWala]

I think I just needed to wake up a little in the morning as I jumped on this right away. After waking up and reading it over several times (and demonstrating it in person) it all seems to be coming together. Thanks again.