Math Overflow Fault

[Big John T]

I have a SLC5/03 with 6 I/O cards and a communication card. I get a math overflow fault every time I:1.3 or I:3.12 is turned on then off. This has not happended in the past. I can force the inputs on or jump them out and get the error. I changed both input cards with known good cards. Any ideas on where to look for that problem. The program is about 400 rungs long with no comments and uses alot of MVM and Copy to write the inputs and outputs. No direct reference is made to the inputs or outputs. My thought is it is in the processor or backplane... That's the only parts we didn't switch out.

John

 

[Ken Roach]

Math Overflow faults are not related to damaged or defective hardware. They are only caused by application code that executes a math instruction that causes an overflow.

You can keep such an overflow from faulting the SLC by simply setting the Math Overflow Trap bit S:5/0 = 0 at the end of Program File 2. The overflow still exists but it doesn't fault the CPU and you have more opportunities to track it down.

If there are subroutines, put a trap rung at the end of each one to trap the overflow bit occurring in that routine. You can also add trap bits after suspicious bits of code in your program.

Overflow errors can be difficult to find in your program, but it's worth the effort if they haven't occurred before, as it indicates something else has been altered in the system.

 

[Ken Roach]

What kind of communication card is it ? Maybe the incoming data has changed and caused an out of range condition.

 

[Sergei Troizky]

You can also add trap bits after suspicious bits of code in your program.

There are also the error file and error rung registers in the status file.

 

[OZEE]

I ran into a processor awhile back that was faulting when a calculated value was being moved into an output module. The value went larger than 65536 which the output module couldn't handle. It took a long time to find it.

The only way to find it was to do what Ken suggested -- OTU S:5/0 and watching the values during the process.

Perhaps if you want to post your program, one of us could look it over and find your problem...

 

[BigJohnT]

What kind of communication card is it ? Maybe the incoming data has changed and caused an out of range condition.

Ken it is a 1747-KE Interface Module, Series A

John

 

[BigJohnT]

There are also the error file and error rung registers in the status file.

Sergei, where are the error rung registers located? I have not see them before.

John

 

[BigJohnT]

I ran into a processor awhile back that was faulting when a calculated value was being moved into an output module. The value went larger than 65536 which the output module couldn't handle. It took a long time to find it.

The only way to find it was to do what Ken suggested -- OTU S:5/0 and watching the values during the process.

Perhaps if you want to post your program, one of us could look it over and find your problem...

I'd be happy to post it but it has no comments...

John

 

[kamenges]

Without comments it's a little hard to tell what the intent of the program is. In addition the program uses alot of indexed addressing so the data values used for calculations are different depending on the situation. I'm assuming the program you posted is a snapshot from around the time of the fault.
That said and assuming the index offset doesn't change, as the program sits right now, the next time any of rungs 218, 225, 312 or 319 go true you will end up with an overflow. N9:112 is currently at a value of 32767. All of these rungs add 1 to N9:112, which will drive that integer into overflow.

Like I said, I'm not sure what the intent of the program is. It does look like it could use some bounds checking, though.

Keith

 

[BigJohnT]

Keith

Yep, sorry for no comments but that's all I had. The upshot of the program is very simple. When an input goes on it fires two outputs O:2.0 and .1 this is the vacuum pump. It also fires the output that is the same as the input. So if input I:3.5 is on the pump starts then output O:4.5 fires for 30 seconds or so. Valid inputs start at I:1.10 and outputs at O:2.10. If multiple inputs are on it sequences through the 36 inputs and does each output for 30 seconds or so.

John

 

[allscott]

If you have drawings for the I/O it would be helpful to label them in the program. Then you can look at the logic and give names to the internal coils and N registers based on what the logic is doing.

Pretty soon you should have a project that starts to make sense.

I agree with ken to put in the overflow traps, then just watch the program and see what is going on when the overflow occurs

 

[Ron Beaufort]

to Sergei:

There are also the error file and error rung registers in the status file.

... sorry, those won’t work to find a Math Overflow problem ... basically the information that you’re thinking about will always indicate the last rung number of Ladder File #2 - because that’s where the “fault” actually occurs ... and yes, I know that sounds wrong ...

to BigJohnT:

here’s what Sergei is talking about ... this is VERY handy information and you need to know about it ... unfortunately the indications here won’t help you find your current problem ... that’s what the “flag/trap” bits that everyone has been mentioning are for ...

finally ... posts #4, #6, and #12 in this thread should answer all of your “how to” questions about this subject ... if not, please just ask ... I’ll be glad to answer any specific questions - as time permits ...

PS EDIT ... sorry I don't have time to look at your file right now ... the bo$$ has work for me to do ...

 

[BigJohnT]

I did figure out what the I/O is doing but no drawings. Heck they don't even know what is hooked up to each output. Documenting will be my next step. That will not be easy as they didn't use the I/O directly but did a copy or MVM from to the I/O. After some disscussion with my partner he recalled the last maintenance manager complaining about having to reset some counters out in the plant. My guess it I have found it!

John

 

[BigJohnT]

Ron, Thanks again for your help. Can anyone elaborate a bit on the flag/trap bits. If the S:5/0 error is set at the end of the file it would be difficult to trap the code. However I just popped up the N files and out loud and clear are any that are at 32767...

John

 

[Ron Beaufort]

my favorite technique for the "flag bits" is already shown (with pictures) in the first one of the posts that I linked ...

this is one place where Copying-and-Pasting rungs can be a real time-saver ... but ... this method is the best that I know of to tell you where the problem is occurring ...