AB Control logix asynchronous scan problem

[davegr]

Hello guys, I'm new here so go easy on me .

Right I have many years AB experience but I am using the contollogix plc with RSLogix5000 programming software for the first time and I have a couple of questions/problems.
Firstly, the I/O scan is now asynchronous. If I am monitoring the same input to set 2 different latches in 2 different parts of my program, I assume I could reach the end of the "scan" and find one latch on and one off? Does this mean that I should move all my inputs to internal coils at the start of the program, and then move internal coils to real outputs at the end, to artificially create a synchronous scan? I wouldn't even think of doing this in PLC5, what do you guys do?
On the same point, I have an HMI linked to the PLC reading registers (status info to make screen items change colour). But as I am writing to these registers different info at different points in the program, the HMI screen objects flash, since they can access the register at any point, and not at the end of the scan. So likewise I have had to copy these registers at the end of the scan to another group read by the HMI to overcome this.

TIA

Dave G

 

[Ron Beaufort]

If I am monitoring the same input to set 2 different latches in 2 different parts of my program, I assume I could reach the end of the "scan" and find one latch on and one off?

that is correct ...

Does this mean that I should move all my inputs to internal coils at the start of the program, and then move internal coils to real outputs at the end, to artificially create a synchronous scan?

in MOST cases, it doesn’t really matter if one latch was on and the other was off - at the end of a particular scan ... because ... on the next scan, the off latch would “catch up” and be turned on too ... BUT ... in SOME cases it certainly DOES matter ... and in those cases the procedure that you outlined is pretty common practice ... we usually call it a “buffer” ...


it sounds like you've come up with the same "buffer" idea for your HMI ... if I understand your problem correctly, then the technique that you've mentioned should work ... basic idea: an MOV or COP instruction is "synchronous" with the ladder logic execution ... specifically, the MOV or COP happens "RIGHT NOW" before the processor leaves that particular rung ... on the other hand, the update of the input and output tags is "asynchronous" ... specifically, the data in the tags can be updated at any point in time - and at any point in the ladder logic execution ... the "flicker" that you mentioned is one unpleasant result of this arrangement ... in most cases, the "buffer" arrangement should take care of it ...

 

[davegr]

Thought so, thanks. What is the advantage of an asynchronous scan? I can't see any myself. Why did Rockwell change?

 

[rdrast]

Thought so, thanks. What is the advantage of an asynchronous scan? I can't see any myself. Why did Rockwell change?

For one reason, it is because there may not be any actual cyclical task. You can delete the cyclical task, and have only timed or event driven tasks. If that were the case, when would you logically update I/O?

Another reason, is because, especially with large distributed I/O systems, it makes life much easier to schedule the actual I/O updates, without trying to fit them into a varying scan-time program. CIP ensures that I/O is updated at specific intervals.

 

[Gerry]

Why did Rockwell change?

If you've ever programmed a 1774, PLC-3, or PLC-2 with RIO, then you've worked with asynchronous I/O scans. You can also add the PLC-5/250 and the "classic" PLC-5 with RIO to that list.

Apparently the NP PLC-5's keep RIO scans synchronous (as Ron B pointed out to me some time ago).

Once you get into the power of CLX and start making UDT's, then the act of populating the UDT's will also accomplish buffering.

If using FBD, I believe the processor buffers all tags in a routine.

 

[TConnolly]

You also dont have to buffer for the entire program. Buffering for only the affected subroutine is adequate.

 

[russrmartin]

Examples

Can anyone give an example of how the program scan being asyncronous would have a negative affect? It seems to me that it is a non issue if you know this and write your program accordingly. I'm just trying to think of a time when not using a buffer could catch you with your pants down, so to speak.

 

[davegr]

Can anyone give an example of how the program scan being asyncronous would have a negative affect? It seems to me that it is a non issue if you know this and write your program accordingly. I'm just trying to think of a time when not using a buffer could catch you with your pants down, so to speak.

Here's a quick example (not got the hang of inserting ladder yet);

"Input001" "A"
---| |------| |-------------------------(B) Rung X

"Input001"
---|\|----------------------------------(A) Rung Y

In the above example, in a synchronous scanning PLC, coil B will come on for one scan, whenever the input001 goes from false to true.

However, in an asynchronous scan, this MAY not happen, if the input changes to true after scanning rung X, and before scanning Rung Y. In this case, A will then be turned off, and on the next scan, B will now NOT be turned on, since the contact of A is not true.

 

[Ron Beaufort]

here's another scenario ... it's a rerun from this thread that might make interesting reading - when you have some extra time ...

a customer had a program running perfectly in an SLC-5/04 processor ... but unknown to the customer, someone had inadvertently programmed a “double-coil” situation for one of the machine’s motor starters ... now even though this was an “improper” programming technique, it never caused any problems since the “last rung” in the scan always gave the proper control for the output ... specifically, the incorrect logic of the “first rung” was always overwritten by the correct logic of the “last rung” ... and so the machine worked perfectly for a couple of years ... later it was decided to take the program logic away from the SLC-5/04 and “port it” over to a new ControlLogix system which was controlling a much larger system nearby ... someone “copied-and-pasted” the ladder rungs .. and “searched-and-replaced” the addresses ... and shifted the I/O wiring over to the new ControlLogix hardware ... and turned the system on ...

and the motor starter went totally !nuts! ... because ...

the SLC platform only updated the field output once (at the end of the scan) when the “correct” (last rung) logic had properly controlled the bit ...

but the new CLX platform was able to also update the field output DURING the scan, when the “incorrect” (first rung) logic had driven the bit to its “other” condition ...

now I didn’t personally see this thing “go nuts” ... but the witnesses that I talked to said that you could have read a newspaper by the arcing-and-sparking from that chattering motor starter ... and I can assure you that to these guys “in the field” this little “asynchronous I/O scan” detail did indeed seem to be quite a “mountain” of an issue ...

 

[russrmartin]

I understand with Dave's reply, but my point was, why would you write your code this way knowing that the processor will act the way it does. Ron's example seems like it could be very possible, since I would imagine that there are several programs out there that are large enough that one would rather cut and paste than start completely from scratch. Thanks guys.

Russ

 

[davegr]

I understand with Dave's reply, but my point was, why would you write your code this way knowing that the processor will act the way it does. Ron's example seems like it could be very possible, since I would imagine that there are several programs out there that are large enough that one would rather cut and paste than start completely from scratch. Thanks guys.
Russ

The point being Russ, that if you are used to writing programs that employ a synchronous scan then take these techniques and employ them in a PLC with an asynchronous scan, then you MAY run into problems. Similarly if as was suggested above, a program is converted from a different Rockwell PLC that scans synchronously, then unforeseen problems may again occur. It's not a case of "bad" programming, just that what may have been perfectly correct for one machine may not be so for the controllogix.

 

[Gerry]

why would you write your code this way knowing that the processor will act the way it does.
Russ

Most of the time, an asynchronous I/O scan has no consequential effect on the logic. And so it is natural to ignore the implications until they bite you in the backside. Then, once bitten - twice shy.

 

[randy741985]

Just to Make sure what is being said here. The Discrete I/O is all that is asynchronous in the Program?

 

[OZEE]

No, all IO is asynchronous with the program scan.

 

[kamenges]

As a side note to buffering, the Logix 5000 programming environment has an additional copy instruction called a synchronous copy (CPS). This instruction will guarantee that data being copied will copy in a continuous block. This isn't usually an issue for a digital I/O card, where only one DINT is involved, although it possibly could be. However, communications to drives or larger controllers where the data blocks are larger opens you up to cases where the data will change half way through the copy. The CPS will guard against data consistency issues this can pose.


Keith