Double-coils

I have always avoided double-coiling when I program. I have always found it easier to commission and debug if there is only one place in a program that can control a bit. I kind of thought it self-evident that double-coiling was a bad idea.

I have a vendor (whom I consider a quality supplier) who has suggested that my bias is driven by having lived in the "AB world" in the States, and that in Siemens programming (for example) it is perfectly acceptable and appropriate to double-coil (especially if setting/resetting).

Now I've done my share of work in Siemens S5 processors too, but even here, I have always avoided double-coils like the plague. I just didn't see a real reason to use them.

This vendor has gotten me thinking though. What are the arguments for and against double coiling?



Obviously in the arguments against:

1. More difficult to debug / troubleshoot.
2. Rung/Sub-Routine order becomes hugely important.
3. Pre-scan must be considered (especially for sub-routines which are not normally called).

(Enough in my "biased" mind that I would never do it myself)



In the arguments for:

1. It allows outputs (internal or real world) to be placed at the positions in the program that make sense (even if that means two or more places).



I don't want to be thick headed and arbitrarily limit my supplier, but I just don't like double coils. Am I missing something? Anyone want to weigh in?

Thanks,


Marc

Even in the AB world (at least in the PLC-5s), doublecoiling is OK, if you doing something like a SFC which has absolute control of which subdirectory is active, and guarentees that only one is active per scan.

And it's not impossible to "roll-your-own" SFC, even in a SLC. That's roughly what THIS THREAD is trying to do.

But if you are dealing with straight ladder, and are just using SUBs to break up your code into managable chunks, then I agree with you - double-coiling is just plain bad.

If you can't explain exactly when an output (internal or external) is on, then you probably don't understand your process well enough.

That last sentence applies to the use of latch/unlatch (or Set/Reset) of bits too, and why it's generally preferable to avoid them as well. There can be no logic that is currently true that explains the state of the bit, and so you have to know (or trust you know) what conditions in the past occurred to make the state the way it is now.

Just as knowing which condition may or may not have set the double-coiled bit. Is it the last instance, or was that SUB disabled, and so it was the one before. Ultimately you are guessing you know, and it's possible to guess wrong.

This is engineering. We shouldn't have to guess.

The great strength of ladder is that each logic statement is graphically and explicitly displayed.

The great weakness of ladder is that it does not inherently impose any structural discipline on the overall program.

With experience good programmers devise ways to create their own structures to bring some order to their PLC programming. Now everyone is pretty much free to argue the merits of their own system...but I would strongly suggest that "double coiling" is usually avoided.

Your vendor's comments about the "AB world" bias are just disengenuous. AB does NOT stop you from double coiling, but most programmers learn fairly quickly that scanning two OTE's is usually a mistake, regardless of whose PLC you are using.

There are perfectly legitimate ways to use double coiling. I suspect the main reason why it is allowed is that in the very old PLC2's the idea of "control zones" using MCR instructions was used to electively scan portions of a ladder file depending on machine state. It was primitive form of subroutines.

Even now you can double coil in different subroutines if you want...just so long as you KNOW that both routines never get scanned contemporaneously.

But my strong preference is NOT to. My main reason is that I structure my programs in such a way that ALL I/O (inputs and outputs) are explicitly called only once.

This means that I can create projects without needing to know I/O allocations until commissioning time. It all also makes writing the logic easier and troubleshooting a lot more straightforward.

OK, if there is no other way.

Generally though, I will go to great lengths to avoid it. I even have my own favorite method of sequencing that avoids using double coils and even set and reset latching.

Siemens S7 also has a nice SR block allowing you to avoid double coiling even for setting and resetting.

As an aside, I also avoid jumps and MCRs, usually my code has none of this. If the PLC supports it, I will use functions. Although for these, I ensure that I use only local variables where the function is called in multiple places.

On the other hand, when programming in assembly or SEW Ipos, I will use jumps because there is nothing else available.

Doug

PhilipW said:

The great weakness of ladder is that it does not inherently impose any structural discipline on the overall program.

Click to expand...

And can you show me one that can?

Discipline is at ones finger tips.

We can end up with spaghetti code with any language or form.

Pierre,

Yes I see what you mean....junk code is junk no matter what language it is in.

FB is better organised for the flow data in an analog intensive process.

SFC imposes a higher level of organisation in a highly sequential system.

In terms of processor resource utilisation machine code or assembly language forms are highly efficient...but demand a high level of skill to program well.

By contrast higher level programming tools support re-usable code libaries, multi-threading, multiple reentrantrancy, and extensive function calls...but consume correspondingly large amounts of processor resource.

In this context ladder logic is pretty much just one or two steps above machine code...whereas most other languages used in the big wide world of computing...are far more structured.

This is not meant to be a criticism...I have IT friends who are always impressed at what can be achieved in a few hundred words of ladder...that would take them 50k of disc space just to open a file.

When talking about understanding "double-coiled" code Allen said:

Ultimately you are guessing you know, and it's possible to guess wrong.

Click to expand...

How about adding another twist to my question:

Does code with double-coils effectively mandate debugging on-line (ie: not from a printout)?

There are instances in the older S5 processors that you had / wanted to write directly to the PQW's or read directly from the PIW's and bypassed the image tables. If you were doing high speed movements and wanted to read an absolute encoder position or write to an output word in the middle of a scan, you could do it. You can do it in S7 also. Why would you, you ask? SPEED. I believe the AB's use immediate reads and writes. Generally, you are better to use internal bits for functions that impact the outputs and use those to control the outputs in ONE place. The individual bits can be labeled and commented as to what there job is. Trouble shooting is much easier and the functions can be started and stopped, easily for de-bugging. Setting and resetting bits is OK. I don't like to use S/R on outputs, for fear they would be set ON and something not turn them off. The question to ask when writing any code, is can someone else follow what I have done? Would I be proud to put my name on the code?

RRobbins said:

...The question to ask when writing any code, is can someone else follow what I have done?....

Click to expand...

I sure wish we all thought like that.

I don't use double coils very often because I troubleshoot by looking at what the problem is and working backwards. (It doesn't turn on, check the output, check what drives the output) I find that some people prefer to look at what was tried and where did it go wrong, therefore they like their ladder to originate from one point and branch out from there rather than start from elseware and end at the outputs.