One OTL --(L)-- and several OTU --(U)--. Is it fine ?

[bce123]

passwordg ,well i guse paully left try this: http://www.plctalk.net/qanda/showthread.php?t=65861

 

[TimWilborne]

You are correct, using an OTE in multiple rungs doesn't work as the last OTE which is scanned by the PLC wins!

Just browsing the threads this evening so first let me warn, I didn't read everyone's post in detail. This thread is way too out of control to help the OP at this point but I just wanted to try to make a point if Pauly, Peter, and a few others that aren't just trying to post static to increase their post count and might still be listening.

This statement really stuck out to me, mainly because I'll be teaching on this very thing tomorrow to my students. Technically the evaluation of the instructions in the rung preceding the last OTE encountered during a PLC scan will be evaluated for a true or false condition and the OTE instruction will act accordingly, but to say "the last OTE which is scanned by the PLC wins!" is a little bit misleading.

Ron does an excellent job of showing the pitfalls of this statement in the following video.
http://ronbeaufort.com/youtube_lesson_10.htm

passwordg, if you happen to still be following this thread, watch the video carefully and understand the step by step analysis. You can use this same analysis to truly understand and evaluate the conditions of your multiple OTLs and OTUs and correctly predict their outcome or figure out why their outcome is not always predictable.

If you learn to understand and use this method then you can use 1000 OTLs, OTUs, and even OTUs addressing the same bit in a program. Now I didn't say I recommended it, but even that recommendation would be better than making a rule that limiting the number of output instructions on a bit just because you are unsure of how the program code is affecting it.

 

[limsgp]

Actually, I feel that there is nothing wrong with many OTL all over the place.

For e.g. to latch a "Fault" or "Alarm" bit. There may be various situations at different rungs giving rise to the fault condition, so, wherever it is needed, just put a OTL there.

And, just to be relevant to TS's (or OP) case, there could be a "System_OK" bit. Any fault in any place could OTU that bit, and indicate that the system is "Not ready". While a reset or initialize rung could OTL it.

So, don't feel that it is not good practice to have OTL or OTU all over the place. It can made the programming much faster and easier.

And Rslogix comes with cross reference function so it is easy to find where all the OTl and OTUs are..

 

[bce123]

realy tw more advertising?
THE AUTOMATION STORE - Your source for automation supplies and surplus PLC products


do you realy watch your post count?

but I just wanted to try to make a point if Pauly, Peter, and a few others that aren't just trying to post static to increase their post count and might still be listening.

does quanity somehow mean quality to you?

 

[TimWilborne]

Steve, did you watch the video? Your post on it is what brought it to mind. I will help you understand this concept.

 

[bce123]

I will help you understand this concept.

TW, you assume too much.
The OP was:

Is it ok to have one output latch and several output unlatches for the same address in multiple routines in a program ?
Or is it considered risky or bad programming ?

I know it doesn't give an error, but I seem to be having problems and wondering if this might be the reason.

I replied:

I.M.O. no its not ok ,just bad practice, not that it wont work.

I did not state that I did not understand OTE.
I.M.O. using OTL and OTU in multiple routines in a program if you dont understand the impact of doing so is bad practice!!! it has nothing to do with of the way plcs scan and updates. and nothing to do with my understanding of OTE which is not OTL or OTU.
TW, do you understand what I.M.O. means?
maybe this statement:

I didn't read everyone's post in detail

explains why you are confused about it, Steve

 

[Lancie1]

Therefore you would ensure that at some point, every OTU is returned to a false state.

Paully, I assume that you meant OTL instead of OTU. Who cares if the OTUs are true?

 

[daba]

Just browsing the threads this evening so first let me warn, I didn't read everyone's post in detail. This thread is way too out of control to help the OP at this point but I just wanted to try to make a point if Pauly, Peter, and a few others that aren't just trying to post static to increase their post count and might still be listening.

This statement really stuck out to me, mainly because I'll be teaching on this very thing tomorrow to my students. Technically the evaluation of the instructions in the rung preceding the last OTE encountered during a PLC scan will be evaluated for a true or false condition and the OTE instruction will act accordingly, but to say "the last OTE which is scanned by the PLC wins!" is a little bit misleading.

Ron does an excellent job of showing the pitfalls of this statement in the following video.
http://ronbeaufort.com/youtube_lesson_10.htm

passwordg, if you happen to still be following this thread, watch the video carefully and understand the step by step analysis. You can use this same analysis to truly understand and evaluate the conditions of your multiple OTLs and OTUs and correctly predict their outcome or figure out why their outcome is not always predictable.

If you learn to understand and use this method then you can use 1000 OTLs, OTUs, and even OTUs addressing the same bit in a program. Now I didn't say I recommended it, but even that recommendation would be better than making a rule that limiting the number of output instructions on a bit just because you are unsure of how the program code is affecting it.

Well, like TWControls reply above, i didn't read all the posts on this thread, and was going to make my own reply but the quoted post would have been pretty much what I would have said.

Everyone has their own ideas as what is "good practice", "bad practice", "recommended", "avoid using", but at the end of the day the PLC is just a machine that solves logic by interpretation of conditional instructions, and actioning output instructions.

If a particular logic problem can be solved by having multiple instances of OTE, OTL, OTU, then that's OK by me ! (Caveat, I would be concerned about multiple OTE's of a physical output - scary !)

What is important is a basic understanding of what a PLC program is, how the user program is "scanned", and simply realising that the code reads and writes bits and numeric values as the code dictates. That should be one of the first things to be understood, and will shape your views as to what is "acceptable", "good", or "bad" practice, etc.

In a nutshell, there are no hard and fast "rules" as such, but there's a lot of emotion in this field, but IMHO if the code does the job, then it is correct !

 

[Kent Hostetler]

I use multiple OTUs all the time in RsLogix.

If I have a ladder program/project with 1000 rungs and 10 or 20 subroutines that are initiated for various reasons and must be stopped for many other reasons, are the naysayers telling me the only "good" way to stop one of my routines is to pile up input conditions all in one rung preceeding the only OTU?

Is it bad practice to have an initializing or 1st scan routine whereby I unlatch all latched bits prior to the proceeding with the normal program scanning? Sure, you can say to write "zeroes" to pre-arranged words that contain the OTL bits, but that's the same thing.

What I haven't read yet is any good explanation of why it is "bad practice" to ever use more than one OTU for each OTL.

 

[bce123]

Kent, I think the point here is not to do it if you dont understand how they effect your program. I have found that many a rookie gets hung up by this. If you understand the the instruction and its effect in your logic by all means use it. afterall thats why its there.
I am not aginst free style swimming but i think one should learn to tread water first.

 

[rdrast]

Multiple unlatches are fine. Ya know, they are even handy to actually use on an OTE coil sometimes! (Referring to AB here). All of my HMI controlled systems use the PLC to handle all toggle bits (since using an HMI to "Latch" and "Unlatch" things is a recipe for eventual disaster).

Since most such toggles should be persistent, they are OTL's. However, invalid conditions might require one to be forced off (OTU). Also, the cycling of the toggle bit might require one to be forced off (another OTU). Also, a fault might require one to be forced off (another OTU).

If I could accomplish the same thing with a single OTL/OTU pair, there is virtually no need to use them except for the persistence.

Hey, Multiple OTE's are fine. I always have at least one that is used hundreds, if not thousands of times in my programs.

"Not OK" ? "Bad Practice" ?

Not in the least.

 

[Lancie1]

In a nutshell, there are no hard and fast "rules" as such, but there's a lot of emotion in this field, but IMHO if the code does the job, then it is correct !

Daba, what if the code APPEARS to do the job, but the programmer cannot see where the fatal flaw is going to keep it from working?

Here is an example. Look at James's last program (FIFO SAMPLE2) and see if YOU think it does what he stated was the original purpose. Poor programming methods still can result in a non-working program.

http://www.plctalk.net/qanda/showthread.php?t=65565&page=13

 

[daba]

Daba, what if the code APPEARS to do the job, but the programmer cannot see where the fatal flaw is going to keep it from working?

Here is an example. Look at James's last program (FIFO SAMPLE2) and see if YOU think it does what he stated was the original purpose. Poor programming methods still can result in a non-working program.

http://www.plctalk.net/qanda/showthread.php?t=65565&page=13

I think the paragraph previous to the one you quoted explains my views.

The code can't "appear" to do anything other than what it actually does.

However, the visualisation by RSLogix5000, bearing in mind the update time of RSLinx, is another matter - so you often have to look deeper than what is shown on the screen.

Looking deeper will almost inevitably require an analysis of what is happening due to instruction execution order, scan cycle timing, conditional subroutine execution, and a few other things that can have an effect.

I still stand by what I said, multiple OTEs OTUs and OTLs are not a problem to the processor, and if the programmer understands how the PLC actually executes the instructions, then I see no reason why any combinations of them should be considered bad practice.

 

[DamianInRochester]

There is also more to developing a program than just getting it to perform the primary function of control.

Also of great value are:

1) Clarity to those who are not the original programmer. In my opinion well written programs, regardless of style, are easy to digest and debug quicker. So I think it isn't just important that only the programmer understand what he is doing. I think it is also important that the people that have to service the code ten years later can as well without spending a week to reverse engineer.
2) Abiltiy to make modification without unintended side effects or negative domino effects.
3) Ability to recover the system without re-booting the PLC if things get out of sequence.

NONE of these things of course imply that it is bad practice to use set and reset coils in any number of fashions. I can say though that the vast majority of programs that I have run across that have been a disaster to modify or debug utilized set and reset coils haphazardly. I think this is because it is easy for people to just start developing code with them without first giving any thought upfront to structure or organization.

As long as you have structure and organization, everything else is style and performance.