RSLogix 5000 rev 19 - multiple OTE instructions??

Can I use multiple OTE instrutions for the same tag at various different routines inside the program? I know that doing this would cause issues in the earlier versions, but is it still the case with rev 19 as well?

Thanks rkukl. Typically in the past when I write code, I try not to use multiple OTE instructions for the same tag. But I have inherited code from few guys who are new to RSLogix. They have used multiple OTE for the same tag frequently. I will modify the code as per your suggestion. Thanks.

It's not a version issue, it's a logic issue. Version 19 is not going to treat your multiple OTEs any differently than ver 2. It's just bad logic. The software will warn you about it, but it will let you do it.

OG

You mean Double coil syndrome. Read here
http://www.plctalk.net/qanda/showthread.php?t=4365
http://www.plctalk.net/qanda/showthread.php?t=51585

sorry i write in the wrong thread.

Thanks OperaGhost. You are right. The software lets me do it and issues a small warning. I agree it is not a good practice to do it. I prefer using OTL / OTU instead. Using OTL/OTU has moire control.

OTL and OTU are useful in some applications but OTE with a seal in circuit work equally well, just make sure you use them correctly.

As already stated, it's not a version issue at all, in fact it's not A-B specific either.

ALL plc's work by scanning the user program - from left to right on the "rungs", and rungs from top to bottom (aside - Anyone know of any exceptions to this?, I know of one....)

It is the understanding of what an OTE (or similar in other machines) actually does that explains the much-maligned "double-coil syndrome".

Put simply, an OTE instruction just writes a "0" or a "1" into the specified memory location - that's all.

Of course when we start to use OTE's more than once on the same memory location, there are things we have to be aware of....

1. The memory location may change state multiple times in one scan. When we inspect it in our program with XIC or XIO, it will be at the state it was last written, i.e the last OTE definitely will have set it to a 0 or a 1, an OTL may have set it to a 1 (if the rung evaluated as true), and an OTU may have set it to a 0 (if the rung evaluated as true). When we look at it with our programming software, we will not get a clear picture of whether it is on or off, nor any synchronisation to the logic execution.

2. On most PLCs, physical outputs only get written to the output modules at the end of the program scan. In which case the "last-one-wins" rule will apply. Whatever state the last rung that writes to the output memory address, will be sent to the output hardware. This could be considered bad practice, although perfectly valid logically.

On some PLCs, notably Logix5000 systems (ControlLogix, CompactLogix, FlexLogix, etc., the output data is written to the output modules asynchronously to the program scan, so the "last-one-wins" rule will not apply. On these asynchronous systems it is definitely bad practice to have multiple OTE's of physical outputs.

I could quote examples of where we might want to use an OTE more than once. It's not a programming flaw (and hence only a "warning" in RSLogix) that will stop the logic working, but a technique that can save memory, and make the code more readable. We just have to be aware of the "rules" and the hardware platform we use.

To hang a global "bad practice" label on the use of multiple OTEs is overkill IMHO.