Very basic PLC question

I will apologize in advance for this question.

In a PLC scan I understand the inputs are read, then the PLC carries out a scan out the logic and then the outputs are acted on. But what about internal (memory) bits/coils.

eg.

If on the rung 1 a digital input 1, going high energises a memory coil M1

on rung 2 M1 contacts close to energise Digital output 1 Q1

on rung 3 Q1 contacts close to energise internal coil M2

What would be the sequence of events, scan by scan?

Look on YouTube for Ron Beaufort's Videos and have a look. He does a great job of explaining the PLC Scan and everything that takes place.

As for internal memory locations I believe that they are acted upon right away. So in your example:
1. If IN1 is true (Go Look for a 1) then M1 is true (Put a 1 in M1's bit box)
2. M1 is true (because of the 1 in its bit box) from R1 so Q1 will be set true (put a 1 in Q1's bit box, although the actual output will not chance state until the end of the scan)
3. Q1 (because of the 1 in its bit box) is true from R2 so M2 will be set true (put a 1 in M2's bit box)

end of scan write the output table (Q1=1) to the actual outputs.

Exactly as you've described it. In general (there are always exceptions), your ladder will be scanned sequentially, from left to right, and top to bottom. Your PLC never "looks back". So, if you had a a rung like this, and when the rung started executing, M1 was true: ...then the PLC will execute as follows.
- M1 is true, therefore, execute the instructions at the end of the rung
- First instruction to execute: turn off M1
- Second instruction to execute: turn on M2
M2 now remains on for the rest of the scan - even though you would look at that rung, and see that M1 is off and you might not think it would execute the coil for M2. But by the time it gets to that point, the PLC has already proceeded past that ---| |--- of M1, and decided it was true. It won't look back at it.

So, as your memory bits are set/reset in the code, they are on/off from that point onward. That also applies to I/O, for that matter. e.g.: In this instance, the PLC will turn on both Q1 and Q2 in the same scan (or rather, after the same scan). It does NOT activate Q1, wait for the rest of the scan to continue, turn on the output, and then come back through and say "OK, now Q1 is on, so I'll turn on Q2. As far as the logic is concerned, as soon as you set a bit, it's set. It's purely the hardware that's not updated until the end of the scan.

One final tip: not all PLC's do the "read inputs....execute code....write outputs" any more. Compact Logix and Control Logix PLC's, for example, update the I/O asynchronously, which means the status of an input could be updated halfway through a rung. Search the forum for threads on this topic and you'll find a ton of information on this, including things to be aware of and ways to overcome it.

Hope that sheds some light on things for you!

Be warned that some PLCs - at least one Modicon - scan in a 'column' order (down the first column then down the second) instead of scannning a complete rung before proceeding to the next. Thus, for this type PLC scan, in ASFs second picture Q1 and Q2 would turn on in suceessive scans if the two rungs were in the same 'network' (page of rungs).

....and there's the exception

I learned Allen Bradley first.

When we had to use another PLC I was 'what??? They call their inputs, outputs and memory something else??? And they don't even number them the same??"

But then I calmed down - 'well at least it scans rungs the same'. Well I guess I can accept some differences.

Then Modicon came along...

When I finally figured out that Modicon was, in effect, solving spreadsheet cell formulas I could see where they were going.

And on and on to various languages and control layout philosophies and whatever. So after 30 some years of PLCs I learned to become very flexible in my thinking.

So a PLC senses conditions, combines that with remembered states/data, implements rules, then causes changes. And around and around.

Yeah in MODICON "rungs" are networks, a grid of 8x10 IIRC. Other PLCs also have the grid approach. A network could contain however many "rungs" you could fit in the network/grid.

The grid verse rung approach provides for some different logic patterns.

And that's in their old LL984 stuff. Very different beast now when running Unity.

Unless I'm mistaken (which is very possible) The latest AB processors scan and update the I/O asynchronously. I'm not very familiar with AB stuff so maybe I only imagined that I read that.

Found it. From the manual:

In Logix5000 controllers, I/O values update at a period that you configure in the
I/O configuration folder of the project. The values update asynchronous to the
execution of logic. At the specified interval, the controller updates a value
independently from the execution of logic.

Nick

Manglemender said:

Unless I'm mistaken (which is very possible) The latest AB processors scan and update the I/O asynchronously. I'm not very familiar with AB stuff so maybe I only imagined that I read that.

Found it. From the manual:

In Logix5000 controllers, I/O values update at a period that you configure in the
I/O configuration folder of the project. The values update asynchronous to the
execution of logic. At the specified interval, the controller updates a value
independently from the execution of logic.

Nick

Click to expand...

Nick, Yes it does, so I ALWAYS map my IO and use old school techniquie of map the inputs at the top of scan and outputs at end of scan

http://accautomation.ca/understanding-the-plc-program-scan/

Here is some additional information on understanding the PLC program scan.

Regards,

cjd1965 said:

Nick, Yes it does, so I ALWAYS map my IO and use old school techniquie of map the inputs at the top of scan and outputs at end of scan

Click to expand...

Same here....I've never trusted aliasing and asynch updates to I/O in CLX.