How are branches scanned?

I understand how rungs are scanned in the AB PLC world. But what I am unclear on is how branches are scanned, and how bits are updated. Consider the following:

I'm looking at a bit of logic in RSLogix 5000. (Not mine) It goes something like this:

--]EQU[---------]TareWarn[--------------(CmdStateDN)--------

             |                                        |

             |-]CmdStateDN[-]XIC[-]XIC[-(CmdStateDN)--|

             |                                        |

             |-]CmdStateDN[-]EQU[-]EQU[-(CmdStateDN)--|

             |                                        |

             \-----]CmdStateDN[------|MOV 1|---------/

                 |                                 |

                 \-] / CmdStateDN[------|MOV 2|----/

Here is my question: How is each branch scanned if the result of EQU is true?

My instinct tells me that once "EQU" AND "TareWarn" are true, then "CmdStateDN" will energize (OTE). At which point all of the following branches would be true during THAT scan except for the last. (XIO) If that is the case, why the multiple XIC of "CmdStateDN"? Why not just have it once?

Or is each branch scanned once during each PLC scan, stepping through each branch?

None of my schooling, nor any of the AB documentation is real clear on this.

Regards,
Mike

Welcome to the forum!

Your instincts are partially correct. The topmost branch gets scanned first, followed by each branch below.

BUT if I understand correctly, there are three OTE CmdStateDN instructions?!? If so, then CmdStateDN gets evaluated in each branch based upon what happened in the previous branch. This is an extremely poor programming practice IMHO.

For example, lets say that the conditions of this logic:

--]EQU[---------]TareWarn[--------------(CmdStateDN)--------

cause CmdStateDN to be true, so CmdStateDN=1.

Now we go down to the next branch.
|-]CmdStateDN[-]XIC[-]XIC[-(CmdStateDN)--|
CmdStateDN=1, but if one of the XIC instructions is false, then CmdStateDN now changes to 0. Note that if CmdStateDN=0 from the top branch, there's no way for that tag to change to 1 in this branch or the third branch as CmdStateDN=1 is a pre-condition.

Now we go to the third branch, in which CmdStateDN can only be turned on if the two previous branches produce CmdStateDN=1 and the two EQU instructions are true. Make sense?

The last two branches are move statements but only one will be executed if the initial EQU is true.

try this trick ...

double-click the rung number - then double-click it again if necessary ...

this will open the ASCII entry window right above your ladder window ... (note if it says "Neutral" just change it to "ASCII" ... this will not affect how your processor scans - only how the text is displayed) ...

the rung's "order of execution" is now spelled out for you - step by step ... just read it from left to right - and your questions should all be answered ...

and welcome to the forum ...

RonJohn

Duh!

Your explanation makes complete sense. I didn't realize it, but I was mistakenly interpreting the OTE as an OTL.

It looks like the OP (Original Programmer) was using the same bit to ensure conditions occurred in sequence before advancing the logic. Makes sense.

Regards,
Mike

Ron Beaufort said:

try this trick ...

double-click the rung number - then double-click it again if necessary ...

this will open the ASCII entry window right above your ladder window ... (note if it says "Neutral" just change it to "ASCII" ... this will not affect how your processor scans - only how the text is displayed) ...

the rung's "order of execution" is now spelled out for you - step by step ... just read it from left to right - and your questions should all be answered ...

and welcome to the forum ...

Click to expand...

Thank You Ron B,

Good information. You have answered another question I was pondering. Can I OTE or OTL a bit, then perform an XIO or XIC on that same bit a branch down? That is, does the bit update instantly during that scan, or on the next scan.

Interpreting the ASCII text answered that for me, thanks to your guidance!

Regards,
Mike

you're welcome ...

incidentally, the "write-to-a-bit" then "read-the-same-bit" approach that you've shown is "often" a throwback for a programmer who is more familiar with certain brands of PLCs that will only let you put a LIMITED number of conditions (XIC, etc.) in each branch or rung ... this approach is a "workaround" which allows the programmer to interpret many, many, many "permissives" before allowing a rung to evaluate as true ...

that might not be what you're seeing in your particular case - but the programming approach is used quite frequently for certain types (often German brands) of PLCs ...

Below is my go-to rung for toggling bits on and off from HMI's.
It does demonstrate how AB PLC's scan logic.

 

 PB.HMI  PB.OS    PB.HMI     PB.Toggle  mp_dummy  PB.Toggle

--][-----[ONS]-----(OTU)--------]/[--------()-------(OTL)--

 |               |

 |               |            mp_dummy                      PB.Toggle   

 |               ----------------]/[-----------------(OTU)--

 |      EMERG_STOP                                PB.Toggle

 |---------]/[---------------------------------------(OTU)--

"PB" is a structure with all of the bits needed for the toggle. 'mp_dummy' is just a dummy bit I use for all in-rung logic (in a program, a separate dummy bit is needed for each program; this one is mp_dummy for Main Program).

Normal operation allows for toggling the output bit for each press of the HMI button. The top branch evaluates to see if the toggle bit is off. If it is, mp_dummy is set true, and the output bit is toggled on. Then, the next branch does nothing. If the toggle bit was on, the second branch toggles it off.

The third "Master" branch forces the bit off no matter what if a safety condition is violated.

The OTU of "PB.HMI" in the top branch is to make sure that the HMI button actually releases; a nasty problem with many HMI's, but especially with anything by Rockwell/AB.

One of my pet hates (this may date me) is modern PLC's ability to allow many, many conditions on a rung, facilitating the need to use the scroll bar to navigate to the output instruction. This is a PITA when trying to troubleshoot and fault find quickly, it's the same when the rung is split across many lines. So I tend to use whenver possible the method Ron mentions in post #6 so that I keep all my conditions and output instructions within the viewport.

ie ---|1|---|2|---|3|---|4|---|5|---|6|-------(A)--
-----|A|---|7|---|8|---|9|---|10|---|11|-----(A)--

Steve

nehpets said:

One of my pet hates (this may date me) is modern PLC's ability to allow many, many conditions on a rung, facilitating the need to use the scroll bar to navigate to the output instruction. This is a PITA when trying to troubleshoot and fault find quickly, it's the same when the rung is split across many lines. So I tend to use whenver possible the method Ron mentions in post #6 so that I keep all my conditions and output instructions within the viewport.

ie ---|1|---|2|---|3|---|4|---|5|---|6|-------(A)--
-----|A|---|7|---|8|---|9|---|10|---|11|-----(A)--

Steve

Click to expand...

I see where you & Ron Beaufort are coming from and agree with this method when used for the reasons mentioned. The original example posted, with a new branch for every two instructions, seemed a bit excessive; more confusing than helpful.