FAL Failures

I am looking at a PLC5/80E progam with two FAL instructions in parallel on the same rung. The first instruction moves 10 elements of an integer file to another integer file. The source data is referred to by an indirect address. The Expression in the FAL is #N54:[N10:199]. The second FAL instruction moves 10 zeroes into the source mentioned above. The Dest for the second instruction is #N54:[N10:199] and the expression is '0'. Both instruction operate in ALL mode.

These FALs are part of a system to track parts into carriers and out of carriers along a plating line. The data refers to the part types and production codes. The integer locations represent the physical locations along the line or on the carriers. The data is supposed to follow the parts through the line from carrier to plating tank, to carrier and then into the next tank and so on.

Every now and then the part data gets dropped. Zeroes arrive in a location and then travel along with the part to the end of the line.

I suspect that the problem is order of operation/timing. My best GUESS is that the second FAL is completing before the first because of the indirect addressing.

KerryP said:

I suspect that the problem is order of operation/timing. My best GUESS is that the second FAL is completing before the first because of the indirect addressing.

Click to expand...

You could test this by conditioning the second FAL with the done bit of the first. However, (and I have no knowledge of the internal workings of the PLC-5 interpreter) I don't believe the PLC-5 does multitasking on the ladder logic. I'm pretty sure it does one instruction to completion - excluding file operations spread over multiple scans - then the next, ad infinitum.

That was my thought as well. I will just have to make sure my rung conditions are true long enough for the first instruction to complete and hold the DN bit on to initiate the second instruction. Thanks.

Do you have any interrupts whci may affect the part number? I don't think ordinary instructions can be interrupted but I think I remember reading that the multi-operation ones, like these FAL instructions, can be interrupted between the individual operations.

No interrupts are in this program.

The PLC5 Instruction Set Reference says that these instructions are asynchronous to the program scan. The overall times on this processor hover around 64 mS so it is pretty busy. I suspect that the indirect addressing in the first instruction sometimes takes a tiny bit more time than the 'move zero' work of the second instruction and the data is zeroed out before it is moved.

The PLC5 Instruction Set Reference says that these instructions are asynchronous to the program scan

Click to expand...

Do you have a reference for this relative to FAL commands? I only see it for items in MSG, block I/O and ASCII commands.

My bad. I found the reference to asynch FAL not in the Instruction Set Reference but in another forum where a writer testifies to such coming from AB tech support. I've been reading a lot of sources on this problem.

I am working up the nerve to try delaying the instruction that clears the data with the DN bit from the instruction that moves the data.