Overflow trap in SLC500 / PLC5?

[kdcui]

I'm looking through some ancient code that we are upgrading. In one of the ladders, on a rung there is just:

OTU S:5/0

This is he Math Overflow Trap, and is set when there is a math overflow (go figure).

Now, will a math overflow always result in a fault? If so, by constantly unlatching that bit, will that ensure the PLC will never fault in the case of a math overflow? In that case, what happens to the data that caused the overflow?

To me a better solution would be not to program in such a way that would allow overflow, but whatever...

 

[kamenges]

The SLC will fault if the Math Overflow bit is set when the plc performs it's housekeeping at the end of the scan. As long as this bit is reset prior to housekeeping the processor won't fault. Generally this instruction is stuck at the very end of ladder file 2 t make sure any overflow is reset prior to housekeeping. I think integers will sit at either 32767 or -32768 depending on the direction of the overflow. Floating point numbers will display either +INF, -INF or NaN.

One thing programmers tend to forget is that an STI can trigger anywhere, including after execution of the OTU at the end of LAD 2 but before housekeeping. These tend to confuse programmers since they get a math overflow error even with the OTU in place. So if you use an STI make sure you have an OTU of S:5/0 at the bottom of the STI also.

By the way, a PLC5 won't fault on this error. That was a hard lesson for me when I worked on my first SLC.

While I agree that proper programming can prevent this I can also see where someone might stick this in if the processor is faulting and they are under pressure to get a machine going again.

Keith

 

[Ken Moore]

I typically put this end at the end of each sub, and set a unique bit. Then when the bit goes true , I know which sub has an issue and can fix the problem.

 

[kdcui]

Thanks for the feedback.

Ken, I may end up doing something like that with the math intensive subs.

-Kris

 

[OZEE]

However, the best thing to do is to make sure that you don't leave logic that will cause this fault... like you suggested in your OP.

 

[daba]

This is not always "math overflow", can be caused by something that an instruction just can't handle.

One example, BCD thumbwheel switches can cause this overflow fault when the input data is converted to Integer with the FRD instruction.

As the switch wipers travel across the PCB tracks between digits, it produces non-BCD (i.e.Hex) four-bit binary codes, which the FRD cannot convert.

 

[Bitmore]

I have noticed in some structures that math or logic compares could result in an overflow such as 255 instead of -1 for a single integer compare.

 

[RPax]

I typically put this end at the end of each sub, and set a unique bit. Then when the bit goes true , I know which sub has an issue and can fix the problem.

Hi, I just have a problem with a maths overflow bit shutting down a PLC. I have a lot of maths code in the program and am now trying to pin point where exactly the problem is.

On a test PLC I tried the above at the end of each sub (as suggested by ken) i.e

S:5/0 B3:0/0
!---! !---------( )-!
etc

but when I cause an error all the bits are turned on in each sub. I'am obviously doing something wrong, would appreciate somebodies help on this. Many thanks - Rpax

 

[daba]

RPax wrote

but when I cause an error all the bits are turned on in each sub. I'am obviously doing something wrong,

The overflow trap bit does not get reset just because you have looked at it to set another bit, you have to turn it off with a OTU. Then there will only be a B3/nnn bit set for each occrrance of overflow.

 

[Ron Beaufort]

see if this post helps:

http://www.plctalk.net/qanda/showthread.php?postid=14307#post14307

there's more information in the rest of that thread that might be useful - but I think you'll find the answer to your question in the post I've linked ...

 

[RPax]

Great stuff lads, exactly what I was looking for, much appreciated

 

[RPax]

Just a quick one on the above, If I put a Overflow S:5/0 Maths overbit after a PID Loop does the same apply as for MUL/SUB/ADD etc? Thanks

 

[kamenges]

The operating system only evaluates the S:5/0 status as part of the post-scan. That menas that if you have an instruction that sets S:5/0 early in the program the processor still won't fault until it has completed scanning the whole program. So you don't need to put an OTU occurance after each instruction. You only need one at the very end of the program. Just keep in mind that if you are using an STR that the very end of the program may not be what you think all the time.

Keith

 

[bernie_carlton]

But remember that turning off the overflow bit at the end of all the scans is not a cure. The overflow means that something has gone wrong. Somewhere in your code something is changing incorrectly. If you truly have code which expects an overflow then it should handle it properly and reset at that point.

 

[Paul T]

But remember that turning off the overflow bit at the end of all the scans is not a cure. The overflow means that something has gone wrong. Somewhere in your code something is changing incorrectly. If you truly have code which expects an overflow then it should handle it properly and reset at that point.

True enough. The only exception I make is for integer count values to HMIs where I didn't program the PLC using floats. I almost always check for divide by zero or out of bounds on analog IO before doing any arithmetic.

I have a few assembly and test machines that count parts, count faults, count feed failures, count everything Operations could think of. Naturally, even though the totals are good for at least a few weeks, minimum, the operators never bother to clear them at the end of each week. So, after a while if I go out on the floor I have totals at 32,767.

I sometimes get ambitious and trap for this before implementing the ADD, but other times I just clear the minor fault bit at the bottom of the subroutine.