Monitoring and or detecting CPU faulted condition

[gmarowski 1]

I have a process in which one PLC is dependent on another PLC being fully operational before it begins. Sometimes, like when we have a power failure, the CPU on System 1 is faulted, and system 2 starts up fine without knowing about system 1's problem, This is costing us time and money and I need to figure out how to prevent this.

I found that I can monitor the S:1/13 bit on System 1 from a Panelview and set up a warning indicator there. But I can't seem to be able to directly monitor the S:1/13 bit from the PLC of System 2. If I could, then I could convert that into a B3 or N7 and use it to sound an audible alarm from System 2, which is my ultimate goal.

Any ideas?

[AndrewG 13]

What kind of PLC do you have (SLC, ControlLogix etc)? In RSLogix5000, there is a GSV (get system value) instruction which may be useful. According to the Instruction Help, you can use the GSV instruction to access the FAULTLOG object, which includes a count of the number of major and minor faults.

 

[Michael Lloyd 85]

You can use a Message block to retrieve the status

[gmarowski 1]

Sorry about that, I forgot to mention that it is SLC 5/05's and RSlogix 500.

I wasn't sure if a message block would be able to access the "S" registers or not. I'll give it a try.

 

[Michael Lloyd 85]

If not just map the S register value to a register

[gmarowski 1]

50 minutes ago, Michael Lloyd said:

If not just map the S register value to a register

I tried using S:1/13 to set a bit (B3x/x) to zero (normal) or 1 (fault) and also tried MOVing the value of S:1/13 to an N7 integer, but in both cases the CPU faults and the program stops without changing the the value. This is why I'm stumped. I can see the S register directly, but can't make anything else happen as the program stops and all PLC inputs and outputs are frozen. Or so it seems.

This is why I turned to the Panelview. It could access the S:1/13 register and at least through up an indication that the CPU is faulted.

[Ken Roach 194]

It's sort of a bootstrap problem;  if the controller is faulted, it's not executing logic, so it can't move the Status file elements to another location or send a MSG instruction of its own.

That's one of the reasons that the ControlLogix platform got Fault Handler tasks and events in its operating system.

You should be able to access the Status data file in Controller 1 with a MSG instruction in Controller 2.   Treat it like it's an Integer file.   I can't guarantee that will work;  I have not tried it myself.

In my opinion the most straightforward way to interlock these controllers is a hardwired solid-state Output -> Input watchdog signal.    If the watchdog stops changing state at the customary rate, Controller 2 will know that Controller 1 is powered off or faulted.

[gmarowski 1]

1 hour ago, Ken Roach said:

You should be able to access the Status data file in Controller 1 with a MSG instruction in Controller 2.   Treat it like it's an Integer file.   I can't guarantee that will work;  I have not tried it myself.

In my opinion the most straightforward way to interlock these controllers is a hardwired solid-state Output -> Input watchdog signal.    If the watchdog stops changing state at the customary rate, Controller 2 will know that Controller 1 is powered off or faulted.

I agree, a simple MSG instruction should work, I'll have to try tomorrow. Kinda rusty on MSG instructions.

I like the idea of a watchdog output, but I'm not sure the SCL has anything like that available. I'll have to look into that, but I don't think it does.

It's beginning to sound like the MSG is the way to go. As long as I don't lose communications it should be OK. And even if I have a loss of comms, I'll detect that as well, trap it, and generate another error to be alerted of.

Thanks everyone for the input and help. I'll let you know what I find. If you have any more idea, please feel free to drop them off here. I can always use a hand and always looking to learn.

[Ken Roach 194]

When I use a hardwired watchdog, it's a DIY affair rather than a dedicated purpose "fault relay".

Typically I just wire an output from one PLC to an input on the other PLC, then run that output at 1 Hz (on 500 ms, off 500 ms).

On the receiving side, if the input stays low for 1000 ms then I know that the watchdog sender has faulted, been shut off, or that there's a broken wire.   If it says high, then there's probably a short circuit to +24V.
 

The usual problem you run into is if the PLC Output module has enough leakage to turn on the Input module.   If so, you add a drain resistor in parallel.

[gmarowski 1]

Thanks for the idea Ken! That may be the best soultion so far. Lots to think about... Thanks.

 

[Michael Lloyd 85]

21 hours ago, Ken Roach said:

When I use a hardwired watchdog, it's a DIY affair rather than a dedicated purpose "fault relay".

Typically I just wire an output from one PLC to an input on the other PLC, then run that output at 1 Hz (on 500 ms, off 500 ms).

On the receiving side, if the input stays low for 1000 ms then I know that the watchdog sender has faulted, been shut off, or that there's a broken wire.   If it says high, then there's probably a short circuit to +24V.
 

The usual problem you run into is if the PLC Output module has enough leakage to turn on the Input module.   If so, you add a drain resistor in parallel.

Just a thought, I wonder how many cycles a relay output card could handle? We use all 120VAC relay output cards and I've been hesitant to do watchdog this way. at 1 sec per cycle it adds up quick...