Also be careful as AB PLC's treat dividing by zero as a major fault and shutdown.
That is
not true in
ANY AB PLC.
In PLC2, PLC3, PLC5, PLC5/250, Logix500 and Logix5000 systems it is simply a "minor fault", which does not shutdown the processor.
Dividing by zero
does not cause a major fault itself, but it will set the "Overflow" status bit.
That is not the problem either, because the overflow status bit is a "minor fault", and logic scan will continue. The overflow bit will most likely be reset on the next "successful" instruction that affects the arithmetic status bits.
So looking at Logix500, SLC and Micrologix systems, the "problem", if you'd like to call it that, is that
any setting of the "overflow" bit during the program scan, will also set the "Overflow Trap" bit S:1/5
It is that "Overflow Trap" bit S:1/5 that causes the Major Fault, if it is still set at the end of the scan of file 2.
IMHO it is a stupid thing that they did when designing that functionality, for the following reasons.....
1. "
We've reached the end of the logic scan, and somewhere along the way an instruction set the "overflow" bit. This was flagged by the "overflow trap" bit, and it's now on, so we will major fault the processor." - Why? The programmer may have inspected the "overflow" bit where it was important to know it, and dealt with it accordingly......
2. "
We've reached the end of the logic scan, and somewhere along the way an instruction set the "overflow" bit. This was flagged by the "overflow trap" bit, and it's now on, so we will major fault the processor." - Why? Do they think it "unsafe" to proceed with executing any more code because the program is "flawed" in some way. Don't you think you should have stopped processing any more code in that scenario, why wait until the end of the scan? Agreed, faulting the processor will stop outputs coming on, but the output data will already have been written to the Output Image Table, and internal flags and registers will have been processed with the "minor fault" on one or more instructions occurring.
3. "
We've reached the end of the logic scan, and somewhere along the way an instruction set the "overflow" bit. This was flagged by the "overflow trap" bit, and it's now on, so we will major fault the processor." - And? : Please tell me where this occurred if you think it's that important... Oh, you can't, which is both sad and useless at the same time.
For those reasons, and possibly many others, without exception every single Logix500 application I have laid my eyes on, have, as the last rung of file 2, an unconditional unlatch (OTU) of the "overflow trap" bit, S:1/5 !!
Programmers : If you consider it important to test the overflow
status of an instruction, do so
immediately following that instruction, and if it is set, deal with it there and then, and OTU the overflow trap bit.
Everyone : If programmers follow the above advice, that is the only case where the overflow trap bit is (somewhat) useful, in the sense that "something unforseen" occurred.. You'll get no indication which instruction it waq though....
