Ron Beaufort
Lifetime Supporting Member
Greetings to all,
this is one of those “yeah, it makes sense now that I think about it” type situations that most people never think about ... until it creates a problem ... the first time that I ran into it was a few days ago ... and I’ve never seen it mentioned anywhere before ... luckily it came up in the comfort and privacy of the lab ... not out there in a “let’s make money” production environment ... anyway, here it is for what it’s worth ...
most of us who work with Allen-Bradley SLC systems know that an “out-of-limits” math operation can generate a processor fault condition ... for a quick refresher, if the “overflow trap” bit (S:5/0) is set to a 1 at the end of the program scan, then the processor will fault ... if you need more detail than that, read this old post ...
old post about the Overflow Trap bit
once a programmer finds out about that S:5/0 “overflow trap” problem, then he often writes all of his future SLC programs to include something like this at the very end of Ladder File 2 ...
[attachment]
this rung has the effect of making sure that the “overflow trap” bit is ALWAYS turned off just before the very end of the processor’s scan ... thus, there is NO possibility for any “out-of-limits” math operation anywhere in the program to cause an “overflow fault” condition ... problem solved, right? ... well, not so fast ...
suppose that the “out-of-limits” math operation happens to take place within an STI (Selectable Timed Interrupt) file ... now the nice thing about an STI is that we (the programmers) get to decide just how often the STI file gets executed ... we do this by specifying a “setpoint time” when we set up the STI ... the trick is that we don’t usually know (or care) exactly WHERE in the program that the STI gets scanned ... and therein lies the problem ...
now suppose that the STI contains an “out-of-limits” math operation ... and that the STI just happens to execute that “out-of-limits” math operation right in BETWEEN the “let’s unlatch the overflow trap” rung and the “end” rung of Ladder File 2 ... bummer ... the processor IS going to fault after all ...
and consider how tricky this could be to troubleshoot ... the STI could execute that “out-of-limits” math operation many, many, many times and never give us a fault ... just as long as the STI’s execution happens to take place somewhere - anywhere - in the program scan ABOVE that “unlatch the overflow trap” rung ... so this thing gives us the potential of a program which runs without faulting for a very long time ... and then all of a sudden the processor faults out due to an “overflow trap” situation which we just KNEW that we had absolutely positively prevented with our handy little “unlatch” rung ... and incidentally, the longer the program, the less chance that you’ll see this type of problem shut your system down ... and that just makes the darned thing even harder to troubleshoot ... it only faults if the STI just happens to hit that very tiny slice of scan-time ... right in between those two consecutive rungs ... and statistically speaking, this is going to happen at 3:00 o’clock in the morning ... on a weekend ...
now for a quick simple solution ... how about putting a second “unlatch the overflow trap” rung right at the end of the STI file ... especially if there is ANY possibility of an “out-of-limits” math operation taking place anywhere inside that STI file ...
and finally, thanks to Phil for this chance to share ...
this is one of those “yeah, it makes sense now that I think about it” type situations that most people never think about ... until it creates a problem ... the first time that I ran into it was a few days ago ... and I’ve never seen it mentioned anywhere before ... luckily it came up in the comfort and privacy of the lab ... not out there in a “let’s make money” production environment ... anyway, here it is for what it’s worth ...
most of us who work with Allen-Bradley SLC systems know that an “out-of-limits” math operation can generate a processor fault condition ... for a quick refresher, if the “overflow trap” bit (S:5/0) is set to a 1 at the end of the program scan, then the processor will fault ... if you need more detail than that, read this old post ...
old post about the Overflow Trap bit
once a programmer finds out about that S:5/0 “overflow trap” problem, then he often writes all of his future SLC programs to include something like this at the very end of Ladder File 2 ...
[attachment]
this rung has the effect of making sure that the “overflow trap” bit is ALWAYS turned off just before the very end of the processor’s scan ... thus, there is NO possibility for any “out-of-limits” math operation anywhere in the program to cause an “overflow fault” condition ... problem solved, right? ... well, not so fast ...
suppose that the “out-of-limits” math operation happens to take place within an STI (Selectable Timed Interrupt) file ... now the nice thing about an STI is that we (the programmers) get to decide just how often the STI file gets executed ... we do this by specifying a “setpoint time” when we set up the STI ... the trick is that we don’t usually know (or care) exactly WHERE in the program that the STI gets scanned ... and therein lies the problem ...
now suppose that the STI contains an “out-of-limits” math operation ... and that the STI just happens to execute that “out-of-limits” math operation right in BETWEEN the “let’s unlatch the overflow trap” rung and the “end” rung of Ladder File 2 ... bummer ... the processor IS going to fault after all ...
and consider how tricky this could be to troubleshoot ... the STI could execute that “out-of-limits” math operation many, many, many times and never give us a fault ... just as long as the STI’s execution happens to take place somewhere - anywhere - in the program scan ABOVE that “unlatch the overflow trap” rung ... so this thing gives us the potential of a program which runs without faulting for a very long time ... and then all of a sudden the processor faults out due to an “overflow trap” situation which we just KNEW that we had absolutely positively prevented with our handy little “unlatch” rung ... and incidentally, the longer the program, the less chance that you’ll see this type of problem shut your system down ... and that just makes the darned thing even harder to troubleshoot ... it only faults if the STI just happens to hit that very tiny slice of scan-time ... right in between those two consecutive rungs ... and statistically speaking, this is going to happen at 3:00 o’clock in the morning ... on a weekend ...
now for a quick simple solution ... how about putting a second “unlatch the overflow trap” rung right at the end of the STI file ... especially if there is ANY possibility of an “out-of-limits” math operation taking place anywhere inside that STI file ...
and finally, thanks to Phil for this chance to share ...