RSLogix 500 Fault Error 20h (Math Overflow Trap S5:0)

I strongly disagree

That "fix", which so many use, merely papers over the problem, it doesn't correct it.

He's trying to calculate (31206 * 8000) / 20000. The answer he expects is 12482 (rounded). The PLC is giving him "2" in N7:2. It knows this is probably not right, so it correctly flags the mistake, and hopes that the programmer will correct it and then clear the flag. The programmer didn't, so the PLC shut down before someone gets hurt.

Blindly OTUing S:5/0 could be just as catastrophic as having the PLC fault.

What the programmer is supposed to do is, for every calculation that could result in an overflow error, is to XIC S:5/0, then take steps to correct the math, possibly by using S:13 & :14, and then OTU S:5/0.
 
Last edited:
That "fix", which so many use, merely papers over the problem, it doesn't correct it.

He's trying to calculate (31206 * 8000) / 20000. The answer he expects is 12482 (rounded). The PLC is giving him "2" in N7:2. It knows this is probably not right, so it correctly flags the mistake, and hopes that the programmer will correct it and then clear the flag. The programmer didn't, so the PLC shut down before someone gets hurt.

Blindly OTUing S:5/0 could be just as catastrophic as having the PLC fault.

What the programmer is supposed to do is, for every calculation that could result in an overflow error, is to XIC S:5/0, then take steps to correct the math, possibly by using S:13 & :14, and then OTU S:5/0.

"Papering over the problem", never corrects it, for sure. But have you considered that the "trap" bit does not feature in any of A-B's other PLC ranges, only Logix500.

When the trap bit causes the PLC to fault, it is too late, and many more data-table values could have got corrupted during the remainder of the scan, sequences triggered to deal with the apparent under/over range measurements, shutdown procedures initiated, alarms set, etc. etc.

Yes, in the ideal world, the programmer could inspect arithmetic status bits after every arithmetic instruction, adding tons of lines of code to the application, but any half-decent programmer would not configure code that can produce such errors in the first place.

If the "trap" bit was so useful, how come they dropped it for Logix5000 ?
 
Why? Because people complained. No one likes having their poor programming skills exposed to management ("We lost a batch because the programmer didn't check for divide-by-zero"). And it's certainly arguable that stopping the processor is more safe than living with a math error.

Keep in mind that when it was introduced, the SLC was intended for small systems, especially OEM skids, not whole production lines. But like anything, once released, it got used in ways that were never intended by the designers.

I'm better than half-decent in my programming skills, yet even I've overlooked a divide-by-zero scenario from time to time. Why are you arguing in favor of poor coding practices? Because for better or worse, that's what S:5/0 is intended to protect against.
 
Evaluate S:5/0 in several well-chosen rungs.
That will narrow down the possible code locations, so you just have to check a few.

If the error is possibly with a floating point instruction, open the floating point file in question online and look for "NaN" (Not a Number). If you find any adresses that have this value, then use the cross reference to find where this is written to.
 
Hi Ron,

I've had a quick read of your linked posts (especially #4), and I don't believe the following additional advice is in there. If it is, and I've missed it in my quick "scan" of your excellent posts, then do please forgive me...

ashu2shreya said:
Hi i am having same error of math overflow but i dont know error at which rung. Can u plz tell me how to check?

"If" your program has more than one subroutine, then you can also add the same trap logic Ron outlined (XIC S:5/0 OTL Bx:y/z NXB OTU S:5/0) after each JSR instruction in Ladder 2. This will first allow you to narrow the Math Overflow problem down to which subroutine, or subroutines it is occurring in. Then you can head on in to any of the subroutines that were flagged for a Math Overflow for further investigation.

For each JSR instruction the "Bx:y/z" storage flag would be designated as follows...

x = Binary Data File of your choosing or creation
y = Unused Element within that Binary Data file
z = Unused Bit address within that Element to represent subroutine number

Example: Create B Data File "B10", 1 x 16-bit Element

LAD 2 = B10:0/2 (only required if Math instructions used in LAD 2)
LAD 3 = B10:0/3
LAD 4 = B10:0/4
...

You don't have to add these JSR flags if you have trap logic added after each Math instruction in each subroutine, as Ron suggests. It might help or not in those situations. But if your subroutines are reasonably short and you don't want to or there is not individual traps, then the JSR trap method may be useful in narrowing it down so as to temporarily add a trap or two into the flagged offending subroutine(s).

Regards,
George
 
Hi i am having same error of math overflow but i dont know error at which rung. Can u plz tell me how to check?

Here's what I do:

First, I find two consecutive, unused bits. Let's say B10/0 and B10/1.


Next I will TEMPORARILY add the following rung as the last rung of LAD 2:
XIC S:5/0 BST OTE B10/0 NXB OTU S:5/0

Now what will happen is that if there is a math error, the flag will clear, but B10/0 will be energized. If the bit remains energized, then I know I have a persistent problem. If it doesn't, it means that somewhere in the code is logic that fixed the problem, but that it didn't kick in immediately. I

've seen that sort of thing most often when programs are saved and then downloaded. File instructions (FAL, FSC, etc) will sometimes have pointers that were saved out of range, and thus cause a problem on first scan. Once the instruction executes, the pointer is now in-range, and all is right with the world.

Needless to say, they can be very hard to find, as any intermittent problem is. In those cases, I set "latch traps" like Ron posted, and come back later.

But if B10/0 is persistent, then I figure out roughly the 50% point of my program. If I'm lucky and LAD 2 is little more than a series of JSRs, then I'll pick a rung about half way, and add the following:
XIC S:5/0 OTE B10/1

If B10/1 is on (and B10/0 is also on), then I know that the (first) problem is somewhere in the half ABOVE the rung. If B10/1 is not on, but B10/0 is, then I know that the problem is in the half BELOW my rung.

Now I divide that half in have, and paste the rung back in. Again, the combined states of B10/0 and B10/1 tell me which quarter to try next.

It doesn't take long to zero in on the (first) instance of the problem.

Fix the issue, and repeat. Chances are good that the programmer who forgot to check for a "divide by zero" in one place forgot to check for it in others.

After I'm done, I delete both my moving rung AND that last rung on LAD 2. "The job is not done until the tools are put away."
 

Similar Topics

I am needing help with an issue that I am having with my RSLogix 500. I have freshly installed it on a new laptop, and have already fixed a...
Replies
2
Views
1,567
Hi guys, Kindly could you guide me how to reset the CPU fault. Run indication led not getting on. Always its fault led flushing. Kind...
Replies
13
Views
3,528
Hi guys, I had a problem today with a mlx 1500 which went into fault, I went to the errors and it said about a faulty module , but not which one...
Replies
3
Views
2,944
I've searched for "default project" and end up with hundreds of hits! What I'm wondering is... Can you set up a .rss file to always didplay as...
Replies
5
Views
2,143
:D I know this may seem a little lazy but I have an huge workload right now and I'm reaching out to my fellow EE's for some TLC :p . Can anyone...
Replies
3
Views
7,871
Back
Top Bottom