S:5/0 (SLC-500) vs. S:10/14 (PLC-5) ...

[Guest]

Greetings to all, now here’s an interesting thought ... well, interesting to me at least ... it was brought to mind by a discussion going on right now in another thread ... first consider a processor (example: SLC-5/04) in the Allen-Bradley SLC-500 family ... there are many experienced programmers among us who immediately cry “foul - poor form - out of bounds” or something else along those lines every time someone suggests simply doing an unconditional “reset” of the math “Overflow Trap” bit S:5/0 ... as most of us know, this “reset” is a very common programming procedure which is often done with an unconditional OTU (Output Unlatch) rung for S:5/0 at the very end of Ladder File #2 ... the idea is that without some type of “reset”, a very simple “Math Overflow” might create a processor fault condition and shut down the entire system ... (for one example: trying to store a value larger than 32,767 in an integer location) ... and so, many SLC programmers have developed the habit of simply unconditionally “resetting” bit S:5/0 to prevent the fault from happening ... now for the purposes of this discussion, let’s NOT debate whether the practice of simply “resetting” S:5/0 is a good one - or a bad one ... for now, let’s just say that the practice DOES happen ... now suppose (just for the sake of discussion) that I personally belong to the “do-NOT-just-reset-the-bit” school of thought ... specifically, I think that if that particular bit got set, then obviously some “bad math” voodoo happened somehow/somewhere in my SLC program ... I’d better find out what that “bad math” involved ... maybe it’s truly something that SHOULD fault the processor and shut down the system - for safety reasons, etc. ... now that I’ve made that particular argument for my SLC-500 system, let’s turn our attention to the larger Allen-Bradley PLC-5 processor family ... this point is not often discussed, but the PLC-5 processor also has a bit which works much like the S:5/0 bit in the SLC-500 ... the PLC-5’s corresponding bit is S:10/14 and it’s documented by RSLogix5 as “Arithmetic Overflow Occurred” ... as I said, this PLC-5 bit works much like the “Overflow Trap” bit in the smaller SLC-500 processor ... but one BIG difference is that S:10/14 will NOT automatically fault the PLC-5 processor ... on the other hand, S:5/0 WILL cause a fault to the SLC-500 processor - if the bit is still on at the end of the program scan ... well now ... suppose (again for the sake of discussion) that I’ve just climbed up on my soapbox and declared in an authoritative voice: “do-NOT-just-reset-the-S:5/0-bit” for an SLC-500 system ... suppose that I insist that a “shut-down-the-entire-system” fault would be preferable to simply masking a potentially hazardous math error ... haven’t I just painted myself into a very sticky corner? ... what about the PLC-5 processor? ... so maybe while I’m still up there on that soapbox, I need to also declare: “when using a PLC-5 system, you should ALWAYS program a ‘generate-a-fault’ rung to shut down the system in case of an ‘arithmetic overflow’ condition” ... I mean “what’s good for the goose should be good for the gander” as the old saying goes ... and so I’m just wondering, why do some people firmly insist that the S:5/0 bit should NEVER be simply masked? - but by the same token, those same people don’t ever mention the need to program the corresponding S:10/14 bit in the PLC-5? ... now my memory is not what it used to be ... but personally, I don’t recall EVER seeing the S:10/14 bit being used in ANY PLC-5 program ... maybe it should be? ... at least that’s my “point-to-ponder” for today ... and so my final question for all of the “do-NOT-just-reset-the-S:5/0-bit” people is this: do you ever program a “generate-a-fault” rung for the S:10/14 bit? ... and if not - why not? ... PS Edit ... I'm not trying to "pick a fight" with anyone here ... actually I go along with the general idea that conditions which set S:5/0 should be investigated and not simply masked with an unconditional reset ... but still I wonder, why don't we (myself included) ever seem to worry about the "other side of the coin" where bit S:10/14 is involved? ... I'm just looking for some thoughts here - not a fight ... Edited 2 Jun 2005 by Ron Beaufort

[mgvol 0]

You bring up an interesting point about the differences between to SLC and PLC platforms...I can say that "back-in-the-day" when I programmed PLC-5's, I never considered generating a fault off the overflow bit. As for the SLC, Ive written many, many programs for the fixed I/O, 5/03, 5/04 and 5/05 CPU's, and I always do over and under range-limiting on my analogs to prevent this problem. And as someone who has had to go to customer sites and find out why "my SLC just faulted", I have found that 99% of the time it is caused by an analog value being off-scale hi or low. The other 1% seem to be spurious, perhaps noise related.

[Firetubes 1]

...and we've come full circle with the ControlLogix5000. The math overflow doesn't stop the processor.

[TConnolly 13]

There are seven machines here where a processor fault is hazardous to the machinery. The machines are well shielded but should the processor fault, about five seconds later there would be a very very loud boom. The operators don't like it because it is painfully loud and leaves their ears ringing and their pants wet. Management doesnt like it because it means that the days operating expense went up by more than double the cost of their high end luxury car in the parking lot. Maintenance doesn't like it because it means an extra 6-8 hours work for them to repair the machine. I dont like it because its not fun to have to explain that the PLC faulted because I didn't write a fault handler in my code. Two are controlled by PLC5/20Es, Two by SLC5/05s, and the rest by CLXs. So you can bet that there is an un-conditional reset of the the overflow bit in the SLC machines. Critical mathematical parameters are range checked before math operations and there are fault handlers. But just in case I missed something there is an unconditional reset at the end of every routine that has any math in it. Many simple machines can safely just halt, but there are so many more processes that have to be shut down in an orderly fashion for a varitey of reasons.