Sign in to follow this  
Followers 0
BIGEYE

SLC 5/04 Major Error

12 posts in this topic

I have an SLC 5/04 going in to fault and cannot find the cause. The error description reads: A minor eror bit is set at the end of the scan. refer to S:5 minor error bits. When I reset the fault and switch back to RUN, the plc goes in to fault immediately. The only way I can get the PLC operational is to download a backup of the PLC code to the PLC. However, after a couple of days, the same fault comes back again. The column of boxes at the left shows a 1 in only the Major Error Halt S:1/13 if this is of any significance. Appreciate any help on this one. TIA

Share this post


Link to post
Share on other sites
Hi Bigeye, Normally on SLC's system bits S:20 and S:21 can point you to the problem. S:20 is the rung and S:21 is the Routine. These values are at the bottom of the status screen where you see the S:1/13
1 person likes this

Share this post


Link to post
Share on other sites
Thanks for that, I have the PLC up and running just now and will check if/when it fails next time and get back.

Share this post


Link to post
Share on other sites
Also check S:6 to see what fault you're dealing with. Then goto the help and search Faults. Might just be a mathoverflow fault... Should point you in the right direction.. Once you find out what fault you're dealing with, write us back and we'll help. Regards,

Share this post


Link to post
Share on other sites
We've had this scenario happening for three months in a row a couple of years ago...Whatta pain!.... Someone did some "test programming" and forgot to either suspend the new logic or properly complete it. It was a CTU without a RES instruction!!!! It had a PRESET of 32767 and it counted every minute interval. So, of course, every twenty something days it was taking down the SLC in which's functional logic was residing! Downloading a back-up file will evidently place a lesser value within the counter's ACC bin and everything will be fine untill the ACC will become larger than PRE! Search the C:6 (and any other C: type )Data File and make sure every used counter has a RES instruction implemented (and functional) within the ladder logic. Edited by dmargineau

Share this post


Link to post
Share on other sites
HMMM? A counter should not cause a fault when it's ACC exceeds its PRE. Also it should not cause a overflow when it reaches 32767, it will turn negative and continue counting towards zero. Someone correct me if I'm wrong. Edited by Mickey

Share this post


Link to post
Share on other sites
Nope the CTU ACC exceeding the PRE should not fault the controller.
1 person likes this

Share this post


Link to post
Share on other sites
Mea culpa... It's been a while since the incident... The ACC value of the CTU was being used as the PRE of a TON. Of course, when the CTU ACC rolled over to negative values, the above mentioned TON wasn't defined anymore, causing an immediate hard fault within the processor. Most of the processor's "un-resetable" hard faults I have encountered, presuming functional hardware, were caused by Math Overflows and by timers with negative PRE values.... Edited by dmargineau

Share this post


Link to post
Share on other sites
I have gotten into the habit of using LIMs, GRTs or GEQs in front of every DIV with a non-constant divisor, and in front of every Timer.PRE calculation...sometimes it's simpler to do the math and then limit check/clamp it. An ounce of prevention... Edited by OkiePC

Share this post


Link to post
Share on other sites
Correct me if I am wrong, but but isn't S:5 the bit address for the Mathoverflow Trap. If this is the case you should take your process and safety considerations into account, but if you cannot find what is causing this issue, which it is likely it is not a program issue at all but a field device, you can get around this problem until you find the cause by adding an OTL S:5 at the end of your program. Hope this helps, and forgive me if I am wrong.

Share this post


Link to post
Share on other sites
follow up I meant OTL S:5/0

Share this post


Link to post
Share on other sites
I think you meant OTU at the end of file 2 and I would think the math overflow is a programing issue and not a field device but I have been wrong before.

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