Double Coil Avoidance

ygolohcysp · Mar 18, 2020

Hello,

I was just reading about Double Coil Syndrome on an old post from here. It's something that I dealt with and figured out for the program I just finished with. I get why it works the way it does, although in my mind since this is programming, it should work the way I want it to.

Anyway, in my last program, I just got around it by setting up bool variables as output coils, and then used those in OR contacts going to the actual output coil.

But I'm wondering if there is a better practice. Sometimes I need timed sequences where there is a bunch of AND contacts, and Timer On's, and other portions for sequencing off and timers in those, all for Auto function. And I need a manual function, but still with protection parameters in place, and it doesn't always make sense to try to design the program around having each coil with an array of different inputs.

So is there a best practice for program design from the start? Rely on internal variables, so I can reference as many as I want, and then have all those variables point to one coil? Subroutines? Should I really try to layout the program around coils, and just make the inputs as scrambled and messy as they need to be to only have one coil reference?

Just trying to wrap my head around this as a function of design intent rather than problem solving later. I think it would make for more efficient code.

bernie_carlton · Mar 18, 2020

I'm not sure about 'best practice' but I know what worked for me and my co-workers. Each rung of code which solved to a specific output ended in a properly identified bit. These will were gathered, as you had described, on an OR configuration near the end of scan. With proper naming it is easy to see which function is calling for each output.

drbitboy · Mar 18, 2020

ygolohcysp said:
although in my mind since this is programming, it should work the way I want it to.

What a pleasant thought. Possibly delusional*, but pleasant nonetheless.

Humor aside, I agree with your approach i.e. buffer the state, or multiple states, that contribute(s) to a single output in internal bits via ORs and ANDs, and the rung that "sets" the coil only once is after all of those states are resolved.

The chaos of having contributing states (bits) scattered about is mitigated by having those states collected in the one rung that determines the coil state, because in most programming environments one can use the state names there to find where those states are set.

As far as declaring this a "bad practice," it seems justified IMNSHO. There are two cases

In a synchronous [input scan/program scan/output scan] PLC (e.g. A-B MicroLogix), the first rung of a Double Coil Syndrome (DCS) pair does nothing useful, and can be distracting at best and harmful at worst to someone trying to understand the logic.
In an asychronous PLC (e.g. A-B ControlLogix/CompactLogix), the first rung may do something non-deterministically i.e. it is possible for the coil state to be output after the first rung is evaluated but before the second rung, so now someone is trying to diagnose why some motor clicks on for a few ms at random times.

The one possible exception I could think of would be where any rung after the first of a DCS set, where all input states were to be ORed, did this:

Code:

--+--]test N[--+----(coil)---
  |            |
  +---]coil[---+

or equivalent, and that only in a synchronous PLC, and it's still ugly.

* if "should" means "unconditionally will," then it's delusional; if "should means "if I do my job right, then it will," then okay, I can appreciate the sentiment.

mk42 · Mar 18, 2020

drbitboy said:
* if "should" means "unconditionally will," then it's delusional; if "should means "if I do my job right, then it will," then okay, I can appreciate the sentiment.

In my world, it's usually "with a whole lot of luck, it MIGHT work"

ygolohcysp · Mar 19, 2020

drbitboy said:
What a pleasant thought. Possibly delusional*, but pleasant nonetheless.

Humor aside, I agree with your approach i.e. buffer the state, or multiple states, that contribute(s) to a single output in internal bits via ORs and ANDs, and the rung that "sets" the coil only once is after all of those states are resolved.

The chaos of having contributing states (bits) scattered about is mitigated by having those states collected in the one rung that determines the coil state, because in most programming environments one can use the state names there to find where those states are set.

As far as declaring this a "bad practice," it seems justified IMNSHO. There are two cases

In a synchronous [input scan/program scan/output scan] PLC (e.g. A-B MicroLogix), the first rung of a Double Coil Syndrome (DCS) pair does nothing useful, and can be distracting at best and harmful at worst to someone trying to understand the logic.

In an asychronous PLC (e.g. A-B ControlLogix/CompactLogix), the first rung may do something non-deterministically i.e. it is possible for the coil state to be output after the first rung is evaluated but before the second rung, so now someone is trying to diagnose why some motor clicks on for a few ms at random times.

The one possible exception I could think of would be where any rung after the first of a DCS set, where all input states were to be ORed, did this:

Code:

--+--]test N[--+----(coil)--- | | +---]coil[---+

or equivalent, and that only in a synchronous PLC, and it's still ugly.

* if "should" means "unconditionally will," then it's delusional; if "should means "if I do my job right, then it will," then okay, I can appreciate the sentiment.

I appreciate the input. I'm kind of leaning towards calling different routines in the project I'm currently working on as my approach just for this one time. But that's because it's a huge system, with about 5 systems that will mostly run together, sequenced on and off, but can have the individual systems run on their own as well. So one main program or routine, which calls the sub-routines as needed defined by the auto-run mode it's in.

To clarify what I meant by how I think it should operate ... well, to start off, I'm not a PLC guru ... yet. So I'm thinking about it in terms of hardware (actual wiring in old ladder relay logic) .vs programming (though I don't have a lot of experience, and have been years removed, I learned C++ first). I get that with a PLC, it examines the rungs, and determines the state of the output based on that rung, and the last rung scanned is what's accepted as true. Great, but that's not how my brain automatically thinks of it. To me, it should only be determining "Does this rung make this output True" rather than "Is this output True in every location within the program because of this one rung?" Or rather, multiple rungs should just automatically be seen as an OR argument. Again, just the way my brain was automatically thinking it should be given my lack of experience.

I get that it would potentially become problematic with safety stuff and having outputs off reliably, but the issue I had in my first project was in having multiple calls for the alarm stack lights.

But, lesson learned, and that's why I'm figuring out best practices. Or acceptable work arounds at the very least. ;-)

kamenges · Mar 19, 2020

Originally posted by ygolohcysp

Or rather, multiple rungs should just automatically be seen as an OR argument.

Switch to Automation Direct classic plcs. They have an OROUT instruction that does what you want.

Another way to do what you are thinking of is to use latch outputs instead (assuming you are working with a synchronous scan plc). Unconditionally unlatch the bit(s) at the beginning of the scan and use latch outputs in each rung. That will result in the functionality you are talking about.

Now, the next programmer to touch this program will likely hunt you down and beat you mercilessly with a wet blanket. But sometimes that is the price you pay for going your own way. But I suspect he won't be anywhere near as upset about that as he would be conditionally called subroutines all loaded with shared outputs. At least the first method is fairly obvious.

Keith

GaryS · Mar 19, 2020

Best practice is not to do it if you can
But having said that you can do it
the first ladder rung that uses the output should be a normal coil ( )
all runs after that should be a Latch Coil (L)
the program will turn it off on if the first rung is false and only turn it on when a rung is true
I have done this more than a few times when the amount of elements in the rung are to large to display

janner_10 · Mar 20, 2020

bernie_carlton said:
I'm not sure about 'best practice' but I know what worked for me and my co-workers. Each rung of code which solved to a specific output ended in a properly identified bit. These will were gathered, as you had described, on an OR configuration near the end of scan. With proper naming it is easy to see which function is calling for each output.

+1 Nice and simple. Easy to troubleshoot too.

parky · Mar 20, 2020

I believe that the best way is to only use "coil" outputs once therefore create the logic maybe this means many internal bits to turn on an output and or them in a separate block, this makes fault finding easier, i.e lets say the output is controlled in five different places (processes) providing the tags are documented correctly you should be able to cross ref the bits and jump to the logic.
I have come across programs that set & reset outputs many times in the program and in most cases causes all sorts of problems, lock up's, false triggers and even had a strapping machine doing a tango where we had to power it down to stop it, even the original programmer could not put a required mod in it as every time he tried it caused problems (he was removed and I re-wrote it from scratch it worked a dream). I'm not saying set/reset of outputs should not be used but in my experience it's best to avoid it, structure your programs i.e. each operation in separate blocks this makes it easier to fault find.
Using set/reset on internal bits is fine (don't see how you cannot) even if its an or around the trigger logic to "Latch" it in. I have seen people write programs this way as they do not like to do SET/RESET doh it's the same thing.

kalabdel · Mar 20, 2020

Have at PLCopen coding guifelines http://https//plcopen.org/node/90?file=165

I can not link directly to it but a quick search will get you there.

Rson · Mar 20, 2020

every coil should be on it's own rung, imo.

If you need to control an output based on different conditions, use an internal bit for that condition and then the bit to fire the coil.

If I'm looking for a problem with a PLC program, it is nearly always because something isn't turning on. The easiest way to troubleshoot is to start at the coil (Actual PLC address) and work my way back. For this reason, I always make the outputs grouped together in one place in my programs. Top to bottom output 1, output 2, etc.

Aabeck · Mar 20, 2020

I usually set bits for conditions that enable an output, then in the last routine, or the end of the rungs on a single (Mitshubishi, AutoDirect, etc) ladder have a rung controlling a single output based on the modes and bits.
Also on this line I can check E-Stop, MCR/K1, Low Liquid Level, Overtemp, Cover Open, etc relevant to that outputs controlled item.

Sydney · Mar 20, 2020

Rson said:
every coil should be on it's own rung, imo.

Well said, I've seen to many double coils in my time.

Try explaining to your boss why the money line, referring to the last assembly line in a automotive plant, was down because someone troubleshooting a piece of equipment came across a double coil that confused them or acted in a unusual way depending on how the rung was written. Our down time in assembly was $10.000 a minute.

When we came across a double coil, and it happened quite often, we were required to countermeasure the double coil. I can't recall at any time not being able to get around using a double coil.

We always tried to "Keep It Simple Stupid" when writing ladder. One way to do that is to make a rule to only use the same coil once in a program.

Dayvieboy · Mar 21, 2020

No compile errors or warnings when you have duplicate coils?

Aabeck · Mar 21, 2020

Dayvieboy said:
No compile errors or warnings when you have duplicate coils?

Only in RSL/Studio5000 of all the platform software I use.

And, only if enabled in the settings. Easily turned off with a chackbox.

Double Coil Avoidance

ygolohcysp

Member

bernie_carlton

Lifetime Supporting Member + Moderator

drbitboy

Lifetime Supporting Member

mk42

Lifetime Supporting Member

ygolohcysp

Member

kamenges

Member

GaryS

Member

janner_10

Lifetime Supporting Member

parky

Member

kalabdel

Member

Rson

Member

Aabeck

Member

Sydney

Member

Dayvieboy

Lifetime Supporting Member

Aabeck

Member

Similar Topics