SLC 5/04 fault????

john paley

Member
Join Date
Apr 2002
Location
Tennessee
Posts
304
I gets a processor fault on my slc5/04. So I goes in and look at the fault code--a minor fault has been set at the end of the scan, or whatever fault 20h says exactly. I've seen this fault before in other slc's and it was always some of my code causing a math overflow error. But this time--no math error--as a matter of fact, no s:5 bits are set--no minor error was set--or at least stayed set. Yet the 20h fault says" a minor bit was set at the end of the scan". Anybody ever seen that??

This fault occured twice--yesterday--but not since--in 24 hours. So I goes and ask the operator--What was the last thing that happened before the thing farted?? So he tells me I hit "line thread" then it stopped and gave me the unwind 5/04 farted alarm (not really a farted alarm, but a comms watchdog alarm). I follows the "line thread" trail, but nothing is different from before--can't overstuff the integers--this SLC has been in this application for more than 5 years without this kind of trouble. Why now??

So I puts a rung in at the end of file 2 to copy S:5 to an address and latch a bit if s:5 ain't equal to 0--just in case the minor bit is somehow healing itself after the fault--I can look at the other address and see what it was at just before the fault triggering "end of the scan". But it ain't faulted since.

Anybody got any ideas??
 
SLC 5/04 Errors

The SLC 5/04 will cause a Major error on math overflow. The standard function to assure this condition is to place an OTU for S:5/0 at the end rung of Ladder 2. However, the minor fault code described can be caused by a variety of conditions. Most notable are time out errors from speciality modules, rack errors, and software errors. Many are recoverable. Please provide more information on the module complement and we can proceed to the next step.
 
There is an 1746-HSCE conter, 2 1746-NIO4V'S, AND A 1747-SCNR controlnet scanner. Along with 7 bit type I/O cards.

Yes a math overflow will cause a major error--error 20h--which says that a minor error bit was 1 at the end of the scan. I've seen that many times in other applications and it was always my code. And I always fix the code, rather than simply reseting the math bit at the end of the scan.

The minor bits are in status word 5 (math overflow being s:5/0) My problem is that none of the minor bits are set while the SLC is still in the fault condition. I have the 20h major fault code--but no minor fault bits are set--never saw that before.

There is one s5 bit set--s:5/10--STI overflow--but this bit is not a minor fault bit that causes the 20h fault. As a matter of fact, the STI overflow bit goes to 1 every time I do an online edit. I guess that the STI can't run in a timely manner while testing or accepting edits--it really doesn't matter--that bit doesn't fault the processor.

Is it possible for a minor fault to reset itself after the processor halts?? I put code in there to try to catch that. Or is it possible for the STI bit to fault the processor just sometimes? I will put code in there to reset that bit. I'm grasping at straws, here. The problem seems to have gone away--it's been two days now--but I'd like to know what caused it. It just eats at me. Something's not right and I don't like it when something's not right.
 
Fault Routine

Is it possible for a minor fault to reset itself after the processor halts??

Yes. What you need is a Fault Routine. A seperate LAD file can clear the S:5 bits. IF the number of that LAD is in S:29, then when the SLC faults, that program is run, and the the S:5 bits are cleared. Of course, it would be a really good idea to clear the S:1/13 bit in that fault routine as well - then the SLC won't "****". This is why Error 20h is listed as a "recoverable fault" in the help.

I've got this set up in a SLC right now. If I toggle S:5/0, I see the "Fault" status come on for a moment, and then return back to "Remote Run".

In the fault routine, I also capture the date & time, the error code, and the file:rung of the error in a FIFO, so that I can see what happened and when. I'm still experimenting with it.

I also played with the SLC, and found that any bit S:5/0 through S:5/7 will cause 20h - even though the PLC doesn't use S5/5, /6 , or /7 (that I know of).
 
Last edited:
Allen,

What I meant to say was "Is it possible that the SLC is clearing the fault bits all by itself?" Like before I get a chance to view the status bits.

When your slc enters the fault routine, is the I/O interrupted for the time the fault routine takes to reset the s:1/13 bit?? Do you see the outputs "bounce" when you see the fault status is on? An interruption in outputs might upset my process to the point of "losing the line"--depending on the duration of the bounce. It is controlling an unwind on a paper handling machine and it has control of brake and dancer PSI for web tension regulation--not to mention pneumatic and hydraulic valves. Then again, my fault has only occured, so far, with the line stopped while entering the thread mode. In thread mode, it doesn't really matter what the I/O does.

But the fault routine sounds like a good way to see what the heck is going on--whether I auto-reset the thing, or not. I never needed one before cause SLC's status bits have always pointed me in a direction to find the problem. As it is with this particular application, the processor is not leaving a clue as to what happened to cause the fault--I'll work on a routine.

thanks
 
I Agree you should install an unlatch bit for S:5/0 at the end of your program. You my have to raise the Watchdog time also. Monitor the processor scan times and see how close they are to your watchdog time out. Message programs, Math errors and to many branches can slow down scan times. I would look into any changes.
 
I Agree you should install an unlatch bit for S:5/0 at the end of your program.

I beg to disagree. If there's some math causing an overflow trap there's math in my code that has been ill programmed, possibly to the point that the process is compromised. I'd rather find the problem and fix it than "hide" it with a catchall reset of the fault. But using a fault routine as Allen suggests allows me to do both--find the problem and automatically reset the bit.

However, I don't think my present problem is an overflow trap. If I'm wrong, then I have two problems--a math problem plus a processor that lies to me--as the math trap bit is not set when it faults. Our other SLC's have always pointed toward their fault causes before--math overflow traps included--that's why this particular fault puzzles me so darned much--the pesky booger simply is not leaving a trail.
 
Last edited:
John:

Can a SLC reset an S:5 bit all by itself?

Not if it's functioning properly. In mentioning the Fault Routine, I was bringing up the possiblity that an OEM might have put one in there and that you might already have one.

Something else to look at: Does this SLC have an EEPROM that it reads from when restarting? If so, it might be that the EPROM has the value 20h stored in it's memory of S:6, and when your guys go to restart, the old error code overwrites the REAL error code that stopped the thing.

I don't know that EEPROMs would overwrite S: data files, but it seems like a plausible explaination.

Do the outputs "bounce" when running the fault routine?

Unfortunately, I don't know. I'm running this thing on my desk with just a rack. All the output slots are disabled and everything simulated.

But I would guess that they would. When the fault is recovered from, the SLC goes through it's "prestart" scan (clearing all coils, timers, and the like), and the "First Scan" bit (S:1/15) gets set. So it would make sense that the outputs stopped for 10-20 msec.

Which is not good. But like you, I don't like the idea of masking a bug in my program by doing the "sensible" thing that Craig suggests and just unlatching S:5/0 at the end of my program regardless. If a bug is there, it should be eliminated. When I do get a calculation that has to cause an overflow (when I'm intentially loading S:13/S:14), I'll unlatch S:5/0 at the spot rather than at the end.

That's some of why I've been experimenting with Fault Routines. Just because there is a bug doesn't mean that the process should stop if it doesn't have to and I'm not around.
 
Last edited:
Allen,

Nope, no eeprom and no faulr routine. And the guys didn't restart it--I did. And I looked at the Status bits while it was still faulted --before the errors should have been cleared. The S:5 bits 0 thru 7 were all zero. Yet I had the 20h fault code that says one of the S:5 bits was set at the end of the scan.

And worse(?) thing of all, the problem seems to have just gone away. I may never discover what's been going on. (The thing just going away will make my boss happy though. But he's a manager and somehow we just aren't always on the same page.)

Thanks for your help! I'm gonna do that fault routine when I get the chance to play with the machine a little.
 
Last edited:
Latest Update

Well, after 6 or 7 days, it happened again. The circumstances just happened to present themselves in the correct manner. But this time, the math overflow was set when I looked before reset--before, it wasn't. The "move the s:5 word to storage at the last second worked, too.

I still didn't do a fault routine and reset but I did find the culprit rung--some of my math trying to put a too large compute result in an integer. I fixed that. Now I put it in a float, then if the float is within nrange, move it to athe integer. That's about the equivilant of a overflow reset bit, but the function of this part of the code really doesn't matter. If the number gets that big, it was derived under unfavorable conditions, anyhow. I also put bits in to make the possible conditions more favorable.

Anyhow, thanks for the response and all the help. I'm sure I'll be asking again.
 

Similar Topics

Hello all! I have some machines that run an SLC 5/03 and occasionally a fault is generated. Recent Example: A power supply wasn't screwed in...
Replies
3
Views
401
hello at work we have a machine controlled with an SLC 500 fixed, model 1747-l30c at fault, i plan to migrate to a micrologix controller. I'm...
Replies
7
Views
2,987
Has anyone ever seen this fault or have any insight as to what it was. I found this on an SLC 505 after we had the main breaker off working in...
Replies
1
Views
1,406
Hello everyone, I got called down to a plant to service a powdered metal press. It has an SLC 500 5/02 CPU that was faulted for the code 0002h...
Replies
9
Views
1,757
Hello! We have a drum rotation machine controlled by a AB SLC 500. The drum rotation inputs comes from a encoder into a 1746-HSCE. We are using 2...
Replies
0
Views
1,128
Back
Top Bottom