Programmed I/O image tables

Just out of curiousity, is there any hardware based reason that AB compact logix PLC's need programmed I/O image tables?

i.e. Inputs straight to markers, and markers out to outputs.

It's something I haven't seen much of in the Siemens "world", but some people more familiar with AB seem to like / spec. them.

Is it a fallback on the "old days" when PLC's required this kind of thing, or are the AB units dynamically looking at I/O all the time?

I can see some benefits in regards to keeping on the fly mods out of the "core program", but otherwise am unsure about its pro's and cons.

Thanks.

The ControlLogix PLC IO updates are asynchronous to the PLC scan and occur at the scheduled module update time. Also, different tasks are running at different rates. That means that the status of an IO tag can change in the middle of the scan. Most of the time that doesn't matter but sometimes it does. In those cases where it does matter, the programmer buffers the IO state of the tag of concern at the beginning of the program or subroutine scan. Some programmers prefer to buffer everything just so they don't have to worry about it. Its a matter of personal preference.

Alaric just beat me to it, but, I'll submit this post anyway.

The Logix family of processors have a separate processor whose only job is to handle comms between I/O tables and I/O. This means that as your program is scanned and processed, the I/O table is updating on it's own cycle. For example, if you are checking for an input to be true on 1 rung and the same input to be true on a 2nd rung, it is possible for the input to change state in between scanning the 2 rungs.

To get around this, some programmers use the CPS instruction to copy an I/O table to a tag array and use this tag array to monitor I/O.

It is not necessary to perform this copy and, I myself, rarely do it. It's just a good idea to keep in mind that the I/O table is changing throughout the PLC scan.

I actually use it for an additional reason ...

I have a "library" of reusable code. I can put my code in any controller, then "map" the IO to the code.

Thanks all, that really does clear things up somewhat. Both the asynchronous update issue / feature, and Oakley's "library" reason make good sense.

Thanks.