AB PLC FAL Instruction Problem


Thread Starter


Although my experience with Allen Bradley PLC's is limited I was recently asked to review and debug a new AB PLC program. This program is running in a PLC-5 processor with ControlNet I/O and an Ethernet link to a PC running RSLogix (Most recent revisions on all).

I discovered that a series of four FAL blocks with indexed addressing (Mode=All) performing minor functions (move, AND, XOR, and move) were working sporadically and incorrectly. For
example, if I managed to get the first Move function working the AND function would stop functioning altogether. After trying various
things for over two hours I decided on a hunch to zero the S:24 offset pointer value prior to and after every FAL block. This seemed to solve the problem (although I'm still not entirely convinced)

I then talked to several experienced PLC programmers who have never zeroed this pointer and have never experienced these difficulties.

I then talked to Allen Bradley Technical support. They confirmed that I did the right thing. The contents of this pointer can become
out of sync and that resetting it prior to running an FAL block is a necessary and important step. As it turns out this point is stated in their manuals.

They also confirmed that an FAL block with a Mode=All runs synchronously - the block will complete its function until the end of the table is reached prior to scanning the next line of logic

Allen Bradley Technical Support stated that this has been an issue within AB PLC programs for at least ten years.

I can find no Allen Bradley PLC programmers that have given this pointer special consideration within FAL instruction blocks.

Has any one else out there experienced these problems? Does any one else reset this pointer prior to running an FAL block?

Thank You


George Robertson

I use this instruction extensively, have not had this problem, and have never reset the pointer.


[email protected]
George G. Robertson, P.E.
Manager of Engineering
Saulsbury Engineering and Construction
I have used the FAL function with several PLC5
projects and have never reset the indexed register.
Nor have I ever encountered the problems that you
have described. Are you using the same control
word for all of your FAL instuctions? You shouldn't. If you are, that would account for
the problems that you are describing.
Not with FAL instructions, but with any instructions that i need to do indexed addressing (mostly on SLC), I have made a habit of using my own register to track what S:24 should be, and explicitly putting my value there each scan right before the instruction. This has cleared up erratic operation in the past where several
instructions are fighting over the register.

If it corrects the problem, I have learned, it is best just to accept it and move on. Be one with the processor. Focus.....NA NA NA NA NA NA NA NA....... (<- cheesy Caddyshack reference)

seriously, this may not be required most of the time, but with this and the math registers, I have found it is best to 'prep' them before doing anything that they can mess up.

--Joe Jansen

Phillip Costantinou

I've used it and had a similar experience. I didn't reset the offset pointer; I put a normally closed contact ".DN" bit from the control word to the left of the FAL. This worked I didn't look back as to whatever else the problem may have been. Thanks for the heads-up on zeroing the
S:24; hope I remember that next time.


Phillip G. Costantinou, P.E.
Instrumentation and Controls Engineer
I.C. Thomasson Associates
2950 Kraft Drive
Suite 500
P.O. Box 40527
Nashville, TN 37204-0527
(615) 346-3400 Switchboard
(615) 346-3431 Direct to desk
(615) 346-3550 FAX
[email protected]
Hello Dave,

Just a guess but are the FAL instructions all using the same Control Block element?? Each FAL instruction must use a unique Control Block element. Forward the program to me and I might be able to add some insite to your problem.

Please contact me offlist if you would like.

Bradley G. Hite
Intertech Inc.
mailto:[email protected]
ICQ# is 38746036
Teaching Practical Skills For a Technological World

Anthony Kerstens

I haven't used the FAL much, but I find it interesting that Mode=All causes the block to run synchronously.

AB I/O updates are asynchronous. That is, I/O can
be updated at any point within the logic scan. This is necessary because of subroutines, and the possibility of long logic scans. Is there any I/O used as part of the FAL or driving logic that may not have thought out by the original programmer? Are you able to figure out how long the FAL takes to complete?

Anthony Kerstens.

Larry Lawver

Responding only to this statement:

>AB I/O updates are asynchronous. That is, I/O can
>be updated at any point within the logic scan. This is
>necessary because of subroutines, and the possibility
>of long logic scans.

This isn't generally correct. The original PLC worked that way, and the Pyramid Integrator and ControlLogix can do that OPTIONALLY, but SLC500s and PLC-5s are always buffered through the Input and Output Image Tables. That is, the normal scan goes like this:

1. Real world inputs are read into the Input Image Table.

2. Logic is scanned, including called subroutines. Inputs are read from the Input Image Table. Potential real world outputs are
updated in the Output Image Table as they are calculated. The results of these calculations are available to downstream logic, but the real world doesn't know about them until...

3. At the end of the logic scan, the Output Image Table is written to the real world outputs.

"Asynchronous" I/O updating as described in the post is possible in several ways, including Immediate Input and Immediate Output
instructions, but these are special programming techniques, not the basic operation of the processors.

Hope this helps!

Larry Lawver
Rexel / Consolidated / Central Florida
-> AB I/O updates are asynchronous. That is, I/O can
-> be updated at any point within the logic scan.

Is this specific to the PLC-5? I have worked quite a bit with the SLC-500 systems, and I am fairly sure they are synchronous. Is this a difference of processor type?

--Joe Jansen
My experience with PLC-5 says that the I/O update is in fact synchronous. And the FAL in ALL mode is completly executed on each scan as the processor "visits" the rung. The new ControlLogix
I/O update is asynchronous because the various I/O modules are in control of the update. There is something else wrong. I have never had to specially condition FAL components. I suspect a STI raising havoc?

I have used the FAL instruction for years in many PLC applications and have NEVER seen this problem.
> Is this specific to the PLC-5? I have worked quite a bit with the SLC-500 systems, and I am fairly sure they are synchronous. Is this a difference of processor type?

Dear Joe,
PLC5, PLC2, SLC, & MicroLogix all use the IO Image
Table as described previously.

Anthony Kerstens

Verification from a very good source.

Anthony Kerstens P.Eng.

> -----Original Message-----
> From: Jeff Haskett [SMTP:[email protected]]
> Sent: Thursday, June 08, 2000 10:59 AM
> To: Anthony Kerstens
> Subject: RE: PLCS: AB PLC FAL Instruction Problem
> Anthony,
> The statements below are correct. The SLC500's and the PLC 5's do
> operate as discribed below, that is input image update - program scan
> including called subroutines - output image update. Immediate input and
> immediate output instructions can be used to interupt the program scan and
> update the input and output image tables if real world through out is not
> fast enough (note that using these instruction will increase scan time
> further).
> As for ControlLogix the inputs are updated asynchronously to the program
> scan. This is due to the added intelligence built into the input cards
> themselves. Output are updated at the end of every program! ControlLogix
> supports 32 task each contaning a maximum of 32 PROGRAMS which can contain
> as many subroutines as memory and throughput can support.
> I hope this helps.
> Jeff Haskett
> Automation Account Manager
> Gerrie Electric Automation Group
> Tel: 905-681-3668 x 387
> Fax: 905-681-7091
> email: [email protected] <mailto:[email protected]>
> -----Original Message-----
> From: Anthony Kerstens [mailto:[email protected]]
> Sent: Thursday, June 08, 2000 10:22 AM
> To: '[email protected]'
> Subject: FW: PLCS: AB PLC FAL Instruction Problem
> technical discussion?
I'd like to thank everyone for your responses to my AB PLC FAL instruction problem.

In response to a couple of the questions:

1) The FAL instructions in this program are not using the same control block element(word) . This is a good guess but was one of the things that I had checked for.

2) Although we did discuss the length of time to run the FAL block we didn't try to accurately calculate it. The algorithms are simple and the table length is only 40 words so we didn't expect
that it would be an issue. Our complete program scan time is about 30 ms.

The issue that I find puzzling is the number of people that have never experienced these problems. Where is the difference? How many programs out there do not take the S24 issue into account? Will these programs stop working correctly at some point? Are they working correctly now?

I would like to close with the following paragraph from the PLC5 Instruction Set Reference Manual:

"ATTENTION: Instructions with a # sign in an address manipulate the offset value stored at S:24. Make sure you monitor or load the offset value you want prior to using an indexed address. Otherwise unpredictable machine operation could occur with possible damage
to equipment and/or injury to personnel."

Thanks again.

I can find no Allen Bradley PLC programmers that have given this
pointer special consideration within FAL instruction blocks.

Has any one else out there experienced these problems? Does
any one else reset this pointer prior to running an FAL block?

I don't use FAL instructions cause of the strange way they work makes them difficult to debug, but I believe they do indeed change the index value in
the status table. I prefer to create my own FAL like code based on indirect addressing that is much easier to debug.

Bob Peterson

Anthony Kerstens

As far as I had understood, all AB PLC's are asynchronous. However, could someone from AB verify this?

If the SLC's are synchronous, then some of my logic written in the past could be greatly simplified.

Anthony Kerstens P.Eng.
I speak to my experience with PLC-5/xx family.
I think that AB is responsible for confusing the
issue. They describe RIO network as asynchronous.
I think that reads from physical I/O in the
local chassis into the input image table and writes to physical I/O in the local chassis from the output image table are perfectly synchronous.
I think that transfers of remote I/O images
between some kind of 'workspace' and the image tables is synchronous. But, reading/writing from/to physical remote I/O into/from the 'workspace' is asynchronous. I have poured
through AB documentation looking for a definitive answer to this question. Haven't really found it. I agree with Anthony, I think it would be great if someone from AB would respond and verify.

Bill Code,
MPM Engineering Ltd.

Jeremy Pollard

Some of AB's documentation talk about an asynch I/O scan and in fact the PLC 5 has it, but the I/O image table is updated synchronously to the program scan. The PLC-3's were asynch all the way, and the Controllogix is a hybrid. Some may have been confused with the wording.

Tech writers unite:)

Cheers from:

Jeremy Pollard, CET
[email protected]
On The Web - http://www.tsuonline.com
PLCopen North America - [email protected]
the Training Factory, Inc.
Programmable Controller Support Systems
The Software User Newsletter ONLINE
The Crazy Canuckian!
8 Vine Crescent, Barrie, Ontario L4N 2B3
705.739.7155 Fax 705.739.7157
Hi All

Its been a while since I used a PLC5 but I will have a shot at answering some of these questions from memory.

FAL Instructions. There were a number of transfer modes offered.
All - the entire file to file transfer was done prior to execution of the next instruction. n transfers per scan where n number of elements
(words) were transferred per scan. eg if the file length selected was 100 and n =10 then it would take 10 scans to complete. Note that the 10 transfers in each transfer were done prior to execution of the next instruction. Finally I think there was also single which was equivalent to n=1. The main point here is that the actual transfer was still synchronous to the scan, just with the potential to break it down to byte size (excuse the pun) pieces.

Next scanning RIO. It is true that the ASB (the remote scanner) does scan asynchronously to the PLC program scan. However, the I/O data is still presented to the PLC's I/O table during the I/O scan of the PLC. The PLC is synchronous with the following general phases housekeeping, I/O scan, ladder scan.

As already stated this is from memory on the PLC5 classic and may be out of date but better some answer than none. I think AB are still fighting fires as usual and don't have time to respond to
such trivial questions posed by clients.

Allan Dow
Embedded Systems & Solutions

Dave Ferguson

I think your point is well taken. You need to control the S:24 register. A lot of people probably are not seeing an issue simply because the code doesn't include other instances of manipulated s:24 registers. No other # file uses or no other FAL or the S:24 pointer is in a state that does not hurt it. I have programs that have
values changing in this register and I never knew why but no trouble.

Put a histogram on S:24 and see it change........

Dave Ferguson
Blandin Paper Company
DAVCO Automation