Sign in to follow this  
Followers 0
tgorupMFT

help with a fault on SLC-5/03

14 posts in this topic

Hope someone here can give me a hand, I'm new to this stuff and do not have any real training, so go easy on me. Ok, here is my problem. I got 5 AB SLC 5/03 systems running that are networked together by DH-485 link couplers. 4 of them are robotic cells the other is a parts conveyor. All of a sudden one of the robot PLCs will fault and shut down. It only happens when its time for it to unload into the parts conveyor, before then everything is fine. We had this problem once befor and the SLC 5/03 CPU was swapped out and it worked again, well I tried that this time and still the same thing happens. Does anybody have any suggestions? Thanks

Share this post


Link to post
Share on other sites
The first thing you need to do is go online with the faulted processor and see what the fault code is.

Share this post


Link to post
Share on other sites
Ok, here is what it said. Major Error Halt S:1/13= 1 Math Overflow Trap S:5/0= 1 Error Description A minor error bit is set at the end of the scan. Refer to S:5 minor error bits.

Share this post


Link to post
Share on other sites
In some of the SLCs (5/04 was the last) I've had a problem with the Math Overflow Trap setting for no clear reason so I put a "OTU S:5/0" rung at the very end of the scan and it takes care of it.

Share this post


Link to post
Share on other sites
To the bes of my knowledge all the SLC's will fault for a math overflow, depending on the application, you may or maynot want the processor to fault, I use the following code to reset the fault bit and capture it with a fault flag, you can then use the flag to record the fault, take action etc....

Share this post


Link to post
Share on other sites
Greetings tgorupMFT, in addition to the excellent advice already posted, you might want to take a look at the “Basics of Math Overflow Faults" in this post ... and possibly the handy trick to help track down the offending “bad math” rung covered in this post will prove useful ... hope that this helps ... and welcome to the forum ... PS ... I have no idea why your original thread is marked "closed" ... but I decided to post this information here (in a new thread with the same title) just in case you might find it helpful ...

Share this post


Link to post
Share on other sites
In addition to trapping and resetting the math overflow bit, you can see what file and rung caused the problem by examining words S:21 and S:20. There is probably a divide by zero or something like that happening at that certain point in the cycle. You can add limit checks ahead of th math instructions to prevent a processor fault, but there may be more work required to get the root of the problem eliminated.

Share this post


Link to post
Share on other sites
Ron Beaufort PM'd and let me know that I was wrong about the S:20 and S:21 registers. Apparently they don't record the location of the bad logic for this type of fault. Ron, Thanks for straightening me out...I scanned your links, but apparently didn't read them very well. It seems I can remember using the S:20 and S:21 words to troubleshoot math overflow problems in the past, but perhaps I was working on a different type of fault. Thanks, and sorry for any confusion I might have caused. Paul C.

Share this post


Link to post
Share on other sites
OkiePC nailed the problem, at least in my case. It took me forever to figure out that the possibility of dividing by zero existed within my logic. I was able to solve the problem by using limit tests. If I had the S:21 and S:20 knowledge at the time I would still have a full head of hair.

Share this post


Link to post
Share on other sites
Thanks everybody for the help. I did add the above code into the program but I'll have to wait and see if it works out, I was able to get the system back up and running by doing a "load from eeprom". Thanks again for all the help. Tom

Share this post


Link to post
Share on other sites
I wouldnt add that code, unlatching the overflow bit, Personally, i think thats a chickenshit way of doing it. All you need to do is properly condition your math, and the problem is solved. I see lots and lots of engineering companies unlatching the overflow bit, when all it takes is a properly written program to solve it

Share this post


Link to post
Share on other sites
Even with the limit tests looking for underflow and overflow conditions I've had that bit set and the suggested fix came from a local AB tech. I traced one instance down to a CPT instruction that was computing an answer for display purposes but that was as far as I could go. No way was I going to spend a lot of time on something that could be firmware related so I put the patch in and moved on.

Share this post


Link to post
Share on other sites
Ya, i guess it all comes down to personal preference, but its just something i dont do. If it works, why not i guess.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0