Two rungs writing to one coil

[Chuck Woodbury]

If the first OTE is false and the second true, the second will be true only until the scan gets back to the first, at which time it again goes false. If one is in a Subroutine not being called at the same time the other OTE is being addressed only the one in the active subroutine will be working. And, as RDRast said, JMP/LBL will keep one or the other inactive as well.

 

[fluoronator]

Actually the output is on contiguous rungs in the same ladder file. I'll probably do a test tomorrow but if it's always "last rung wins", I'm expecting to find that the first rung never works.

 

[rsdoran]

Actually the output is on contiguous rungs in the same ladder file. I'll probably do a test tomorrow but if it's always "last rung wins", I'm expecting to find that the first rung never works.

Could be many if's involved since you stated this was a new install. It would be easier to understand if we could see it, that said do any of the rungs have an XIC at the front that has no reference to being turned on i.e. the XIC may be B3:0/0 and not shown anywhere except as an XIC or XIO. The XIC is the equivalent of an AFI (always false instruction) and the XIO equivalent to an always true instruction. which programmers use for testing purposes. If so then the programmer may not have cleaned up or is not done putting finishing touches to the program.

 

[gas]

It could be that this is the first program that he ever wrote.

It could also be that he has too many projects and the boss wants them all done at once and he just didn't see this duplication. Or maybe the boss is "helping". If it's the second I feel for this guy.

 

[Newton W]

I've seen first-outs programmed that use the same addressed coil in multiple/sequential rungs...

Should be easy enough to figure out, though.

-William

 

[PeterW]

I know this is a bad practice but what happens when you have two different rungs of logic that write to the same coil? Which rung wins if one is turning it off and the other is turning it on? Is it the one that is scanned last? I'm working with a SLC505.

Probably find he's using a coil as a scratch flag.

That is he has conditions to turn it on/off and then the following networks uses the result in other logic.

Later on, he has another network of conditions for the same coil.

The conditions in each case are relevant for its use imediately in the networks after the network in which it is turned on/off.


EDIT: This used to be common practice in Siemens Step 5 programming, usually flags above 200 were scratch flags.

 

[daba]

Acceptable if....

IMO this technique is acceptable, and widely used, where the first coil is again used as a -||- contact on the next and subsequent rungs, each of those having the same coil as its output.

If any of the rungs equate True, the coil is turned on, then because it is OR'd into the next rung, it will stay on, etc. etc. until it is scanned again.

In this fashion it acts as a logical extension of the preceding rung(s), and allows you to build large OR functionality over a range of rungs.

One advantage is that you can always "see" the state of the output bit, no matter which rung you are monitoring, a bonus if there are a lot of rungs or they are spread through different program files.

You have to be sure that the first rung of this logic doesn't have the -||- of the output coil on it, otherwise it would never turn off.

Like many other things, it makes sense to the person who wrote it, and once you've got your head around how and why it works, you'll probably be able to live with it.

 

[daba]

...and more on the subject...

the technique is far preferable to having a general-purpose "logic_extend" or "carry" or "scratch" bit that can be used anywhere you like.

People have a tendancy to forget that your logic can be interrupted by Interrupts, Periodic Tasks, Selectable Timed Interrupts, Interrupt Program Files, etc. etc.

If you used the general-purpose logic extension bit in one of those interrupt files you will garbage the result of the interrupted code.

 

[Terry Woods]

PeterW is correct... except that those of us that have been lucky enough not to have suffered under S5 call his limited "scratch flag" a simple control relay.

The point being, as the ladder is processed, ANY particular output is written to memory in the manner determined by the result of any particular rung as that rung is completed.

You can't let yourself get locked into the idea that the Input Image and the Output Image are EVERYTHING!

You gotta know... a hell of a lot more is possible!

And that includes the possibility of a particular Control Relay Output going On and Off, many times, before the end of the scan! Which, of course, more than implies that the particular Output is controlled by more than one rung.

To ignore this bit of reality is to keep yourself very limited in terms of the possibilities.

Think outside of the BOX!

This particular concept is the next step beyond that so-called "awful" concept of SET/RST! (or Latch/Unlatch)

I have to wonder... how many of you can handle it when we get to that dreaded "GO-TO"! (I wonder how many of you don't realize that you ALREADY use the dreaded GO-TO???)

OOooOOoooo.... "scarwy!" (No... it's not a misspelling, It's a quote from EF.)

Then there is the... Indirect Addressing issue where data is retrieved from, or written, to a "calculated location". Oh...My...God!

This whole concept is called... Data Processing!

Decisions are made, or at least ought to be made, based on DATA!

Proceeding through any ladder is nothing more than Data Processing!

Later...

 

[RSL]

Amen Terry.

I agree with you. I get into this argument at work all the time. Most of the people I work with refuse to acknowledge that the concepts you mention exist, let alone are valid and useful techniques.

I do not agree with the use of them just because you can. If you really need an upper level instruction use it. If it can be done well without then don't. Like you said the data determines what is needed.

However, the end user (customer) is the ultimate consideration. On many occasions I have coded to satisfy the directives of a customer. Many times making my job harder and the code less efficient. If my customer does not understand JMP and LBL instructions I can't ridicule him and tell him he better learn. I have to find another way. There have also been times where I really had to use indexed or indirect adresses and the customer really had no choice.

The truth is most end users do not operate at the level of a programmer. Since they pay the bills we have to find a way for me to get my work done and them to be happy with it.

As I said I really do agree with you and wish everyone did accept all these concepts. That just is not reality with most customers and some co-workers.

RSL

 

[Terry Woods]

RSL...

I appreciate what you are saying. However, isn't the bottom line something about doing what will INCREASE production for Corporate?

My bottom line strategy in designing is...

1) Production (Corporate)
2) Production Folks (They are your most powerful ally or foe!)
3) Maintenance Folks (They are the second most powerful ally or foe!)
4) and last... the programmer (me... I have to satisfy 1, 2 and 3!).

That means, first I do what I can to get what I can out of the Hardware that IS the process! Then, I do whatever I can to make those Production Folks look as good as they can look! (They are your Best Allies!) Then, I make it as easy as possible for the Maintenance Folks to fix, or at least, check what they need to check!

All of that means... the programmer, me... takes the hit!

It seems that NOTHING IS EVER EASY!

If you find that it was easy... then something is wrong!

Unless, of course, you really become a guru in terms of the particular issue!

With time, anyone can become a guru in terms of a particular issue.

Oh... and by the way... NEVER use a complicated method when a simple method will do. HOWEVER, at the same time, make the method as complicated as necessary to accomplish the goal!

It's that simple!

K.I.S.S. for the sake of troubleshooting is NOT a valid argument if it interferes with Production!

If there are folks that demand K.I.S.S. for the sake of troubleshooting... then there is something fundamentally wrong with the code as it is written!

 

[geniusintraining]

K.I.S.S. for the sake of troubleshooting is NOT a valid argument if it interferes with Production!

If there are folks that demand K.I.S.S. for the sake of troubleshooting... then there is something fundamentally wrong with the code as it is written!

....

 

[PeterW]

People have a tendancy to forget that your logic can be interrupted by Interrupts, Periodic Tasks, Selectable Timed Interrupts, Interrupt Program Files, etc. etc.

If you used the general-purpose logic extension bit in one of those interrupt files you will garbage the result of the interrupted code.

With S5, interupts maybe triggered mid-block but don't action until the end of a block. Therefore you never used this method to carry over a block boundary.

 

[darrenj]

Modicon plain wont let you do this..

However AB will...

Recently i stated a large machine it was shipped up from the states (A reputable company) and we couldnt get the interlock to work properly (It was telling another machine when it was ready..) I spoke to the programmer in the states and he emailed me the program..after looking into it i found a duplicated coil..It tuened out to be a typo..Hey it happens..the machine worked great at factory but they didnt have a filler to "Talk" to so it wasnt picked up.. I would pick up the phone and try to speak to the programmer..he might save you some headache..

D

 

[Terry Woods]

Sooo, Git...

What are you trying to... say, or imply?