"double coil error" what does it mean?

parky said:

Here is a general pic of the process

Click to expand...

While that is true for the majority of PLCs on the market, it certainly is not true for the A-B Logix5000 series of PLCs, and by that I mean ControlLogix, CompactLogix, DriveLogix, and FlexLogix (now virtually redundant).

On those hardware platforms, the I/O update is not synchronous to the user program scan, and data is exchanged with the I/O modules during a "time-slice" of processor operations. This "System Overhead Time-Slice" (SOTS) is a background task that overrides virtually everything, and one of its major functions is to exchange data with other modules in the system, including I/O modules.

Think of the Logix5000 system as being a collection of modules exchanging data (via a method called Producer/Consumer), the rate or period of exchange being controlled by each module independently of the user's program.

What this means is that an input can be read at different states throughout the execution of one "scan" of the control program. This has to be taken into account if you intend to read a physical input more than once in the application. It may, or may not, cause any issues, but only the programmer would know this.

"Buffering" the inputs, by mapping them once only to internal tags, and using the internal tags as the input state in the rest of the logic overcomes this potential issue.

To be fair, I have used "double-coil" bits in my logic, but only to extend a rung to the next for readability.

eg.

rung n : .... OTE logic_extend
rung n+1 : XIC logic_extend .....

That is the only time I will use them, and it's all I want to see in the compiler report, anything else and I question my own sanity.

From the standpoint of the double coil problem, the fact that Logix5000 PLCs handle their I/O updates a little differently than other PLCs is immaterial. The key takeaway is that individual I/O points are not updated immediately following the program line where they are modified. They are updated along with the rest of the I/O points. The value transmitted to an output modules is the result of the program rung executed most recently before the I/O update.

Steve Bailey said:

From the standpoint of the double coil problem, the fact that Logix5000 PLCs handle their I/O updates a little differently than other PLCs is immaterial. The key takeaway is that individual I/O points are not updated immediately following the program line where they are modified. They are updated along with the rest of the I/O points. The value transmitted to an output modules is the result of the program rung executed most recently before the I/O update.

Click to expand...

I think I agree : the user
program simply reads and writes data from/to the produced and consumed tags that are written/read to/from the I/O modules at a time you have no control over. The produced/consumed data exchange can happen at any time (and multiple times) within the user program scan

If you program multiple physical outputs on a Logix5000 system, it is simply NOT a case of "last one wins"

There are IIN (Immediate In) and IOT (Immediate Out) instructions you may use to control when specific module data is exchanged, but in general, very rarely used.

Simply put, when you program a simple OTE, you are NOT writing that data to an output module at all, that is handled in the background ....

Good points for the OP to learn about other platforms but in this case it is Mitsubishi so not exactly relevant to this post, however, as stated there are ways to update the PIO on demand rather than the normal mode of updating either before or after program scan. In saying that this really applies to high speed control situations and very often special I/O cards as a scan time of 50ms (quite slow by modern standards) turning on a physical output for say 10ms is not normal for most control processes and standard I/O.

For any of you not wishing to read anything in this thread unrelated to Mitsubishi Please stop reading this now.


If any of you are old enough to remember the Very Old Siemens 110A Controller it was common to see only 1 bit used in the program to work out logic before the state of the bit was used in the next rung for more logic. You could see F0.1 used loads of times in the same program. It made for interesting fault finding when the only tool available was a PG610 I think it was. That was in the 1980s when i was young and had hair.
There is a German manufacturer on whose equipment I work regularly and their programs use M0.1 in the same way, but it is easier now to debug using a Laptop and the ability to display a complete rung.

It is still relevant, as you could re-use a bit to continue a rung to make it easier to fit the screen in GXDeveloper as this also has a limit (that is practical) to see on the screen when monitoring, however, they use K for the continuation on another line see pic. so either way I suppose is ideal, only thing is an un-experienced programmer may find it confusing and the number of double coil errors if using the same bit as an output.

L D[AR2 said:

What is the consensus on double coils used to make a rung more easily visible, e.g.

Click to expand...

I, with all due respect, consider this a bad style. Why not use an internal bit instead to split a long rung that way?

L D[AR2 said:

What is the consensus on double coils used to make a rung more easily visible, e.g.

Click to expand...

Since in today's processors, memory is not usually an issue, I avoid this methodology. I'll create an intermediate tag. Especially when the bulk of my integration work is in ControlLogix, and I always enable duplicate destructive coil checks as a sanity check. I'm uber OCD, so none of my programs ever have AFI's, Double coils, unused tags, undocumented tags, minor warnings in the log, etc. Every time I get one of my programs back a few years later, I even go in and correct all the ills the plant techs have added over the years...drives me insane.