CLX Having A Power-Up Handler Causes Major Fault

I have a controller issue I think. 1756-L63

Using RSL5000 v20.05 I can verify a project and download it, do online edits and monitor fine.

However on this CPU if I have ANY routine run as a Power-Up Handler (even a single line with a NOP or TND) as soon as it is put in Run mode it faults. Per Rockwell the Power-Up Handler is NOT used when going from Program to Run, only on powering up, but this does it when switching every time.
[From KB QA2147 - TechConnect:
The power up handler only executes on a power up.
It does NOT execute on a program to run switch]

Online the Major Faults list is empty but on top reads "2 majors faults since cleared"

It did this with a standard routine used on other controllers fine. It kept doing this even when I put a TND as the first line, and then with all other lines removed.

If I go to properties for the power up and select 'None" instead of a routine the CPU runs fine.

I have downloaded a simple test program in case something else in the program was causing it, but it's he same. I don't have a spare CPU here to test - that would rule out or confirm a programming error

Has anyone else had a single CPU ever act like this?

Here is a screenshot of the power up routine I imported that works in other controllers fine.

Hi, I had a little problem with this also. I had to get this AHU to restart on it's own after a power fail. See snip to see what worked for me. RS 5000 v.20.01.
The logic is on branches is in my I/O mapping routine unconditioned. It will get unlatched in the main control routine when the unit comes on line and has a run permissive. Hope this helps.

In my experience, the Power-up has always worked only on power up, not a mode change. Has the routine been defined as the Main Routine? Assuming it is, is the "Powered" tag energizing on Power up?

I've always hated their sample logic for clearing a fault. I personally would remove rung #2 and then for the SSV, create a new tag and use that to reset the fault. That is why it tells you it has cleared two faults but doesn't show you the fault code. The MOVs are clearing that info.

The new tag would be full of zeroes which would wipe out the fault info but your data is still intact in the GSV tag.

OG

OG,

This is in the Power-Up Handler, program Power_Up, routine f001_Power_Up, and if I change the Configuration of Power_Up so there is an assigned Main Routine the CPU faults ever change from Program to Run. Clear the errors, change back to Run and faults every time without cycling the power.

I know SLC's do crazy things like this but this is the first CLX I have come across acting like a SLC.

You aren't assigning a fault routine are you? I see a routine that looks like one even though it isn't shown as assigned. And it looks like your fault clearing code is in what would be the main routine, which is correct.

The main routine acts sort of like a pseudo-fault routine. I'm not sure how it would react is there were also an assigned fault routine. Having a power up handler means it will fault, but it shouldn't do so on just a mode change.

I'll see if maybe a can dig some hardware up and test. I think I have an L63 somewhere.

OG

The power up fault only sets one bit for the HMI, and I tried it with and without that enabled.

Not bumping this,

Just got an email from Rockwell Product Safety of this exact thing, but they show it for the CLX 5580 Redundancy CPU's when this -L63, not redundancy, did the exact same thing.

They say to REMOVE the Power Up Handler and use the S:FS bit to replicate the Power Up Handler logic.

Knowledgebase ID PN1547 / 1130013 Level - Everyone

May i make the following suggestion.
create an entirely new program from scratch and include all the i/o.
have only 1 rung of logic in it that turns on an internal memory bit.
download it into the plc and try to run the program.
if it runs, you have a program issue, if it doesn't run, you have a hardware issue.
for the hardware issue, i would inspect all i/o back plane connections, power supply connections, and so on. i had a bent pin on a card one time that created this issue.
if its a program issue, copy the program 1 routine at a time into the test program and run it. time consuming, but you will find the issue.
hope this helps.
james

James Mcquade said:

May i make the following suggestion.
create an entirely new program from scratch and include all the i/o.
have only 1 rung of logic in it that turns on an internal memory bit.
download it into the plc and try to run the program.
if it runs, you have a program issue, if it doesn't run, you have a hardware issue.
for the hardware issue, i would inspect all i/o back plane connections, power supply connections, and so on. i had a bent pin on a card one time that created this issue.
if its a program issue, copy the program 1 routine at a time into the test program and run it. time consuming, but you will find the issue.
hope this helps.
james

Click to expand...

I had already done all of that and more. Even with a single main program rung if there is a Power Up routine there is a major fault going from Program to Run. I have had a Power Up of only one rung of NOP and tried TND - if it is called the CPU major faults.


Without the Power Up routine called the program, even the program in development, ran fine and would go from Program to Run without problem. Without it being called it would fault powering it up, I have to try the S:FS method to see if that will stop the powering up fault on the first scan, or see if the major fault is set before the first scan.



I think the KB article they just released covers this as a hardware issue, just beyond the 5580 Redundancy they say.

have you double checked the i/o configuration? i mean look at the module and compare it to the i/o config information.
you may want to change the chassis, swap the i/o modules, replace the cpu,
change the power supply.
i'm just making suggestions, anything to help.
james