Synchronous vs Asynchronous

It is said that the one of the differences between a CompactLogix and a SLC is the SLC is Synchronous while the CompactLogix is Asynchronous. If this is true, does this relate to how the I/O is updated or are there other implications? If it is only I/O related does this mean that the I/O on the CompactLogix are updated as soon as they change state or is it safe to assume they are updated at the end of each scan? Any clarification on this matter would be much appreciated.

first of all - there is CONTROL-Logix and there is COMPACT-Logix ... both of these are asynchronous (that is NOT synchronous) - BUT - they are not both the same ...

since you mentioned the COMPACT-Logix, you might be interested in this thread:

http://forums.mrplc.com/index.php?showtopic=26162&p=125399

since you mentioned "as soon as they change state" - you MIGHT be thinking of the Change Of State feature for the CONTROL-Logix platform ...

If it is only I/O related does this mean that the I/O on the CompactLogix are updated as soon as they change state

Click to expand...

no ... the CONTROL-Logix can handle that type of update (it does have a Change of State setting) - but not the COMPACT-Logix ...

is it safe to assume they are updated at the end of each scan?

Click to expand...

no ... in GENERAL terms, the I/O for the COMPACT-Logix is updated at the RPI setting (Requested Packet Interval) which is assigned to the Local Bus ...

DISCLAIMER: I've heard a rumor that AB has been changing the COMPACT-Logix to allow more flexibility in how its I/O is updated ... the version that I'm most familiar with is version 16 ...

in the SLC, the PLC followed the standard (synchronous) scan cycle:

1) read inputs
2) process code
3) write outputs

In the Logix platform (asynchronus), the IO is written to whenever the PLC decides it should (based on task priority and the RPI of the IO). This means that your low priority code will probably have an input that has a different state at the beginning of the scan than at the end, and you must account for this in your code.

I think it is generally considered a "Best Practice" to have an IO MAPPING routine that copies all the Inputs to other tags at the beginning of your main code, and then copies intermediate tags to the outputs at the end of the code.

I'm not quite sure why Asych is a considered a "feature", but that's probably a separate discussion.

Thank you for the feed back! It is much appreicated.