Jump to content


Photo
- - - - -

help with a fault on SLC-5/03


  • Please log in to reply
13 replies to this topic

#1 tgorupMFT

tgorupMFT

    Sparky

  • MrPLC Member
  • PipPipPip
  • 13 posts

Posted 24 May 2005 - 08:41 PM

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

#2 gravitar

gravitar

    Slacker

  • MrPLC Member
  • PipPipPipPipPip
  • 998 posts
  • Location:Home of last year's American League champions!
  • Country:United States
    United States

Posted 24 May 2005 - 10:25 PM

The first thing you need to do is go online with the faulted processor and see what the fault code is.

#3 tgorupMFT

tgorupMFT

    Sparky

  • MrPLC Member
  • PipPipPip
  • 13 posts

Posted 24 May 2005 - 10:28 PM

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.

#4 jstolaruk

jstolaruk

    industrial sorcery

  • MrPLC Member
  • PipPipPip
  • 429 posts
  • Gender:Male
  • Location:SE Michigan
  • Interests:Golf, Shotgun Sports
  • Country:United States
    United States

Posted 24 May 2005 - 10:42 PM

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.

#5 Ken Moore

Ken Moore

    Principal Specialist

  • MrPLC Admin
  • 1710 posts
  • Gender:Male
  • Location:Upstate South Carolina
  • Country:United States
    United States

Posted 25 May 2005 - 05:33 AM

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

Attached Images

  • overflow.jpg






#6 Ron Beaufort

Ron Beaufort

    Guru

  • MrPLC Member
  • PipPipPipPipPip
  • 814 posts
  • Location:Charleston, SC
  • Country:United States
    United States

Posted 25 May 2005 - 10:37 AM

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

Best regards,
Ron
PLC Training Boot Camp

I once was lost, but now am found, was blind, but now I see.

#7 Chris Elston

Chris Elston

    Controls Engineer

  • Super Admin
  • 3051 posts
  • Gender:Male
  • Location:Indiana
  • Country:United States
    United States

Posted 25 May 2005 - 10:52 AM

fixed it.

#8 OkiePC

OkiePC

    Boat Rocker/Trouble Breaker

  • MrPLC Member
  • PipPipPipPipPip
  • 934 posts
  • Gender:Male
  • Location:Oklahoma
  • Interests:Kids, Outdoors, Animals, Sports, Science, Math, Music, Puzzles, Video Games, Food, Watersports, Paintball, Jeeps, Pit Bulldogs, Chevy, OU Football, Hiking, Piddling, more ...
  • Country:United States
    United States

Posted 25 May 2005 - 01:52 PM

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.

#9 OkiePC

OkiePC

    Boat Rocker/Trouble Breaker

  • MrPLC Member
  • PipPipPipPipPip
  • 934 posts
  • Gender:Male
  • Location:Oklahoma
  • Interests:Kids, Outdoors, Animals, Sports, Science, Math, Music, Puzzles, Video Games, Food, Watersports, Paintball, Jeeps, Pit Bulldogs, Chevy, OU Football, Hiking, Piddling, more ...
  • Country:United States
    United States

Posted 25 May 2005 - 02:30 PM

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.

#10 k.dougherty

k.dougherty

    Hi, I am New!

  • MrPLC Member
  • Pip
  • 4 posts

Posted 25 May 2005 - 02:33 PM

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.

#11 tgorupMFT

tgorupMFT

    Sparky

  • MrPLC Member
  • PipPipPip
  • 13 posts

Posted 25 May 2005 - 04:40 PM

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

#12 Ghettofreeryder

Ghettofreeryder

    Logic Wizard

  • MrPLC Member
  • PipPipPip
  • 86 posts
  • Location:Drayton Valley, Alberta
  • Country:Canada
    Canada

Posted 26 May 2005 - 01:10 AM

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

#13 jstolaruk

jstolaruk

    industrial sorcery

  • MrPLC Member
  • PipPipPip
  • 429 posts
  • Gender:Male
  • Location:SE Michigan
  • Interests:Golf, Shotgun Sports
  • Country:United States
    United States

Posted 26 May 2005 - 07:47 AM

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

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.

#14 Ghettofreeryder

Ghettofreeryder

    Logic Wizard

  • MrPLC Member
  • PipPipPip
  • 86 posts
  • Location:Drayton Valley, Alberta
  • Country:Canada
    Canada

Posted 26 May 2005 - 09:24 AM

Ya, i guess it all comes down to personal preference, but its just something i dont do. If it works, why not i guess.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users