Two OTEs in series?

I was studying a program for a machine at work, and I came across this rung. I never seen two latch coils in series in a rung. The program is written with Studio5000 for CLX5000. I had deleted tags for possible proprietary issue, but this really is a part of a running program. How could it be? I know RSLogix does not even let me download the program because of the error.

RSLogix 500 would not accept that rung, however Studio 5000 (formerly RxLogix 5000) does accept series OTL our combinations of series OTL/OTU/OTE and any other type of "Output instruction".

Logix. 5000 software lets you do that and it's perfectly normal to do so. Judging that their is no tags on the OTL instructions I can't really say what it's doing in the program, however I have programmed In that manner before. Remember an OTL instruction goes to your specified output data table and writes a 1. If the preceding condition is false it does nothing. So it is perfectly normal to have them in series it just does the execution from left to right. So in Essenes you can trigger all your output latches on one rung as opposed to using multiple rungs or branching your output

So, obviously OTE1 must be energized in order for OTE2 to be energized. So, OTE1 in series with OTE2 in one rung is simply two rungs combined into one? (OTE1's XIC -----> OTE2 being the 2nd rung) I guess that could simplify things.

Thanks.

Another equivalent would be the two output latches on two parallel branches. For me it is better visually to use the parallel branches.

@unsaint32, in your statement "So, obviously OTE1 must be energized in order for OTE2 to be energized"

That is not the case, refer to what Bernie said he gave a good example the two OTL's in series act the same way when you would normally have branched outputs, in that the state of one of the OTL has no relevance to the other. So you can think of it as OTL's in parallel.

EDIT*** From a programming standpoint it is fine, but i can see it cause a problem when sparkie is trouble shooting at 3AM and can't figure out what that rung is doing. With the abundance in memory, personally i would just do a parallel branch as Bernie suggested so you can decipher the code visually.

I know you can do it and technically there is nothing wrong with it but when I see that I always picture a relay or a contactor only getting 60V lol.

@ allscott i believe that is what the problem is. Yes ladder logic is designed in such a manner to best relate to actual relays and coils, however thinking that the program will work in such a manner is what gets ya. I always envision it as a set of instructions that execute in a sequence, more so as you would look at a computer program. This may be obvious but, understanding what each instruction does and order of execution is vital then when you see scenarios like that series OTL's it wont be confusing

dbh6 said:

@ allscott i believe that is what the problem is. Yes ladder logic is designed in such a manner to best relate to actual relays and coils, however thinking that the program will work in such a manner is what gets ya. I always envision it as a set of instructions that execute in a sequence, more so as you would look at a computer program. This may be obvious but, understanding what each instruction does and order of execution is vital then when you see scenarios like that series OTL's it wont be confusing

Click to expand...

I learned ladder logic first before learning any other programming language so I have the opposite problem when writing code in more traditional programming languages. I agree understading how a PLC scans is a bit of a hurdle for people that come from a computer programming background.

Do not use AB but you can use the scan of the program to your advantage to minimise code and have more ladder on a page by putting things in series. I do that regularly with compares and maths functions - 1 line of code instead of 5 or 6. Can see all the maths working in 1 line as well - really useful. I often use a self resetting timer to do maths functions for example - no need for leading edge stuff either - the self resetting timer is only on for one scan so not chance of having the math take place more than once. You have to understand how your hardware firmware works to become more efficient.

I know you can do it and technically there is nothing wrong with it...

Click to expand...

If you want to be technical about it, then in Boolean math, two instructions in series (combined with AND function) are not always equal to or equivalent to the same two instructions in parallel (combined with OR). In other words, it would cause an error.

But then Rockwell abandoned Boolean math long ago for a mis-mash of made-up PLC instructions.

Its not a lot different from some instruction list languages.

Lets look at a really old PLC, the GE series 1 (A Koyo which is still sold by AutomationDirect)

Take this ladder

   01                        11 

---] [-----+------------+----( )---

           |            |

   02      |            |    12   

---]\[-----+            +----( )---

Which would be programmed like this:
STR 01
OR NOT 02
OUT 11
OUT 12

Notice that there is not anything in the instruction list to create an additional branch. The outputs are in fact in series in the list. This is really common in lots of different brands.

Now go back to your AB program. Double click the rung number of a rung with two outputs in series to open the mnemonic editor and look at the mnemonic line of instructions that is actually executed when the rung is scanned. Now change the rung so the two outputs are in parallel branches and look at it in the mnemonic editor again. You'll see that there are two extra instructions in memory to create the branch that now have to be fetched and executed when the rung is scanned.

The outputs are in fact in series in the list.

Click to expand...

Yes, they are shown in series, but in ladder logic, there is an implied Boolean AND between them, just as for two contacts in series there used to be an implied OR between them. With the new version, for any two outputs A and B, now the logic says (A AND B) = (A OR B). Only for cases where both A and B = 1 or both equal 0 is that logic correct. So you can not longer look at the statement logic and reverse-engineer the Boolean logic for that circuit. You must know the logic first and always work forward, never backwards because then you have no way of knowing which series of instructions are true AND statements.

It really is very simple - instructions in the code are either CONDITIONAL or UNCONDITIONAL

Conditional instructions (e.g. XIC XIO EQU GRT etc.) will determine whether the Rung Logic Continuity remains true (it starts out that way for each rung).

Unconditional instructions (e.g. OTE OTL OTU MOV PID etc.) just tell the controller to do something based on the current state of the Rung Logic Continuity. But most importantly unconditional instructions do not change the Rung Logic Continuity.

On that premise it is perfectly OK to have "coils" like OTE, OTU, OTL, in series an a rung or branch, just in the same way it is OK to have 2 or more MOVs in series.

All that has been done in Logix5000 is removed the 40+ year-old analogy to electrical relay circuits.

Removing branches where they are not needed reduces scan time, and uses less controller memory.

Think of it this way:

((A or B) AND C) = ?

After solving the boolean equation you will have either a 1 or a 0 in the processor's results register. Now you need to store that result in memory. Storing the answer does not erase it from the processor's register. It stays there until a new value is loaded over it, so the solution to the boolean equation is there to be stored again in a second, or even a third location in memory if desired. No additional boolean computations are performed on the result, it is merely copied to multiple memory locations.