Overflow Trap Placement

I have a SLC 5/05 application that keeps faulting every couple weeks to a math overflow.

In the logic there is a math overflow S:5/0 on an unlatch instruction in the main ladder LAD 2 but it is above about 20 JSR instructions that call other subroutines.

Should this be overflow trap be located after the JSR's and be just above the end instruction?

I am thinking with it above the JSR's it is only protecting the logic in LAD 2 but if I move it below the JSR's and place it just above the end instruction it will protect the entire program?

Am I correct on this?

Hi Tim

That is correct.
It may be worth looking through your data files when the plc is faulted to see which one is causing your problem. It is not always easy to find but it's always with a look for a value that's above 32000

Donnchadh

Yes, the best position for that logic is at the very end of LAD 2. You can still have additional logic to monitor the separate overflow bit so you can still do something about the math overflow. This unlatch just prevents the controller from faulting because of the overflow trap bit.

OG

I would use the over flow bit to latch a unique coil and reset the overflow bit after every divide. This way you know where the overflow occurs and can fix it.

Peter Nachtwey said:

I would use the over flow bit to latch a unique coil and reset the overflow bit after every divide. This way you know where the overflow occurs and can fix it.

Click to expand...

There are many more instructions which can set the Math Overflow status than just divide instructions. And of course all of them will set the "trap" bit when overflow occurs.

FWIW, Logix500 is the only "family" of A-B processors that has the additional "trap" bit, which, if still set at the end of the scan, causes a major fault. Perhaps someone thought it was a good idea, but has been dropped again in Logix5000, so clearly not a great idea.

I am just so used to seeing OTU S:5/0 as the last rung/instruction in a Logix500 program. Any math overflow that is significant in an application should have been dealt with as it occurred, not at the end of the scan. Any "damage" that could be attributed to math overflow has already been processed, up to the end of the scan.

Summary - put an unconditional rung with OTU S:5/0 as the last rung of file 2. Deal with any arithmetic status bits as required, for each "important" piece of code.