Problem with afi

Hi,

I'm having problems with an AFI. I copied and pasted a rung's logic, made a single edit, and AFId the previous logic in case they wanted me to revert the changes. But doing so caused problems. As you can see in the image everything in the rung is true therefor my output should be enabled but it's not. Has this happened to anyone else? If so why does that happen?
I'm using a control logix with remote IOs and my revision for the software is V17.

Dera Bsee: The reason is that your OTE T110300.FILL_OK is repeated, but the plc see the last one and that one has an AFI (Always false instruction)

What do you mean by the last one? As in it's last state or...?

"AFI"(always false) is just that, false,like any other instruction(s) on the rung. Its just always false . It does not cause the rung to not be executed (the rung is executed). So because the rung is false the output instruction at the end is turned off. Last one wins. The last instance in the program that controls the output in question.

Got it, thanks

The OTE programmed on two rungs are competing with each other. Rung 9 IS turning it on during the scan of that rung but when rung 10 is scanned it evaluate the rung to be false, due to the AFI and turns the output off.

I suspect if you put a trend on the output tag you would see it occasionally transitioning on and off. The rate will be so fast that each transition will not be caught by the trend.

Instead ot the AFI to inhibit the rung replace the OTE with an unused tag temporarily or substitute a NOP instruction in its place.

Thank you for your feedback

Afi

The rungs are been scanned from left to right & from up to down, that means rung 10 takes precedence over rung 9, so the processor remembers rung 10 right before it updates the output table, and since that rung 10 contains AFI ,it will be the one that the CPU takes it's decision against.

Hagos

ahhh... the joys of AFI's, reminds me of one time when I moved a motor's MCC from bucket A to B.

It should have taken 5 minutes, I ended up spending 4 hours.

The motor would run but the contactor would shatter very badly, the conveyor moving forward with excessive jerking.

I traced and checked every wire, swapped the contactor, auxiliary contacts....

When I sat down because I had explored every possibility and was about to revert everything, I figured that it had to be in the program.

So I cross-referenced the output and of course bucket B had its program on AFI in another task.... eurg.

Deleted the AFI rungs and problem solved...

I was turning on the output in my program but the later task would turn it off because it was AFI'd.

I'll show you how I test changes very easily and quickly.

Let's say this is the rung I want to test.

I want to bypass the PSC2.




I add a branch under the logic I want to change. Then, with a bit I created, I use an examine off for the original logic and I use an examine on for the logic to be tested.



That way, when I assemble the edits, the rung is still behaving in it's original way.

Then when I want to test the changes, I right click my test bit and toggle it.

So instead of taking 15-30 secs or more to re-modify my rung and assemble edits, it just takes a fraction of a second to toggle.

This made it possible for me to test out changes in production very quickly.

AFI's still examine the rung and set the output(s) to false. If you are wanting to keep the code without issue, use a [NOP] (no operation) or [JMP] [LBL] around it to prevent the rung from being examined.

You will probably still get a warning on compile that there are multiple OTE's with the same tag name.