SLC 50/4 minor error bit

Deer

Member
Join Date
Jun 2002
Posts
124
Hi all,

Does anybody know, how to determine location of rung that has error:
"A minor error bit is set at the end of the scan. refer to S:5 minor error bits."
Let say there is an error on SLC 50/4 (overflow, etc), where processor have program file that comes from lad2, 3, 4,...10.
Is there a trick to find the location of rung that given a overflow?

Thank in advance

Deer
 
The only way that I know of to find it "easily" is if the PLC faults out every time you go into run mode.

If so, about halfway down in LAD 2, add a new rung and put an unconditional TND instruction on it. This ends execution of all ladder beyond this point. If you still get the fault, then the S:5 bit is being set in the code above. If the SLC doesn't fault, it's in the code below.

Divide the remaining code in half (i.e., at either 1/4 or 3/4 of LAD 2), and move the TND rung there. Repeat until you can zero in on the rung.

If you narrow it down to a subroutine, use an unconditional RET instruction intead of TND. Again, any code below the RET will simply not be scanned.

The usual cautions apply - be careful when disabling code that outputs will stay in their last position, timers won't update, that kind of thing. When I'm really nervous, I disconnect the wiring arns, so that I can't loose control of an output and cause harm to people, equipment or - more importantly - my reputation.
 
Allen

When I'm really nervous, I disconnect the wiring arns, so that I can't loose control of an output and cause harm to people, equipment or - more importantly - my reputation .

I'm glad to see that you put your reputation before the loss of life or equipment.

To the self employed reputation is everything!

Paul
 
flag bits should help

cut and paste one of these temporary "flag rungs" under each suspected culprit - be sure to use a different address for each flag bit - this same technique can be used to find other intermittent "what the heck happened last night?" problems - you don't HAVE to unlatch the "Overflow Trap" bit if you're worried about safety issues, etc. - but if you don't, then all of the flag bits from the "real-one" on down will be set - check out the top-most "on" flag bit as the likely culprit - still that won't guarantee that you don't have multiple "bad math" rungs - if you program it the way I've shown, you should be able to catch them all -

flag bits.jpg
 
Last edited:
If you get a math overflow bit, there's a very good chance that you're putting a number outside of integer range into an integer, as the result of a move, cpt, etc.

While the processor is still faulted, look at the values of ALL integers usng the data monitor. Go to the rungs of the integers that are maxed out, or +/- 32767. You'll probably find the culprit that way. Look at the analog I/O values too.
 
This rather lengthy post is intended for beginners only - you “big dogs” probably have better things to do. For those of you beginners who just can’t understand why finding this type of fault can sometimes be quite a gnarly little challenge ...

Quote from John Paley:
While the processor is still faulted, look at the values of ALL integers usng the data monitor. Go to the rungs of the integers that are maxed out, or +/- 32767. You'll probably find the culprit that way.

This is all correct - but notice that he did say “probably” - John is undoubtedly aware that this method won’t always work. As a simple example consider:

[attachment]

Here we have a program which has been operating for a very long time with absolutely no problems. But then “somehow or another” the value 3699 just happens to end up in N7:0. The math in Rung 0000 multiplies 3699 times 9 and comes up with a result of 33291. Now that’s fine mathematically - but it still presents a problem to the SLC processor. The problem arises when it comes time for the processor to store the number in the destination N7:1. Specifically, N7:1 is an integer location and the largest positive number which can be stored there is 32767. So the processor (bless its little heart) does the best it can. It stores the (incorrect) value 32767 in N7:1 - and gets ready to move on through the scan. But - and this is the tricky part for most beginners - the processor also sets the Overflow Trap (bit S:5/0) - as a means to let you (the programmer) know that something “went wrong” somewhere during the program scan. Specifically notice that “setting” the Overflow Trap does NOT fault the processor. If you need a simple analogy, think of it this way: The processor knows that something went wrong - so he writes himself a note and sticks it in his pocket. Setting S:5/0 to a 1 is the processor’s way of writing this little note. Now notice that even though something “went wrong” - we do NOT have a fault condition - not YET. But eventually the processor’s scan will reach the very end of Ladder File #2. If that note (S:5/0 = 1) is still in the processor’s pocket at the very end of the program - THEN we’re going to have a fault - and the processor will roll over and play dead. And that’s why many programmers habitually stick an unconditional rung at the very end of Ladder File #2 in every program just to automatically unlatch S:5/0 - they’ve been bitten by this dog before and they don’t want to shut down the plant just for some “lousy” math error. Now the wisdom of just “masking” the problem with a reset - versus calling attention to the problem with a faulted processor - (trust me, people WILL take notice of a faulted processor) - is highly debatable. I’m not going to get into that here. But I know that some of you out there have been puzzled by this “Overflow Trap - faulted processor - why can’t you just easily find the fault?” discussion going on in this thread. Now let’s continue on. We left our processor just as it finished up on Rung 0000. Location N7:1 contains the (incorrect) value 32767 - and the Overflow Trap bit (S:5/0) is set to a 1 condition.

In Rung 0001 the processor takes the value from N7:1 and divides it by 5. This gives the result 6553.4 - and the processor stores this new value into N7:1. Well, almost. Since N7:1 is an integer, the decimal portion won’t fit - so the value that actually gets stored is 6553.

In Rung 0002 the processor finishes up the conversion by adding 32 to the value in N7:1. So 6553 + 32 = 6585 - and that value gets stored back into N7:1 as the final result of our Centigrade to Fahrenheit conversion. Now unfortunately that value isn’t quite right. If you work it out yourself, you should come up with 3699 Centigrade = 6690 Fahrenheit. (OK, 6690.2 - so just round it off and get on with your life.) The point is: the processor came up with the wrong value. But when you think about it - it’s not really the processor’s fault that the math “went wrong” - the programmer didn’t give the processor a big enough box to store the math values in. Anyway - no matter how you slice it - the value 6585 is now stored in N7:1. And the processor is still scanning along. And don’t forget - he’s still got that note in his pocket.

Now eventually the scan reaches the last rung in the program - at the very end of Ladder File #2. Remember that little “something went wrong” note (S:5/0 = 1) in the processor’s pocket? Well, now that note comes into play. If nothing has “erased” that note (by resetting S:5/0 to 0) - and nothing in our sample program has - then we’re going to have a faulted processor.

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.

Now back to John Paley’s quote and we’re almost finished. The program shot I posted above clearly shows that a fault condition occurred - and the discussion above points out exactly where the math “went wrong” (way back in Rung 0000) - but if you go back and take a look at the program and search for an “overflow or a maxxed-out condition” - you won’t find “hide nor hair” of the offending math operation. That’s because the processor didn’t just quit scanning when Rung 0000 “went wrong” - it kept right on scanning - and the “maxxed-out condition” got over-written by a subsequent math step. John obviously knows that this is a possibility and that’s why he qualified his statement by saying: “You’ll PROBABLY find the culprit that way.” [emphasis mine] Allen Nelson knows how tricky finding this type of problem can be - so he suggested an excellent troubleshooting method of moving a TND (temporary end) statement successively through the program to isolate the problem rungs. That’s a very handy approach for MANY different types of troubleshooting scenarios. Still - for this particular type of problem - I personally like the little “flag bits” trick I suggested in post #4. These will point the way to the culprit even if you’re not available to monitor the operation for a fault which only occurs once in a blue moon. I’ve personally used this approach to troubleshoot several problems which were highly intermittent in nature.

Now - big question - how many of you have ever tried (or even heard of) RSLogix500’s “Go Single Step” feature? The easiest way to find it is to click the little pull-down arrow next to where you change the processor’s mode - near the upper left corner of your screen. Experiment with this feature someday when you have some free time and a non-production processor to play around with. Quick tip: For troubleshooting, you can actually tell your processor to scan through the program ONE RUNG AT A TIME and watch the show in slow motion on your screen. Also notice that you can set up breakpoints in your ladder files - etc. - etc. Why has no one ever mentioned these nifty little toys before? So many features - so little time.

Finally, in the program shot above, any value over 3640 would “break the bank” and cause an overflow in Rung 0000. And for those of you who are wondering: “Why did you use three separate math operations when a single CPT (compute) would do the same thing?” Well, some smaller processors don’t support the CPT instructions - plus I wanted to break the math down into steps for the purposes of this discussion.

My work here is done.

bad convert.jpg
 
Ron,

That is perhaps the best example / explanation for troubleshooting I have ever seen. Good Job.

Just wanted to confirm what you had said about using the "single step" and "break points" for troubleshooting. When I finally "woke up" some years ago and began to use these tools, I wondered how I ever got along without them!

Keep up the good work,
Chris
 
Qoute from Ron:

This rather lengthy post is intended for beginners only - you “big dogs” probably have better things to do. For those of you beginners who just can’t understand why finding this type of fault can sometimes be quite a gnarly little challenge ...

Old dogs , as well as big ones, can learn new tricks. Thanks for the ideas.
 
Guys,

Thanks for your reply, I think it's a great trick that I know.

BTW, is it safe if we fix or solved the problem with add a rung to unlatch the overflow bit permanently but without find out what causing this fault?
is it possible that overflow can comes from field device,let say a transmitter that have 0 - 10 VDC and suddenly this transmitter reach 11VDC,is it correct that the processor only limit it up to 32767 (10 VDC)?

Once again thank you very much for your thought.....great forum!!


Regards,

Deer
 
How to avoid math overflows rather than find them.

The previous replies have described how to locate where math overflows are generated.
I allways evaluate the overflow trap at the end of every sub-routine and generate a code to indicate the faulty program file. This gives a good start for debugging.

But shouldn't the program be designed to avoid math overflows totally ?
You cannot count on to be around to fix it when the problem occurs, or that it will not generate costly damages or downtime.

Thats why I use floating point math whereever possible.
You don't have to use floating point adresses for all your variables.
For AB PLCs, when using math instructions, the compute instruction and the scale-with-parameters instruction, one of the variables have to be a floating point for the ENTIRE calculation to be performed with floating point accuracy.
This will of course increase the scan cycle time as floating point math is more CPU intensive than integer math.
In order to counter this, math should be performed conditionally (with oneshots, when needed), rather than cyclically.

Another source of math overflows are counting operations that overrun. So I routinely add limiting instructions to every counting that I do in my programs.

I have not had a math overflow in many years now, so I think that to use the time to implement such methods is time well spent.

Hope that someone can use this.
 
Thanks Ron for a great post!

I started putting the following rung at the end of my files when I was worried about overflow traps.
Is this Form OK?
SOR GEQ N7:130 32766 MOV 32766 N7:130 EOR

overflow.jpg
 
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.

limiter.jpg
 
Last edited:
Deer said:
...is it safe if we fix ...the problem with add a rung to unlatch the overflow bit ...without find out what causing this fault?

Well, let's see. In Ron's example in Post #6, the operator entered a setpoint of 3699 ºC, and would have expected the PLC to convert it to 6690 ºF, but instead (with resetting the overflow bit), produced a setpoint of 6585 - 95 degrees low.

Is this safe? Probably not. That's why I generally DON'T just put in the reset logic by default, but use techniques like Jesper and George Bradley suggest, so that there CAN'T BE a math overflow.


is it possible that overflow can comes from field device,let say a transmitter that have 0 - 10 VDC and suddenly this transmitter reach 11VDC,is it correct that the processor only limit it up to 32767 (10 VDC)?

It depends.

If you use a SCP instruction to do your scaling, it won't overflow, unless the result exceeds 32767 in the Dest Integer file.

If you do your own scaling, and use intermediate integer registers like in Ron's example and the result exceeds 32767, then it will fault.
 
Hi Experts,

Thanks all for your reply, anyway I hope this post would be useful not just for me but for the beginners too.

Thanks a lot

Deer

:D
 
Even though this thread is very old, it helped me troubleshot and fixed a big problem I had yesterday. Thank you, all of you who contributed to this link long ago.
 

Similar Topics

I have a SLC 5/05 that faulted with a S:5 minor error bit and I can't figure out what that is. It says "A minor error bit is set at the end of...
Replies
2
Views
4,332
I'm trying to read/write to an SLC5 with a ControlLogix L71 V35 plc that fails. The exact same code works on an L82S with V32. Is there a known...
Replies
9
Views
85
I'm ashamed to admit this but I've never had to replace a battery in a SLC. Some how been able to skip that task in all my years. So yesterday...
Replies
8
Views
209
I have a program that I've used 100 times. SQO settings: File N7:0, Mask 0FFFFh, Dest B3:1, Control R6:0, Length 8, Pos 2. Length & Position...
Replies
48
Views
792
Hello PLC friends. I've been going through a saga of diagnosing and fixing an old PLC setup that I inherited. I am learning as I go. Initial...
Replies
14
Views
298
Back
Top Bottom