MicroLogix Fault

We have a small machine that has an Allen Bradley Micrologix 1000 controlling it. Its been running for about 5 years trouble free. Today they had a problem that the machine would not run and when we checked, the Fault light on the Micrologix was blinking. Turning off the machine and restarting it would not clear the fault so we hooked up the laptop and cleared it using the RSLogix 500 software. The message that showed up was as follows:

MINOR ERROR AT THE END OF SCAN
REFER TO S:5

We were able to clear the fault and everything is back up and running. Is there anyway to determine what actually caused the fault or something we should look for if it happens again.

Thanks
Fred

It's probably too lat now to find out what caused this occurrence. The next time, before resetting the error, look through the tables especially for a high number. There may have been a rollover from the highest number to a negative number.

Ok Bernie, I will do that if it happens again. The PLC really doesn't do alot, there are a few counters in the program and a few timers, then just inputs and outputs.

Thanks
Fred

There are a handful of things that could have caused a minor error bit to be set.

Are you doing any HMI data entry on this machine?
Does it have a hard wired thumbwheel input by chance?

MINOR ERROR AT THE END OF SCAN
REFER TO S:5

Click to expand...

Overflow Trap S:5/0
When this bit is set (1) by the controller, it indicates that a mathematical overflow has occurred in the ladder program.

Click to expand...

If either the Accumulator or the Preset is negative when the TON instruction is executed on a true rung, a Major Fault (0034) is generated.

Click to expand...

__

can you post a copy of your existing program? ... (you'll have to ZIP it first - forum rule) ... even if the fault doesn't show up, we MIGHT be able to spot a likely culprit ...

incidentally, timers and counters won't be on the list for an S:5/0 overflow fault ... specifically, a counter has its own "overflow" bit - but that one won't cause a fault ...

many (most?) programmers put an unconditional Unlatch rung at the end of Ladder File #2 to prevent this type of fault ... there is an ongoing debate about the wisdom of doing that - but it's a VERY common practice ...

note: if you're also using an STI arrangement, you might want to consider putting the same type of Unlatch rung at the end of that file also ...

You may wish to consider setting the S:1/8 (fault override at power up) bit. This bit must be set offline (go online and save all first) and then downloaded. Then cycling power to the machine will reset the fault.

It is however good practice to keep minor errors from occurring in the first place.

Most likely you have an overflow error from a math operation. Counter (CTU and CTD) roll-over doesn't set S:5/0 but counting using an ADD could cause an overflow. You can prevent this in the future by examining the status of S:5/0 at the end of any subroutine that performs math and if it is set you can unlatch the bit and take corrective action on the math result.

The other possibility is that you are using a LFU, LFL, FFU, FFL, BSL, BSR, SQO, SQC or SQL instructions somewhere in the program amd one of these had an error and set the S:5/2 bit. To find out which one examine the .ER bit in the R6 control word for the instruction.

If you would like to zip your .RSS program file and attach it to a post then several forum members will see it and we might be able to point you at possible culprits and fixes.

It is communicating with an HMI display, no hard wired thumbwheels

I will have to check the overflow trap if it happens again
Thanks

When i go back to work on Monday, i will send a copy of the program. It wasn't written by my, came already on the machine but I will be happy to send it and see if you can find anything wrong with it. I appreciate all your help. Our plant is one of those places that gets alot of equipment from different plants that close in the corporation. At last count we had 8 different brands of PLC's in the plants and 5 different brands of HMI's not to mention all the different brands of stepper drives, servo drives...the list goes on and on. Its a major task just keeping everything up and running that is why I really appreciate all the help I get on here.
Thanks
Fred

Tracking down the root cause is an excellent lesson in using RSLogix500.

When I have a shedload of logic which has the potential to cause something like this, or when I inherit SLC code that (even rarely) has an overflow, I like to put in a trap.

I examine the error bit, then unlatch it and set my own internal (HMI alarm) bit. I use one unique bit for each ladder file. This keeps the process running, and you can then find out which ladder file(s) contain the offending logic.

You can then check the bits periodically with RSLogix, or monitor the HMI alarm history for evidence of where to narrow the search.

Note that THERE IS REAL RISK to doing this, only you know if you understand the machine well enough to examine the possible consequences of any math errors if you let the machine keep trying to run with a bogus value somewhere in its memory.

Hopefully on the next scan, any math issues or HMI scaling that causes an issue will either be cleared up, or cause no machinery issues.

ONLY do the unconditional unlatch without trap bits if you are:
a) out of memory
AND
b) when you are sure there won't any dangerous repurcussions
AND
C) ONLY after doing the sleuthing to find out exactly which instruction(s) are causing it.

Just my advice,
Paul

At last count we had 8 different brands of PLC's in the plants and 5 different brands of HMI's not to mention all the different brands of stepper drives, servo drives...the list goes on and on.

Click to expand...

Someone should send a message to the man who is responsible for this mess. Ask him what he is thinking, and suggest that he have his head examined with a CT scan. Most likely he has a brain tumor of some type...

fredjohns said:

At last count we had 8 different brands of PLC's in the plants and 5 different brands of HMI's

Click to expand...

Sounds like a dream come true for me (but I do feel your pain)

adversity and opportunity often travel hand-in-hand ...

Our plant is one of those places that gets alot of equipment from different plants that close in the corporation.

Click to expand...

unfortunately this is happening more and more these days ... nobody PLANS it this way – they're usually just trying to do the best that they can using whatever resources they've got available ...

look at the bright side ... YOU still have a job ... many of the folks in those "closed down" plants might not be able to say the same ...

suggestion: learn EVERYTHING you can about EVERYTHING that you've got ... MAKE A LIST of it all ... keep notes and manuals ... you never can tell when knowledge like that is going to come in useful on a resume ...

hope for the best – prepare for the worst ...

Yes, it's the type of challenge that makes the job fun and puts feathers in your headdress, when poor or absent planning pits your wits against a pile of random semi-obsolete controls.