Prolific use of --[AFI]--

Some of the code I see has a notable amount of "Always False Instructions" where the ladders had been modified at some point and then the --[AFI]-- was just left in, along with the rest of the rung(s) that are now always false.

I am not a programmer, but I was taught to run a tighter ship than that. If the rung is no longer used or needed it should be deleted and save memory and processor cycles, not to mention making the code much cleaner and easier to follow.

It's not a method I follow, but I can understand the rationale behind preserving the original state of the program for reference. This is especially true if a good archive is kept and rung/page comments tell you which user made the change and when.

When I have multiple programmers working on a project and we need to add temporary or test code, we use BOOL tags with our initials. The rule is that you remove the tags with your name, just like you would remove your physical locks, before you leave the project. We don't always follow this rule perfectly, but it's a step in the right direction if you don't have a formal version control procedure.

I agree, or, if left it there intentionally, must accompany with comments. That will be the least you can do for who ever take over.

iraiam said:

Some of the code I see has a notable amount of "Always False Instructions" where the ladders had been modified at some point and then the --[AFI]-- was just left in, along with the rest of the rung(s) that are now always false.

I am not a programmer, but I was taught to run a tighter ship than that. If the rung is no longer used or needed it should be deleted and save memory and processor cycles, not to mention making the code much cleaner and easier to follow.

Click to expand...

Only time I use AFI in code is during commissioning. Sometimes , you may need to alter some rung of code to get a something to work right. I would use the AFI to leave the original code intact, but not operational, in the event I need to revert back to the original code.

Of course though, good programming practice dictates that the AFI code is removed once no longer required.

chavak said:

I agree, or, if left it there intentionally, must accompany with comments. That will be the least you can do for who ever take over.

Click to expand...

the only problem with this is if the program comments have been lost.
this is normal as a new programmer will make the mistake and loose comments.
Also - if there are two program versions open at the same time the comments are not saved.
I have seen some AFI's still in the program as the program is being continually updated.

Be careful as AFI's are also sometimes used to make certain code function and it will not work without them. In some cases they are not used to disable code but to make it work.

Another valuable lesson I learned from Ron Beaufort.

I use the AFI instruction quite a lot. And a set bit on the RSLogix 500 programs that I use as an AFI bit (usually B3/100)

It is handy when you are in a constantly changing shop to be able to quickly change a machine to an older state, without having to download an older revision. It's also handy in some of our larger processes when something important is being change to keep the old code as a reference for later.

I also use AFIs as temporary bypasses for things that fail (until the replacement comes in) or features that need to be removed for short time.

I find it easier to be able to reference the old code in the program than opening an older version and flipping between files to reference the same old code.

I had a thread here where an old GE program used AFI's in every program section. It was really really bad, but the program worked. If this topic is still active Thursday, I might be able to load it in a PDF.
(or someone else could.) Right now it's in a GE zip file.

I find AFI's very useful for setting bits "off" through out a program. In a config file for an AB drive I like to disable the REV with an AFI and have no conditions to enable the FWD.

"Example 1305 Control word on RIO."
Set the drive direction only for forward.
Direction | 5 4
-------------------------
No Command | 0 0
Forward | 0 1
Reverse | 1 0
Hold Direction | 1 1

There's plenty of other examples I use and have seen used. I don't find this bad programming practice at all. But i do agree if used disabling "old" code it should be deleted asap.

I must admit, previously, I did use a lot of AFI's in my code, purely for continuous structure. That all stopped when I got a call in the middle of the night, when Bubba had gone online with the PLC without the offline file, so all comments where lost.

He saw the AFI's and figuring they shouldn't be there went through the entire PLC code and deleted every single one of them. Needless to say this caused huge issues, since code was running that shouldn't have been.

I now delete all code that has an AFI anywhere on a rung.

While I am commissioning I always have an Always_On bit, and Always_Off bit and also a Mark_Test_Dint, Mark_Test_Float etc. That way I always commission the part of code with the test bits before moving on to the next.

Mark

Normally I use AFI, when troubleshhting a program, also when I make changes. Normally I use comments and leave the afi rungs commented in case I need to use them in the future.

IMO old code and code that is no lomger being used should be taken out and comments cleaned up.

In a lot of our old equipment the AFI instruction is used to rest FAL instructions for alarms handling.

There are several comments made throughout this thread that points to a misuse of AFIs.

An example, and no offence, "I would use the AFI to leave the original code intact, but not operational". This is OK when the alternative code is built on the same rung as the original (as a branch structure), but if used on whole rungs, and replacement rungs added, then problems can occur.

It must be stressed that a rung with an AFI on it is still operational, the AFI just makes whatever follows it False. The remainder of the rung is processed as normal, except that "Rung Logic Continuity" is now false. In truth, an AFI does not "disable code" at all.

So, if AFIs are employed to "disable old code", and new code is inserted to drive the same outputs, then you are creating "Duplicate Destructive Bit References".

Most people are aware of the pitfalls of duplicating outputs, but for the uninitiated, the most important are......

1. The "Last One Wins" rule applies.** The latest rung sets the state of the bit that the rest of the code "sees".

2. Code becomes "Position Dependant". You have to be careful when inserting rungs, that you are not putting new code in that looks at the transient state of the output bit on the rung, i.e. after the AFI'd rung, and before the rung that makes it true.

** Last One Wins rule applies to internal bits only, but when these bits are real-world outputs (as in the case of Logix5000 systems), the Last One Wins rule goes out the window, because I/O is exchanged with the I/O modules asynchronously to the program scan. You could be sending your AFId output to the module briefly, and depending on the I/O exchange rate (RPI), this could cause problems in the field devices. There is no issue with Logix5 or Logix500 real-world outputs, because these are internal data-table bits, that are exchanged with the I/O modules between program scans.

Also be aware that AFI'ing a rung with a Timer on it, will reset the timer!. The same applies to any instruction that is triggered by a "False-to-True" transition, e.g. FAL, FSC, CTU, CTD, MSG, etc.

There are better, safer ways to "disable" old code, you have to devise a way to stop the processor scanning it, so that it doesn't set any inappropriate states, or take any inappropriate actions.

You could use a JMP/LBL combination to completely skip "old" code, but this doesn't remove pitfall no.2 above. You would still have an area in your logic that is a "no man's land".

My preference is to relocate the "old" code into a dead subroutine file (one that is not called), and put my "new" code into a subroutine that is called. You can even condition the subroutine calls on the state of a bit, so that you can switch between "old" and "new" by toggling the bit.

Whichever way it is done, documentation is paramount, so that everyone is made aware of the situation.

Actually, in Version 19 (and perhaps earlier) of RSLogix 5000, the AFI is flagged as a warning. It was not in v16 (and later, perhaps).
So, at least, if there's an AFI in there, you'll know pretty quick.
Of course, for every BAD thing about them, there is a GOOD thing...at least you can (sort of) "see" what the previous programmer was trying to do...he just didn't clean it up.

daba said:

My preference is to relocate the "old" code into a dead subroutine file (one that is not called), and put my "new" code into a subroutine that is called. You can even condition the subroutine calls on the state of a bit, so that you can switch between "old" and "new" by toggling the bit.

Click to expand...

Daba's method above is what I use for long term old code left in the program and just deleting rungs with a online edit but leaving in test for short term fixes.

In addition make sure the "Old Code" is in the desired state when left in the subroutina as it and the outputs it controls internal or real world may remain in that same state without the subroutine being called any longer.