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