sorry, no cigar - yet
Yo, gbradley,
Let’s think about this for a second. If you put this “limiting” rung at the end of your program - how do you know that on the very next scan, something “upstairs” in your program won’t over-write the value in N7:130 - and cause it to overflow? In other words, there could still be the potential for an out-of-range value in N7:130 up in the earlier rungs of your program - and so you could still get an Overflow Trap condition. But at least you’re thinking and you’re certainly on the right track.
Look at this instead - this is the way most “professional” programmers would handle an “out of range” condition for N7:0 in my post #6.
[attachment]
This is a very common technique and it (almost) guarantees that N7:0 will be forced into an acceptable range just before the MUL (multiply) works on it in the following rungs. Notice that besides checking for a “too high” condition, we’re checking for a “too low” condition also. Don’t forget that anything lower than (note negative sign) -3640 times 9 will be an overflow condition - in other words, a value less than (note negative sign) -32768. You’ll see this same technique used in many professionally written programs. After a while you’ll start to recognize the four little square boxes on two successive rungs - and the criss-cross pattern of the values in the boxes. A common place that you’ll find this arrangement is right above a PID instruction - to insure that the operator hasn’t somehow cranked the setpoint up to an unsafe value. Many programmers will just rely on the program in the operator’s interface device (Panelview, etc.) to limit the setpoint value. A more cautious programmer (one who’s been bitten before) will often put this little LIMITER arrangement in place in the PLC “just in case” someone ever changes the Panelview program.
So the short story is: Consider using this arrangement instead of the rung at the bottom of your post #11. Going a little bit further - suppose that something upstream in your program HAD generated an Overflow Trap condition (S:5/0 = 1). How would the rung in your post #11 help prevent a fault? Simply put: It won’t.
Quote from my post #6
Specifically: It’s not the “bad math” which causes the fault. And it’s not the fact that the Overflow Trap bit S:5/0 got set to 1 which causes the fault. What causes the fault is that the Overflow Trap bit S:5/0 contains a 1 at the end of the processor’s scan.
Think about it - if bit S:5/0 has been set somewhere “upstairs” in your program, then forcing the value in N7:130 back into an “acceptable” range at the end of your program isn’t going to reset that bit (S:5/0) back to a 0 state. In other words, if the processor’s still got that “note in his pocket” (to continue the analogy of my post #6) then the rung you’ve shown above is NOT going to “erase” that note. Sorry - but you’ll still get a fault.
I think that answers your question. Now let’s dig a little bit deeper. Consider the LIMITER arrangement I’ve shown above. Is that REALLY going to “fix” our problem with an Overflow Trap fault condition for our MUL rung? Well, in one sense it DOES “fix” it. Now if we go back to my post #6 and look at the condition which precipitated all of this - we see that “somehow or another” the value 3699 just happened to end up in N7:0. Suppose that same thing happens again. This time the LIMITER arrangement will “fix” the “value-too-big-for-an-integer” condition - so that we will NOT set the Overflow Trap bit. But look at the cost. What value will the math conversion give us for a final answer in N7:1? The same old incorrect value of 6585 - not the correct conversion answer of 6690 that we need. This is what the “big dogs” have been talking about when they say (in effect): “If you fix the math then the Overflow Trap bit will take care of itself.” And that’s excellent advice. So how should we proceed?
First let’s ask ourselves: “That REALLY BIG number that shows up in N7:0 from time-to-time. Where the heck is that coming from anyway?” Suppose that the answer is: “It’s just a bogus entry from the operator - he fat-fingered the keyboard and typed in too big a number.” Well, if that’s the case, then the LIMITER might just be the answer. Now with this in place, if Bubba gets carried away with his keyboard entries, the PLC will just clamp the values back into an acceptable range. (Want to play hardball? Come up with some realistic way to alert the operator that his typed-in entry was out of range. If you don’t, then he’ll probably miss the fact that he entered the wrong number - and just accept the “incorrect” conversion answer as a valid answer.)
Second scenario: Suppose that the REALLY BIG number in N7:0 is a perfectly valid entry that we DO need to calculate a conversion for. Now in that case we can’t just “clamp” the entry with a LIMITER can we? Nope - not if we want a correct answer to our math. So how about using Floating Point locations (example: F8:0, etc.) instead of Integers for our math functions? Now we’re getting somewhere. Try re-writing my program in post #6 using F8 (Floating Point) locations instead of N7 (Integers). I think you’ll like what you see - even with a REALLY BIG number as an input. And notice that it will even take care of decimals in our final answer - (example: 3699 Centigrade = 6690.2 Fahrenheit).
Other scenarios: I’m sure our readers can come up with more ...
So in a nutshell: If all that you’re attempting to do with your “fixit” rung in post #11 is to prevent faulting the processor in the event of an Overflow Trap situation - then simply putting an unconditional rung to unlatch S:5/0 at the very end of Ladder File #2 would be more in order.
Finally, whenever we mention “limiting” a value - the idea of the LIM (limit test) instruction invariably comes up. Some beginners say to themselves: “I’ll just use the LIM as a condition to clamp my values.” Well, you CAN use the LIM to test and see whether you’re inside or outside of the acceptable range - but then what are you going to DO about it? The right-hand end of your rung can get real ugly - real quick - using the LIM approach. Hint: Don’t forget we want to take care of values which are “too low” and also values which are “too high”.
Disclaimer: I’m writing this during breaks in between customer calls - if it contains any typographical errors I apologize in advance. I'm particularly afraid that some of the "-" minus signs might not post correctly because of wordwrap issues.