PLC 5 Fault Prevention Logic

[BobLfoot 302]

I seem to recall a few years ago of writing PLC 5 program with an OTU S:5/0 or some S address at the end of each ladder to keep the PLC from faulting for a math error in that ladder file. Can anyone recall what the correct S register was I used to use. Unfortunately I haven't found it yet in the newer documaentation and I don't have any of my older programs still floating around.

[Guest]

Greetings Bob ... I'm sure that would have been an SLC-500 or a MicroLogix system ... the PLC-5 doesn't automatically fault for "math overflows" ... the SLC and the Micro platforms do ... so - you WERE correct - the bit you're looking for is indeed S:5/0 ... but you happened to be looking in the wrong processor ... Edited 7 May 2010 by Ron Beaufort

[BobLfoot 302]

Dang Rusty Memories - Thanks Ron.

[TConnolly 13]

Even though a math overflow does not fault the processor on a PLC/5, there is a math overflow bit. The bit is S:0/1. If you are performing computations that might result in an overflow you should monitor this bit and respond to the result as necessary for your process.

[BobLfoot 302]

Thanks for the hint alaric. I am having to play cleanup following the faulting of a PLC5 in which the battery was removed and power cycled before the fault codes and status was recovered. Of course out Monday Morning Quarterbacks want answers I can't give them.

[Guest]

now that the stone has been turned, let's dig a little deeper ... bit S:0/1 in the SLC is commonly called the "arithmetic underflow/overflow flag" ... also ... bit S:0/1 in the PLC-5 is commonly called the "arithmetic underflow/overflow flag" ... (same address - same description) ... as far as I've been able to tell, the function of these bits in BOTH platforms is identical ... basically they do what their names say they will do ... the part that many programmers miss is that once this bit has been written to a ONE status by "bad math" it will automatically be written back to a ZERO status the next time "good math" occurs ... the point to remember is that NEITHER of these bits will normally generate a major fault condition ... going further ... bit S:5/0 in the SLC is commonly called the "overflow trap" bit ... (it will also trigger upon an underflow condition) ... for better or for worse, this is the bit that usually causes the fault conditions in the SLC and MicroLogix platforms that everybody talks about ... specifically, if you have a ONE status in this bit at the end of the SLC/Micro processor's scan sequence, you can expect a major fault ... bit S:10/14 in the PLC-5 is commonly called the "arithmetic overflow occurred trap" ... (it will also trigger upon an underflow condition) ... this is the bit in the PLC-5 which MOST CLOSELY (but NOT PRECISELY) mirrors the operation of bit S:5/0 in the SLC and MicroLogix platforms ... specifically, a math overflow or underflow condition anywhere in the PLC-5's program scan will write a ONE status to this bit ... and once the ONE status has been written, the ONE status will stay there until you (or your program) writes a ZERO status to the bit ... the biggest DIFFERENCE between this bit (S:10/14 in the PLC-5) and bit S:5/0 (in the SLC) is that the PLC-5's bit will not normally cause a major fault ... if you WANT that type of protection/operation then you need to write the program accordingly ... personally I find it "interesting" (if not to say "amusing") that some people will quickly climb on a soapbox and rail against "unsafe" programmers who will "simply unlatch" bit S:5/0 in the SLC/Micro platform to prevent a math overflow from causing a fault – and yet most of these same pundits never even consider that they are tolerating EXACTLY the same operation from the PLC-5 and the ControlLogix programs that they themselves write ... specifically, it's as though they're criticizing their next door neighbor for bypassing the fuses in his house – and yet they fail to realize that the fuses in their own houses have ALWAYS been bypassed even before they moved in ... note that I am NOT (repeat: NOT) saying that simply bypassing the operation of bit S:5/0 in the SLC/Micro platforms is a "good" thing or that it should be undertaken lightly ... but by the same token, simply tolerating the "non-faulting" operation of the PLC-5 and the ControlLogix platforms under the same conditions should be subjected to precisely the same safety considerations ... it seldom is ... summing up: the "big picture" is that the SLC/Micro platform forces you to "think" about the math overflow conditions – the PLC-5 and ControlLogix platforms allow you to blithely ignore the potential problems ... the question of which approach is the better is still open for debate ... Edited 8 May 2010 by Ron Beaufort

[JesperMP 2]

Well said Ron. I have always monitored, and unlatched the "math overflow bit". Specifically, in every program file there would be a rung at the end of the file that did the following: If overflow bit is set, then set an alarm bit for the HMI, and write the program file number in an address for the HMI, and unlatch the overflow bit. So I would have a message on my HMI saying "Math overflow occurred in program file 34" for example. I can imagine that in some applications it would be an indication of a programming error with possible catastrophic consequences if there is a math overflow. But I'll wager that in MOST applications, it is more preferable to let the proces or machine continue, rather than shutting down the PLC completely. If there is a math overflow, and it has catastrophic consequenses, then it would be preferrable in MOST applications to catch the error and handle it by a shut-down routine. To simple let the PLC shut down instantly is a strange and primitive error handling to my opinion. Edited 10 May 2010 by JesperMP

[wildswing 0]

Sorry for blowing the dust off an old thread, but I have a question. Is there any other way to locate the source of the overflow in a 5 other than the example provided by Jesper where flags are set at the end of each program file? I happen to have an overflow in one of my PLC-5s and would like to find the cause.

[JesperMP 2]

Hi wildswing. You can trawl through all integer files and look for "-32768" or "32767" values, and all floating point files for "NaN" values. If you find any of these, you can use the x-ref to search for all occurences of the affected addreses. It is not a guaranteed method because the addresses can be overwritten after the overflow. But worth a try.

[wildswing 0]

Ahhh, so finding it is a "roll your own" kinda thing. There's no register, or such, that stores the file:rung location. I figured as much. Thanks.

[paulengr 44]

Integer math does not go to "max/min". It rolls over. So unless you are normally adding or subtracting by 1 digit at a time, looking for -32768/+32767 is not going to work. In addition, better check on the manual for PLC-5. This PLC was out WAY before IEEE math standards were out. I don't know for sure but I doubt they implemented "NaN", which didn't become common in math routines until roughly about the time math coprocessors came around (roughly 80286/80386 days, late 80's).

[JesperMP 2]

I am fairly certain that the -32768..+32767 bracketing and NaN will be the result of bad math on an SLC500. I assumed that it would be the same on a PLC5.If it does not behave like that on a PLC5, then pinpointing a programming error on a PLC5 will be a bitch. The best I can think of is to stick several tests for math overflow in each program file that contains some math or counting.

[wildswing 0]

Good discussion fellas. Thanks. That'll be just another thing to add to the "to do" list... sigh

[OkiePC 14]

Jesper's method is the same one I use. I never took it as far as adding HMI alarms though. In a long complex program, if you have one unique internal bit for each file, you basically set a trap and come back later too see if you caught anything. Start with the trap logic at the end of each file. When one gets set, just move that rung up through the file until you find the culprit, or duplicate it in several places throughout the file. MUL and CPT are going to be prime suspects... EDIT: SLC Example shown! Edited 29 Aug 2010 by OkiePC

[wildswing 0]

Thanks OkiePC. Great idea.

[Bob A. 1]

Just a quickie.....The best way to eliminate a problem is NOT TO GET IT IN THE FIRST PLACE !!! If you have unruly math problems, then constrain the values going in so that a successful completion to the math is assured. I have done many PLC apps that were mostly math and it is worth the time to filter or limit the values going into a calculation. For one example, look at the "LIM" command, with a min and max. For another, look at the FIFO Load / Unload. You can put a few values into a Shift Register Array and then take the average of the Array. If you get a wild number, at least it is avareged with some other recent ones. Best Regards, Bob A.