CompactLogix Cycle Order

Hi all,

I'm wondering when the inputs and outputs are evaluated in a 1769-L30ER. Are IO evaluated live, during the program cycle? Or are they evaluated once at the beginning of the cycle?

I'm troubleshooting some code which has something like the following sequence:

rung7: If MyInput is received and SomeCondition is met, reject MyInput

XIC(MyInput)GRT(SomeCondition)ONS(oneshot)[OTU(MyInput),OTL(RejectMyInput)]



...rungs 8-15: some logic



rung16: MyInput triggers MyOutput

XIC(MyInput)XIO(RejectMyInput)OTE(MyOutput)



rung17: Clear rejection

OTU(RejectMyInput)

and I suspect that MYINPUT is becoming true sometime midway between rung 7 and rung 16. Is that possible?

PS. I know there are better ways to write the above code, but there's some red tape around this code, so I'm limiting the changes I make.

Thanks!

IO is evaluated asynchronously to the program scan in the ControlLogix/CompactLogix systems. This is true of both the chassis-mounted I/O and devices connected over the network.

An I/O update can occur even between lines of an ST program or between instructions in a Ladder Diagram. The smaller then program, the more likely that your I/O RPI will time out sometimes in the middle of your routine, since it has hundreds of opportunities a second to do so !

If you need to be certain that an input condition will not be updated in the middle of a routine, copy it to an internal tag at the beginning of the routine.

It doesn't need to by any fancier than "XIC MyInput OTE MyInput_State".

If you need to maintain integrity of a block of data, you can use the Copy Synchronous (CPS) instruction, which locks the input and output tags from being changed by an interrupt. But those take a little extra time to execute so I only use them when they're really necessary.

Logix5000 controllers update their IO asynchronously from the program scan. So you will absolutely see IO change between rungs. The only thing that would behave like an update task would be the RPI on the IO module.

If you want to execute the logic as written you will need to buffer the input into a holding register. This would be done by adding and input routine and setting the state of a logical bit equal to the input bit.

A general rule I avoid using OTU/OTL instructions unless absolutely necessary. I do this to avoid logic traps and make troubleshooting easier. Using branches to execute latching/unlatching functionality makes the current conditions easier to understand.

Another point would be to avoid resetting inputs in the manner you are. The input is a current state of the machine and should be treated as such, by not manipulating it. Resetting the bit will prevent you from using the true state of that input later. If you have a specific machine state set a bit using an OTE instruction with the conditions for that state as the conditions of that rung. Then trigger subsequent logic using the state bit.

Oh, heck, I didn't even see that he was using an OTU on an Input tag.

That's almost never a good idea. It's not normal, and it's going to be very confusing for a troubleshooter.

If this is code that's sacrosanct, the author is overdue for a peer review.

Ken Roach said:

Oh, heck, I didn't even see that he was using an OTU on an Input tag.

That's almost never a good idea. It's not normal, and it's going to be very confusing for a troubleshooter.

If this is code that's sacrosanct, the author is overdue for a peer review.

Click to expand...

Amen! The more you experience latching I/O instructions, the more you will learn to hate them. And hopefully, learn to avoid using them.

Thanks, guys! That's what I needed to know.

And yeah, there's a lot here that I'm hoping to rewrite if I get the opportunity. Good feedback all!

since you're asking about the CompactLogix platform, it would be a good idea to read up on this system's dedicated I/O Task - which has a task priority of 6 ...