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

[passwordg]

Who is to say that they aren't missing ... the dreaded double OTE!

Don't take my post as saying "it's just dandy, nothing to worry about", I was pretty clear in the importance of using these instructions in a 'precise and organized manor'.

Hi Paully. "it's just dandy, nothing to worry about" --- Heh, that made me chuckle.

The Double OTE ?
Is that having the same OTE in say, two different rungs in the same program ? Or is it something else ?
Something like this did happen to me. Caused havoc for a while until someone helped me.
I dont have any real training, though currently writing my first "real" program ever at my work and have been sort of meandering around for a while. So silly mistakes like these certainly are coming back to bite me when they can.

A little presumptuous don't you think? After all the OP has given almost ZERO information to us on the actual problem he/she is having!

Well, at the core, the problem was with certain bits not unlatching or else latching on probably due to multiple locations

Completely DISAGREE.

It's only NOT OK if the code is implemented poorly. Meaning, there is no good pattern which exists as to where and when an OTL is used, and where and when an OTU is used. Disorganized code makes OTL/OTU instructions extremely hard to follow.

The major problem with OTL and OTU instructions is making sure you account for EVERY situation in which you need an OTU! If you miss one, you've got a problem!

HOWEVER, if you write you're code carefully you can use OTL/OTU instructions in a very precise and organized manor. You would be surprised to see how super-duper-simplified code can become!

That was inspiring. Thanks. I would simply love to see some example though. (I suppose might be hard as you'd have to post multiple rungs)

 

[passwordg]

the above ???s are good reasons to map your i/o

Thanks for the tip. I'll look it up since I have no idea what mapping your I/O means.
Meanwhile any chance you could please tell me where to read on this topic ?

 

[Paullys50]

bce123 -

A year ago I would have "mostly" agreed with you, but then I stepped "out-of-the-box". What if I told you I can add many OTLs to my program without adding a single OTU, and NOT have problems, yet have full control? The only thing I have to "keep straight in my head" is the data type I am using. (And if I forget I just copy and paste )

The point is, that if you can keep yourself from the inevitable "tunnel-vision" that comes with this profession, you can pull off some pretty cool things that many would consider to be "bad programming/bad practice" on the surface level. Take a step beyond surface level and suddenly lights burn brighter and warm-fuzzies fill you will joy. (And yes this does relate the the input-mapping thread too)

For the most part I have a single method that controls the majority of my program functions. Outputs, internal control bits, HMI commands, alarms, buttons, PID loops...if you know how to program any one of those, you can program them all. Don't get me wrong, there is a lot going on in the "background" but once you understand the single method, you are golden.

But, many would look at my program and say it's complicated, doesn't follow KISS, blah blah blah. But, that's because they would be looking at everything BUT the simple command logic.

Over the few years that I have been doing this, I have learned extremely quickly to take a step back, tell myself that the program was written in the manner it was for a "reason" and to kick "KISS" to the door because if everything could be done via the "KISS" method any schmoe could program a PLC. Once I understand the "reason", then I smile or shake my head!

 

[bce123]

Paully, please help us to see through this tunnel vison. I am allways open to better ways to do things. please post an example so that suddenly lights burn brighter and warm-fuzzies fill us will joy! I would love to be proved wrong on this matter if it teaches me a better way to program. look foward to your post, steve


p.s. forgot to let you know i use seimens,omron,ad,ab and other plc platforms as well. I am fairly new to logix 5000 and its async scans but if this only pertains to that I would still like to learn it before I get to set in my ways. Thank YOU in advance for teaching us somthing new. thats what sites like this are all about.

 

[Paullys50]

Hi Paully. "it's just dandy, nothing to worry about" --- Heh, that made me chuckle.

The Double OTE ?
Is that having the same OTE in say, two different rungs in the same program ? Or is it something else ?
Something like this did happen to me. Caused havoc for a while until someone helped me.

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

I dont have any real training, though currently writing my first "real" program ever at my work and have been sort of meandering around for a while. So silly mistakes like these certainly are coming back to bite me when they can.

As with any learning process, if you aren't breaking something you aren't learning! (Try to break things in the office, not the plant floor!)

Well, at the core, the problem was with certain bits not unlatching or else latching on probably due to multiple locations

So how do you properly "fix" this problem? How can you guarantee it latches when it needs too, and guarantee it unlatches when it needs too? - I think that is a great "thinking cap" discussion question.

That was inspiring. Thanks. I would simply love to see some example though. (I suppose might be hard as you'd have to post multiple rungs)

Maybe someday, right now the code has been long in development, not my place to share with the world.

 

[bce123]

Oh wait didnt see that last post. you said:

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

the OP had said:

Is it ok to have one output latch and several output unlatches for the same address in multiple routines in a program ?

then you said:

What if I told you I can add many OTLs to my program

now I am confused???? did you not read the OP? and you realy dont think it ok to use one output latch and several output unlatches for the same address in multiple routines in a program? help me out here

 

[PeterW]

bce123 -

A year ago I would have "mostly" agreed with you, but then I stepped "out-of-the-box". What if I told you I can add many OTLs to my program without adding a single OTU, and NOT have problems, yet have full control? The only thing I have to "keep straight in my head" is the data type I am using. (And if I forget I just copy and paste )

The point is, that if you can keep yourself from the inevitable "tunnel-vision" that comes with this profession, you can pull off some pretty cool things that many would consider to be "bad programming/bad practice" on the surface level. Take a step beyond surface level and suddenly lights burn brighter and warm-fuzzies fill you will joy. (And yes this does relate the the input-mapping thread too)

For the most part I have a single method that controls the majority of my program functions. Outputs, internal control bits, HMI commands, alarms, buttons, PID loops...if you know how to program any one of those, you can program them all. Don't get me wrong, there is a lot going on in the "background" but once you understand the single method, you are golden.

But, many would look at my program and say it's complicated, doesn't follow KISS, blah blah blah. But, that's because they would be looking at everything BUT the simple command logic.

Over the few years that I have been doing this, I have learned extremely quickly to take a step back, tell myself that the program was written in the manner it was for a "reason" and to kick "KISS" to the door because if everything could be done via the "KISS" method any schmoe could program a PLC. Once I understand the "reason", then I smile or shake my head!

Well said that man, I've made many programs in the past where you contaion sequence bits in single words.

To my mind there are three parts to the program, the easy bits where you want people to fault find, the hard bits where you want efficiency and speed and the bits where you tell people the problem via diagnostics (therefore they have no need to look even).

I know there are badly written programs out there, I've seen enough of them, but a well written piece of code is .. well .. well written.

I've never been a advocate for KISS for KISS sake, sections can be made to be easily followed but depending on your application your may need the clever stuff.

I have colleagues who hate using Function Blocks as sub routines, a single piece of well written, thoroughly tested code with diagnostic data which is called 100 times in a single program to control 100 identical valves or motors etc, is so much better than cut and paste, cut and paste.

 

[PeterW]

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

Unless all but one are not processed of course

 

[Paullys50]

now I am confused???? did you not read the OP? and you realy dont think it ok to use one output latch and several output unlatches for the same address in multiple routines in a program? help me out here

Take a step back...

Is an OTE the same as an OTL?

 

[PeterW]

Oh wait didnt see that last post. you said:

the OP had said:

then you said:

now I am confused???? did you not read the OP? and you realy dont think it ok to use one output latch and several output unlatches for the same address in multiple routines in a program? help me out here

Quite common is sequencing.

 

[bce123]

I have colleagues who hate using Function Blocks as sub routines, a single piece of well written, thoroughly tested code with diagnostic data which is called 100 times in a single program to control 100 identical valves or motors etc, is so much better than cut and paste, cut and paste

I totaly agree

 

[bce123]

Take a step back...

Is an OTE the same as an OTL?

no, and not the same as an OTU

 

[Paullys50]

Paully, please help us to see through this tunnel vison. I am allways open to better ways to do things. please post an example so that suddenly lights burn brighter and warm-fuzzies fill us will joy! I would love to be proved wrong on this matter if it teaches me a better way to program. look foward to your post, steve

Keep in mind that I am NOT trying to prove that one method is better than another, I am NOT trying to prove that I am right and you are wrong, and I am NOT trying to prove that OTL/OTUs are superior to "sealing" logic.

I am simply trying to make people think.

For example, if I were to teach a PLC programming course at the collegiate level, courses PLC 101 and PLC 201 I would PREACH "sealing" logic as I feel that every PLC programmer needs to have this fundamental knowledge. I would teach to avoid using OTL and OTU instructions unless it was "non-critical" code WITH the stipulation that you have code to re-trigger the OTU instructions again whenever the PLC was first powered up, or the system was in a "non-production" state. Therefore you would ensure that at some point, every OTU is returned to a false state.

Now, as you move onto PLC 301, 401 I would begin to change my tune. As with everything in life, the more you learn, the more you realize that the "ideal" situation doesn't always exist and you need more muscle to get the job done. That is when I would say "Lets review those OTL/OTU instructions I told you to avoid..."

and here we are

 

[Paullys50]

no, and not the same as an OTU

Why are they different?

(There are a few good threads that discuss this topic)

 

[bce123]

Keep in mind that I am NOT trying to prove that one method is better than another, I am NOT trying to prove that I am right and you are wrong, and I am NOT trying to prove that OTL/OTUs are superior to "sealing" logic.

I am simply trying to make people think.

For example, if I were to teach a PLC programming course at the collegiate level, courses PLC 101 and PLC 201 I would PREACH "sealing" logic as I feel that every PLC programmer needs to have this fundamental knowledge. I would teach to avoid using OTL and OTU instructions unless it was "non-critical" code WITH the stipulation that you have code to re-trigger the OTU instructions again whenever the PLC was first powered up, or the system was in a "non-production" state. Therefore you would ensure that at some point, every OTU is returned to a false state.

Now, as you move onto PLC 301, 401 I would begin to change my tune. As with everything in life, the more you learn, the more you realize that the "ideal" situation doesn't always exist and you need more muscle to get the job done. That is when I would say "Lets review those OTL/OTU instructions I told you to avoid..."

and here we are

Well put paully I can agree on that!
and yes I see lights burning brighter and warm-fuzzies are filling me with joy!
as for :

Thanks for the tip. I'll look it up since I have no idea what mapping your I/O means.
Meanwhile any chance you could please tell me where to read on this topic ?

would you mind pointing him in the right direction I think you have a good handle on this subject. Thanks, for getting us to think about this paully