S7 Fail Safe Input Status

Using an ET200S system with classic S7. I have three fail safe input modules of which the first six channels are direct wired estops (dual channel NC on both channels, single estop per channel).

Have them addressed in hardware as I100.0,1,2,3 and I106.0,1.

They are working fine in the safety program and are chained as inputs to a an FB215.

However, I have the same bits chained in some other code (that is called by OB1 once every scan) and it is indicating that I am getting a "flicker" on one or more of these channels. At first I though it was just a "monitoring/eyeglass" mode anomaly, but I put a counter off of it and sure enough it is flickering off for very brief time at random times that are around once a second.

Am I correct in believing that if the actual inputs were really flickering that it would have dropped out FB215? If so, what else could account for the discrepancy in the state of the safe input status between my normal code and my safety code?

After a little more digging, All four inputs on module 1 are solid and no flickering.
All four on module 2 and all four on module 3 flicker. All 8 of those points flicker. I suspect they all flicker OFF at the same time. It seems as though the process image word is getting overwritten for those two modules.

Ok, part of the mystery solved. Module 2 and 3 both had a hardware error on the module. Acknowledging that error eliminated the flickering.

Although it is obvious now that the error was related to the flickering, I don't see a good reason that those channel status inputs should be flickering regardless of the error state. I would not expect an error on one channel to affect the status of all channels on the module. I would expect the status channel to reflect the status of the device regardless of error. If there truly was an error on one of the channels, I would expect the status bit of the channel to either reflect the current state of the channel, or be latched OFF. Does anyone have a rationalization for the behavior I am seeing?

DamianInRochester said:

Ok, part of the mystery solved. Module 2 and 3 both had a hardware error on the module. Acknowledging that error eliminated the flickering.

Although it is obvious now that the error was related to the flickering, I don't see a good reason that those channel status inputs should be flickering regardless of the error state. I would not expect an error on one channel to affect the status of all channels on the module. I would expect the status channel to reflect the status of the device regardless of error. If there truly was an error on one of the channels, I would expect the status bit of the channel to either reflect the current state of the channel, or be latched OFF. Does anyone have a rationalization for the behavior I am seeing?

Click to expand...

If I understand rihgt.you need to put you you safety problem into a fix cycle time OB (ex. OB35) and set Max.cycle time longer than real cycle time in runtime group.
Ohter proposal is you are useing external power supply for these problem channels? If yes, you need to claim in hardware configuration for thsi channel.

hill831017 said:

If I understand rihgt.you need to put you you safety problem into a fix cycle time OB (ex. OB35) and set Max.cycle time longer than real cycle time in runtime group.
Ohter proposal is you are useing external power supply for these problem channels? If yes, you need to claim in hardware configuration for thsi channel.

Click to expand...

They are executed from OB35 and the channels are powered by the modules.
The problem is, quite simply, that if I get a channel error on any one channel in a module it causes a flicker on the status signal for all points of IO on that module (even if configured that each channel faults independently). And even regardless of that, I would not expect a channel in fault to have its active status flicker at random intervals (or at all for that matter). It should either indicate the perceived current state of the device, or it should off completely.

That said, the channels were faulting legitimately and the reason they were has been corrected. I just don't agree with the channel behavior when in fault.

Hi!

Could you please describe the hardware error?

Did you try to measure or o-scope the inputs?
The LEDs might glow even if the voltage is too low to give an '1' -signal.

Kalle

KalleOlsen said:

Hi!

Could you please describe the hardware error?

Did you try to measure or o-scope the inputs?
The LEDs might glow even if the voltage is too low to give an '1' -signal.

Kalle

Click to expand...

The fault was being caused by a timing discrepancy between channel 1 and channel 2. All voltages are fine. The intermittent "blip" that happens while in fault is not created by the fault itself.

DamianInRochester said:

They are executed from OB35 and the channels are powered by the modules.
The problem is, quite simply, that if I get a channel error on any one channel in a module it causes a flicker on the status signal for all points of IO on that module (even if configured that each channel faults independently). And even regardless of that, I would not expect a channel in fault to have its active status flicker at random intervals (or at all for that matter). It should either indicate the perceived current state of the device, or it should off completely.

That said, the channels were faulting legitimately and the reason they were has been corrected. I just don't agree with the channel behavior when in fault.

Click to expand...

Have you tried to switch OK channel safety element with fault element? Mybe it's a external device problem. Or switch the fail-safe module,rack.

I had once strange problem one e-stop alway cause CPU stop, and finally i find it out, my panel software sometime writing data to the safety DB. Hope this could be kind of hint to help find your problem.