Multiple OTE in subroutines?

[Davek0974]

It seems very bad to have one OTE address being used in more than one place, seems that only the last entry scanned is used?

But what about the same OTE address being used in different subroutines that are mutually exclusive or become so when needed?

Scenviro...

Subroutine 1 has OTE 1 in it
Subroutine 2 has OTE 1 in it

JSR to each rung has a mutually exclusive bit so only one subroutine is live at any one time.

Is this ok?


The other option is to place the all the state outputs in the main ladder and use lots of AND contacts to energise the single OTE bits from each subroutine.

 

[dginbuffalo]

I've seen 80 subroutines with the same OTE in it. You can make it work.... But good luck trouble shooting it. It's usually a nightmare. I would NEVER do it unless completely necessary. ANd i've never run into it being necessary!

 

[Davek0974]

So you would advocate having all the state-OTE's in one place and have each subroutine connect with stacked AND contacts?

Seems reasonable.

 

[TheWaterboy]

I've done exactly that when treating ladders as state machines. I have a 10 ladders with the same bits in them. Just gotta make sure you OTU the bits you aren't directly setting with OTE.
edit: exactly as you state in your first post.

 

[Ron Beaufort]

seems that only the last entry scanned is used?

I don't think that your statement (above) is the main point of your question - but technically it is incorrect - especially when working with ControlLogix and CompactLogix systems ...

feel free to ignore this post - if it has nothing to do with your question ...

 

[Luke_Mages]

So you would advocate having all the state-OTE's in one place and have each subroutine connect with stacked AND contacts?

Seems reasonable.

if you have a bunch of subroutines you could use compare commands on an output routine...sort of the same way you would set up a sequencer. Makes troubleshooting much easier and keeps everything very organized.

 

[Davek0974]

if you have a bunch of subroutines you could use compare commands on an output routine...sort of the same way you would set up a sequencer. Makes troubleshooting much easier and keeps everything very organized.

Any chance of an example code?

 

[Davek0974]

I don't think that your statement (above) is the main point of your question - but technically it is incorrect - especially when working with ControlLogix and CompactLogix systems ...

feel free to ignore this post - if it has nothing to do with your question ...

I'm only going on what I've read so far, surely if the plc scans in sequence then whatever state is required by the last entry would be the state of the bit set?

 

[Luke_Mages]

Any chance of an example code?

I've attached a screen shot. this way you can consolidate branches...for example if routines use the same outputs and you number them in sequence you can use lim functions to include that range of numbers...so if an output is energized on 7 of your 8 sub routines you would make a lim function true for 1-7, rather than 7 separate xic rungs.

 

[bernie_carlton]

Another way to approach this (uses of the same output in multiple subroutines) is, before the first subroutine call, do an OTU of the output. Within each subroutine if called for use an OTL of the output. The result is the output being ON if any active subroutine is calling for it to be on. (Note: with Compact/Control Logix systems the 'output' should be an intermediate bit as you may get - due to the asynchronous nature of the output relative to the 'continuous scan'- a turn off of the actual output between the OTU and the first OTL.) This results in a command labled as 'OROUT' is AutomationDirect DL CPUs. (Like Allen Bradley they are branching into multiple CPU families. As far as I know it they still have 'synchronous to main scan' outputs.)

Again, the ease of troubleshooting is questionable.

Otherwise let each subroutine control a unique bit location 'Subroutine X output ON'. After the last subroutine call place a parallel condition rung. Each parallel branch will have a contact 'Subroutine X is enabled' and another contact 'Subroutine X output ON'. The parallel branches lead to the actual output. This should ease the troubleshooting problem.

 

[Ron Beaufort]

I'm only going on what I've read so far, surely if the plc scans in sequence then whatever state is required by the last entry would be the state of the bit set?

well, that's the "trick" ... the ControlLogix and CompactLogix systems don't "scan in sequence" ... specifically, the I/O signals can be transferred

(A) from the input field devices to the processor - and
(B) from the processor to the output field devices –

at ANY POINT of the ladder logic routine ...

here's a simple example:

consider two OTEs – both addressed to the same output device (for example: a lamp) ...

suppose that the first OTE is conditioned as FALSE - to "go write a ZERO into the bit/box" ...

suppose that the second OTE is conditioned as TRUE - to "go write a ONE into the bit/box" ...

Question: would the output device in the field be ON – or OFF – or FLICKERING ? ...

(A) Answer for an SLC/MicroLogix system: the output device would be ON ...

(B) Answer for a ControlLogix or CompactLogix system: the output device would be FLICKERING ...

going deeper – even with a simple SLC or MicroLogix system - consider your original statement:

seems that only the last entry scanned is used

technically speaking, the word "used" could be troublesome ...

for an example, let's assume that multiple OTEs are actually being "scanned" by the processor ... then ALL of the OTEs would be "used" ... that is - "used" in the sense of being "executed" (operated on) by the processor ... specifically, the processor would not "skip over" the leading OTE instructions ...

but your thought was probably that only the last OTE would have any real effect on the actual output device in the field ... that thought would be correct ...

even so - sometimes the so-called "double coil" effect will cause unexpected results whenever the ONE or ZERO status of the bit/box for the OTEs is used as a condition (XIC, XIO, etc.) in various parts of the program code ...

party on ...

 

[bernie_carlton]

Thank you Ron for you observations. The important thing is that nothing has relieved you of the task of knowing how your system works.

PLCs are not like a toaster that you plug in and you just 'know how it works.' (Actually my toaster has a 'bagel' setting which works quite well, toasting just the insides.) You must READ (that terrible word) and UNDERSTAND (another of those words!) how your system works in order to avoid strange surprises.

 

[Luke_Mages]

Thank you Ron for you observations. The important thing is that nothing has relieved you of the task of knowing how your system works.

PLCs are not like a toaster that you plug in and you just 'know how it works.' (Actually my toaster has a 'bagel' setting which works quite well, toasting just the insides.) You must READ (that terrible word) and UNDERSTAND (another of those words!) how your system works in order to avoid strange surprises.

ha...that toaster setting comment just blew my mind...now I gotta buy some bagels...

 

[Geospark]

...Otherwise let each subroutine control a unique bit location 'Subroutine X output ON'. After the last subroutine call place a parallel condition rung. Each parallel branch will have a contact 'Subroutine X is enabled' and another contact 'Subroutine X output ON'. The parallel branches lead to the actual output. This should ease the troubleshooting problem.

Bernie,

For me, this is on the money and how I tend to do it.

It's the simplest, cleanest, least ambiguous and easiest method to troubleshoot.

It also happens to be Rockwell's recommended method for avoiding "double coil syndrome" i. e. having more than one OTE instruction for the same tag address. Memory is cheap compared to downtime.

Regards,
George

 

[The Plc Kid]

@ The OP.

In simple terms Buffer your I/O and avoid all these issues.

Buffer your I/O and someday someone other than you troubleshooting or making changes will thank you instead of curse you.

Do a forum search for Buffering I/O. IMHO it's stupid not to buffer I/O.