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

caleno

Member
Join Date
Mar 2010
Location
NJ
Posts
36
Hi I need help solving this Fault Code 20h (Math Overflow Trap S5:0). I download the code into the ML 1400 PLC. When choosing RUN it gives me a fault Math Overflow Trap S5:0. I have placed the Overflow Trap Bit Run on several sections of my code to find out where the error could be. I found the first error, but I am not sure how to fix it. It is a CPT instruction. How can I post a screenshot of the instruction? or If you provide me with your email I can send you the .RSS file. I am running out of time to complete this project and I can't run the plc code with this fault in the way. Thank you so much in advance.
 
At the end of the main program, put logic to examine the overflow trap bit, and if set, unlatch it. In parallel to the unlatch, use a latch instruction to set a B3 bit that is not in use so that you will know that the overflow has been trapped. This will keep your program from faulting, but it is still important to find the root cause(s) and assess the consequences of the root cause(s).

In some cases, it is not advisable to use the above method to keep a program running with math problems. In other cases, it is not a problem at all, merely an indication that some sensor value or other number is causing a temporary issue that doesn't affect the control system.

To post a screen shot of your logic, hit the Go Advanced button below the quick reply. On the advanced reply page, scroll down and look for the "Attach files" button and follow the instructions that result.

Do us a favor and narrow your ladder window before taking a screen shot and crop the picture in your favorite bitmap editor before posting. My favorite bitmap editor is still Paint.Net which I learned from another forum member many years ago:
www.getpaint.net
 
OkiePC, thanks a lot for your response. I have a free membership, I don't think I can attach screenshots, but files only. Please find my word file and see what I am seeing. If you provide your e-mail I could send you my .RSS file. I need help please. Thank you!
 
Hi James, please find the attached file on my just posted response. Yes you are right, something is wrong with the multiplication or division, but I am not sure why? Is it the format the formula is written? or is the math result causing this fault? Thank you!
 
I have attached a .gif of one of the rungs presenting the S5:0 Math Overflow Fault Error. Does anyone see what is wrong in this rung? Thank you.

RSLogix 500 20h Fault Error.GIF
 
N registers can only hold 15 bits of data, I.e. values up to 32767. When you multiply N7:3 (value 8000), you greatly exceed that (I.e., overflow). Even though you subsequently divide by 20,000 to bring it under that limit, the "warning" has been raised.

Oddly, because of the way that AB handles data type conversions, if you were to signal to the PLC that you were doing floating point math, and your CPT instruction was (31206.0 * N7:3) / 20000.0 -- that is, include decimal points -- then I believe your math would NOT fault.
 
The integers are signed 16 bit. The allowed values are +-2^15-1 (32767)
When you multiply 31206 by anything other than 0 or 1 it overflows n7:2

Try using floating point or scale the values lower before doing arithmetic
 
post your RSS file and we'll be able to help with more detail ... there's GOT to be more to this story than we can see ...

based on what you've posted so far, you should be able to just simply MOV (Move) the final value 12,482 into N7:2 ... specifically, no CPT computations are needed for this particular rung of your logic - since you're always loading the constant value 8,000 into N7:3 before you execute the CPT instruction ...

note that the integer N7:2 can't handle the 0.4 decimal part of 12,482.4 - so hopefully a "round-off" will be close enough ... specifically, the values of N7:2 MUST be WHOLE numbers with NO fractions - and can only range from +32,767 to -32,768 ...

I'm GUESSING that somewhere in your code you've got other similar rungs with DIFFERENT values to deal with - but you don't even have to make the processor do this particular piece of math for you - because you're shoving the constant value 8000 into the formula each and every time this CPT executes ...
 
Last edited:
Another method, using the data you have shown, is to use a MUL and a DIV instruction instead with the result of the multiply instruction being a long word (L) rather than an integer (N).

Paul
 
The "Overflow Trap Bit", S:5/0, is without doubt the most useless thing ever put into a PLC system.

It tells you, in a very unfriendly way, (i.e. by Faulting the processor), that you had an instruction somewhere in your program, that generated an Overflow, or Underflow, arithmetic status.

It doesn't tell you where, nor does it tell you what, overflow or underflow, so it is not much use to you at all.

I concur with OkiePC's suggestions of just unlatching it, and latching your own bit to flag up an over/under...flow.

And yes, you do need to assess how over/under...flows will affect the following code whenever you use maths, or other instructions that manipulate the arithmetic status bits. You need to inspect these bits in your code immediately following each arithmetic instruction, and perform whatever "error handling" you desire.

No other A-B PLC platform has this Overflow Trap Bit, only the SLC/Micrologix range, and therefore I don't consider it serves much purpose. Every Logix500 program I have ever seen has an unconditional OTU S:5/0 as the last rung of file 2.
 
Change the order of math like this:
(31206/20000)*N7:3

That would give a "lumpy" output.

Easiest fix... change N7:3 to an F data-table address

The CPT expression would be evaluated using floating point maths, and the result rounded into N7:2
 
I concur (also)

The "Overflow Trap Bit", S:5/0, is without doubt the most useless thing ever put into a PLC system.

It tells you, in a very unfriendly way, (i.e. by Faulting the processor), that you had an instruction somewhere in your program, that generated an Overflow, or Underflow, arithmetic status.

It doesn't tell you where, nor does it tell you what, overflow or underflow, so it is not much use to you at all.

I concur with OkiePC's suggestions of just unlatching it, and latching your own bit to flag up an over/under...flow.

And yes, you do need to assess how over/under...flows will affect the following code whenever you use maths, or other instructions that manipulate the arithmetic status bits. You need to inspect these bits in your code immediately following each arithmetic instruction, and perform whatever "error handling" you desire.

No other A-B PLC platform has this Overflow Trap Bit, only the SLC/Micrologix range, and therefore I don't consider it serves much purpose. Every Logix500 program I have ever seen has an unconditional OTU S:5/0 as the last rung of file 2.

Simply program the last rung of program 2 OTU S:5/0.
 

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