5000 Fault

JeffKiper

Lifetime Supporting Member + Moderator
Join Date
Jun 2006
Location
Indiana
Posts
2,447
I have a CompactLogix L32E with a Power-Up Handler routine. In this routine it has a GSV MAJORFAULTRECORD that returns a value of 1160018464. So what is there does this value come from and what can I do to fix it. See NOTE

I DID NOT WRITE THIS PROGRAM!!!
I just have to maintain it and fix it.
GSV.JPG
 
Greetings Jeff ...



it will take me a little longer to nail everything down, but so far it looks like the original programmer just wanted to “clear any MAJOR faults” whenever the system first goes starts up in the Run mode ...



basic idea: when starting up in the Run mode, the RSLogix5000 GSV instruction goes and gets the “status type” stuff that RSLogix5 and RSLogix500 always just automatically gave us in the status files ... that information will be stored in a User Defined Tag named “PLC_Fault” starting at the “Timelow” location ...



the important part (for this exercise at least) is the information which gets stored in the “PLC_Fault.Type” and the “PLC_Fault.Code” locations ... whatever (number value) gets stored in those two locations gets overwritten (for better or for worse) by the MOV commands on the next rung ... after those two locations are written to ZERO values (effectively turned OFF) then all of the information in the PLC_Fault tag is sent back to the processor ...



the processor then sees ZEROs instead of numbers in its “Type” and “Code” locations - which in effect resets the fault ...



secret handshake: you’re probably already familiar with the Unlatch S:5/0 rung that is often used in RSLogix500 to keep an SLC or MicroLogix from faulting due to a “Math Overflow” condition ... think of the program rungs that you just posted as something along the same lines - but on steroids ... that’s a close enough analogy to get you on the right track with this one ...



to answer your specific question, the 1160018464 value is merely part of a “timestamp” that just tells WHEN (the specific point in time) that the fault last occurred ... the real meat and potatoes is in the Type and Code locations ... suggestion: don’t worry about the time stamp ...



plan of attack: decide whether it is appropriate for YOUR application to automatically reset any MAJOR faults this way each time that the system goes into Run mode ... once you’ve decided that, then you MIGHT (or might NOT) decide to start making judicious changes to the program ...


another suggestion: to get a “feel” for how the Power-Up Handler works, put a new simple "ADD Count_scans 1 Count_scans" rung in that routine just for experimental purposes ... then leave the processor in the Run mode - and cycle its power OFF and then back ON again ... that should increment the Count_scans location once each time the system starts up in the Run mode ... you'll note that this will also change that "timestamp" value that I've already mentioned ...


I’ll work on this some more this afternoon and tonight ... hope this helps for now ...
 
Last edited:
Greetings Jeff ...



here’s something else that I want to make clear ... the fact you’re your original program uses the word “fault” in several places does NOT necessarily mean that any “fault” actually occurred ...



play with the incrementing “scan counter” rung that I suggested in my first post (as in some of the classroom exercises we did) ... notice that the Startup Handler will execute even WITHOUT an actual fault - if you make the system power back up in the Run mode ...



best guess: at this point I’d say that your original programmer was trying to implement something which would automatically reset any major faults by allowing the operators to simply recycle the power to the machine ... in other words, the laptop would not be needed to get the system going again ...



now whether that’s a “good thing” or a “bad thing” remains to be seen ...
 
Last edited:
Ron

If I place COP after the GSV and copy the PLC_Fault.Type & PLC_Fault.Code to a different location before the next rung is examined (or is executed) that should keep this data in a location that I can look at right?



The SHOULD MY SYSTEM RESET AUTOMATICALLY is a question for a later date and time.



I have a L1 on the wall in the office so I plan on playing with it to see what happens. Sorry I haven’t gotten a chance to verify on the Compact it is in production. The production manager has no sense of humor. He doesn’t like me shutting down a line to experiment with the hardware.
 
If I place COP after the GSV and copy the PLC_Fault.Type & PLC_Fault.Code to a different location before the next rung is examined (or is executed) that should keep this data in a location that I can look at right?

yes, and if you use the same "logging" techniques that we used in the "Data Store" program you could also build a nice "log book" with several occurrences of any data that you're interested in ...

as far as I know the L1 should work the same way ... I haven't personally worked with CompactLogix - but I'd be very surprised if this part of the puzzle works any differently on that platform ...

just a quick question to make sure that we're both on the same track:

before you go any further, you need to make sure that you know what conditions are going to call this "Power-Up Handler" routine into operation ... it is NOT the same as a run-of-the-mill "fault handler" ... if you're not sure what I'm talking about, just put the "scan counter" (ADD) rung in the routine and experiment to see what conditions make it increment ... (with a spare non-production system of course) ... the main point of this line of discussion is that you won't get ALL "fault" type data from this routine ... the only time that it reacts will be when the processor POWERS UP in the Run mode ... if that's what you want, then party on ... if not, we need another arrangement to get the intended job done ...

at this point I’m highly suspicious that this programming approach will NOT do what the original programmer intended it to do ... basic reason: if a fault DID in fact occur, then the processor will not “power up” in the Run mode - even if the power to the system is cycled ... that means that the “Power-Up Handler” will NOT be called into execution - and so any intended “fault clearing and/or storing” won’t actually happen ...

basic idea: I’d bet (significantly more than pocket change) that the original programmer was confused by the differences between a “Power-Up Handler” and a “Fault Handler” ... if so, just make sure that you’re not blindly following along in the same pathway ...

specifically, the Power-Up Handler will NOT be called into operation (executed) by just switching the processor from Program mode to Run mode (by key switch, laptop, etc.) ... more specifically, the power will need to be turned ON with the Processor set for Run mode before the Startup Handler will be executed ... more to the point: my experiments in the lab show that the Startup Handler will NOT be executed if the processor was already in a “fault” condition when it powers down - and then powers back up ...

recommended course of action:

set up a SPARE bare-bones system with a Power-Up Handler ... place only a “scan counter” (ADD) rung in that routine to experiment ... place a “give-me-a-fault” rung in the Main Routine of the Main Program ... a JMP to a non-existing LBL makes a dandy test device for experimental purposes ...

get the processor running - and then cause a fault ... did the Power-Up Handler increment the ADD rung? ... (expected answer: no - and we still have a fault) ...

leave the processor in the fault condition ... cycle the power to the system ... did the Power-Up Handler increment the ADD rung? ... (expected answer: no - and we still have a fault) ...

reset the fault condition ... put the processor in the Run mode ... power down the system ... power the system back up ... did the Power-Up Handler increment the ADD rung? ... (expected answer: yes - and now we DO have a fault) ... take a deep breath and let that sink in ... check the fault code and you should see “Type 1 - Code 1 - Power lost and restored in RUN mode” ... in other words, by programming a “Power-Up Handler” we’ve told the processor to execute that handler whenever it powers up in the Run mode ... and ... since the handler routine is basically “empty” a fault resulted - and this kept the system from automatically starting right back up again ... in SOME applications that's exactly what we want to happen ...

now then ...

add the GSV-MOV-MOV-SSV rungs that you showed in your first post into the “Power-Up Handler” routine ...

get the processor running - and then cause a fault ... did the Power-Up Handler increment the ADD rung? ... (expected answer: no - and we still have a fault condition) ...

leave the processor in the fault condition ... cycle the power to the system ... did the Power-Up Handler increment the ADD rung? ... (expected answer: no - and we still have a fault condition) ...

reset any fault conditions ... put the processor in the Run mode ... power down the system ... power the system back up ... did the Power-Up Handler increment the ADD rung? ... (expected answer: yes - and this time we do NOT have a fault) ...

basic idea: those rungs in the “Power-Up Handler” just automatically reset the fault that the “Power-Up Handler” caused ...

I’m betting that a few simple experiments along these lines will convince you that this “Power-Up Handler” idea is not really doing whatever the original programmer intended it to do ...

now maybe he meant to come back later and add in more horsepower to the routine ... ??? ... I don’t know ... but as near as I can figure from where I sit, you could totally delete this whole routine and everything would work the same way it does now ...

word of warning ... every time you cycle power to the system, make sure that you wait long enough for the communications to time out - and then go back online to examine the test results ... secret handshake: the little “online gears” in RSLogix5000 continue to animate while waiting for the system communications to time out ... it’s easy to read “old news” with that going on ...
 
Greetings PGilbert ...



thanks for the links ... I’m swamped right now but I look forward to reading deeper tomorrow ...



The original programmer is trying to prevent a Major Fault when the controller is powered up. Without the SSV, the controller would fault with Type 01, Code 01.



yes, I fully agree ... my additional point was that merely removing the “Power-Up Handler” completely would achieve exactly the same effect ... in other words, since the handler is (apparently) doing nothing more than just “resetting itself” why not just scrap the routine completely and let nature take its course? ...



said another way, most RSLogix5000 applications are written without including a “Power-Up Handler” at all - and they work just fine ... I’m just a little bit puzzled why this guy went to the effort of putting in a feature that (apparently) serves no useful function - other than resetting a fault which IT (meaning the Power-Up Handler) causes to occur in the first place ...



I didn’t have time to read far into the link you provided, but I did notice this:



Sometimes a user will inadvertently add a power up handler then not know how to delete it.



maybe that’s what happened? ... just a guess at this point ...
 
Last edited:
Fault Routines

Greetings to everyone ,

And thanks again Ron for your very comprehensive explanations about the fault handling .

I've found a pdf from Rockwell ("Logix5000 Controllers Controller Major and Minor Faults") which includes a useful table showing the distinctions between the several classes of faults and how to handle them.

But still there are some unclear aspects to me. As far as I've understood, if any Major Fault is caused by the code, by the Program, this could be solve just by placing the appropriate logic in a Program's fault routine. When this kind of Major Fault might happen, that routine would be executed for one scan cycle.

But what about if, let's say, I want to detect any I/O module fault? where should I place my logic for recording this event? By reading the above aforementioned pdf I have made sense of placing a routine in the Controller Fault Handler folder. I don't know, though, whether this routine would be run in one scan cycle or not. The routines placed in this folder can be assigned to Main or to Fault classes, and that's why I'm a bit confused.

I want to log any I/O Module Major Fault event which might happen and collect some specific data(affected I/O module, timestamp associated to the event...) through the GSV instruction so that I can send an sms alert via my GSM modem.

Also, when reading this pdf, it is mentioned that there's a bit called S:MINOR which is turned on when any Minor Fault event happen. But it seems there's no other "S:MAJOR" bit for signaling Major Faults....am I right about this?

Fault Routines.jpg
 
That looks a lot like the powerup fault handler code that Prosoft includes in their example programs for their third-party network interface modules.

Is there a Prosoft module in your system, Jeff ?
 
Sorry for the confusion: I was replying to the original poster of this thread, Jeff Kiper.

The best way to get a thread dedicated to your particular topic is to create a new one.

If your topic is very similar to a recent or related thread, quote or link to that thread.

Jeff's issue with trying to understand what the Fault Routine was doing is a little different from yours in which a CompactLogix is faulting during brief power-down events.
 
Sorry for re-bringing up this old thread but I need some clarification on this.
My system is a L61 ControlLogix PLC with 4 remote IO racks. The racks are on separate UPS's.

We had a long power outage where 1 UPS failed, therefore the Remote IO failed. This gave a major fault on the PLC (required IO no connected). I do not have the "major fault on controller if connection fails while in run mode" checked (then again I was in remote mode as I'm currently commenting my program). The only way to get the PLC into run mode was to reset the fault through RSLogix5000 software (no fault or powerup routine).

Reading around, I found out about fault handing and power up routines. This is where I need clarification.
Fault handler routine (program created under Controller Fault Handler). This routine will be run ONLY when a fault (major or minor) has occurred. (see attached PDF for my draft at the fault handler routine).
Power-Up Fault Routine (program created under Power-Up Handler). This routine will be run ONLY when the processor goes into RUN mode (from the keyswitch or software when in remote mode).

My PDF's
The fault routine logs the fault and then if it is 4-16 (remote IO not connected) it will clear it.
The power up routine will log then clear all faults when powering up.

Parts that might be wrong.
Will the ONS be reset in the fault handler when the fault is cleared (else it wouldn't log again). This would cause the log to be filled with this one error very quickly, but thats OK.
Would this fault routine still allow the rest of the program to run - I can test this when I download the program.
Does the power up handler routine only get run once (before 1st prescan) or will it be actively scanned.
If there was a major fault in the processor and the power was cycled, would the power up handler routine be run, or would it run the fault handler instead?

Thanks for all your help
Chris
 
Greetings Chris ...

here's a survival tip:

using a SPARE system, go to each of your "fault handler" files and insert a "scan counter" rung ... something like the figure shown below ... (be sure to use a SEPARATE tag for each counter) ...

now simulate various faults (there are usually some suggestions on how to do this in the "Online Books" under Help) ...

now each time a specific fault handler is triggered, the "scan counter" rung in that particular file will increment its value ... this is the best way to see EXACTLY what's going to happen when certain types of faults occur ...

if I have some spare time later, I'll be glad to look over the files you've posted ... no doubt the other members will have everything nailed down before then ...

hope this helps ...

scancounter.JPG
 
Cheers for the reply. I have a bad battery on our spare system, so I cannot test the Power-Up routine (which is what I wanted to do). I will look into simulating faults and see if my code works with that.
 

Similar Topics

Does anyone know the bits to examine for processor fault status? For a simple processor status indicator. Currently I'm using from GSV...
Replies
9
Views
1,115
​Hello everyone, I triyng to link a Power Module eMB-60R from Robot Adept Viper s650 to CompactLogix, version 19.11 I followed exactly the...
Replies
9
Views
2,549
I've made a fault routine to notify operators when an IO module causes a major fault, and provided a button to manually reset the fault, but I'd...
Replies
8
Views
2,389
Hi, I have 2 safety devices (Banner EZ LS light curtains and a Keyence GS-71 Interlock) that are giving me some difficulties. The plc is a Compact...
Replies
6
Views
1,929
does anyone know how or If you can Change the default sheet size to A3 for New FBD's so that when you create a new FBD during online editing it...
Replies
0
Views
754
Back
Top Bottom