AB DCS Instructions - Gaurdlogix

[PSHIA_ESS]

Hello All,
New to this forum. I'm reviewing two programs from two different integrators we have used. Both are using Guardlogix 5094-IB16S/A safety inputs for their e-stops. One program is using a Dual Channel Input Stop (DCS) instruction. The other does not and just uses the inputs from the module as a permissive for the e-stop logic. Question is, in order to maintain Cat3 and 4 safety requirements, does your OSHA require using the DCS instructions? All programming examples I've seen are using the DCS.
Thx

 

[robertmee]

I use DCS for all my estop Inputs. They monitor both feedback and feedback status to insure safe state before reset. Usually, the output of the DCS becomes the actuate or permissibe to a CROUT type instruction that enables a safety output to a device.

Using just a safety input as a permissive to a safety output does not satisfy cat 3.

 

[ASF]

It possible the one without DCS instructions is doing the error checking at the hardware level. That is, the channels are configured as dual-equivalent at the module configuration. If there is any sort of error (short between channels, wiring crossover, input discrepancy) that hardware detects it and turns off both inputs to the code.

Both are equally valid, but setting the inputs to Single Channel and doing the diagnostics in the software with DCS instructions makes for a much easier system to troubleshoot and diagnose.

As to whether [arrangement ABC] meets [safety requirement XYZ], the answer is "maybe". A full safety verification is required to answer that comprehensively. It's not longer as simple as single channel vs dual channel, it takes a lot more things into consideration than just the architecture of the circuit.

 

[robertmee]

It possible the one without DCS instructions is doing the error checking at the hardware level. That is, the channels are configured as dual-equivalent at the module configuration. If there is any sort of error (short between channels, wiring crossover, input discrepancy) that hardware detects it and turns off both inputs to the code.

Both are equally valid, but setting the inputs to Single Channel and doing the diagnostics in the software with DCS instructions makes for a much easier system to troubleshoot and diagnose.

As to whether [arrangement ABC] meets [safety requirement XYZ], the answer is "maybe". A full safety verification is required to answer that comprehensively. It's not longer as simple as single channel vs dual channel, it takes a lot more things into consideration than just the architecture of the circuit.

DCS enforces a reset from safe state. A dual channel equivalency configured in an IB8S for example does not. The IB8S inputs become true as soon as the channels meet the equivalency check. If those inputs are used directly in estop logic permissive to say enable an output to a drive, that's not going to meet cat 3/4. I agree with you, it's very difficult to know what the OP is seeing exactly. A lot of considerations with both the hardware and software side. But it seemed his description of inputs being used in estop logic sounds like old school inputs turning on an output, bypassing safety instructions.

 

[ASF]

Oh, totally agree, you still have to program in the manual reset (if the risk assessment requires a manual reset), it's only the input validity that's checked by the hardware-level configuration as you say.

Then again I do that anyway, even when using DCS instructions, for the most part. I have all of my DCS instructions automatically reset, and then do the manual falling-edge reset at the output stage. This means as soon as you release the e/stop or close the guard or whatnot, I can see that you've done that and that contacts closed within the right amount of time, and that everything is otherwise healthy, just waiting for my reset signal to energise my safety outputs.

Many ways to skin this cat.

 

[robertmee]

Oh, totally agree, you still have to program in the manual reset (if the risk assessment requires a manual reset), it's only the input validity that's checked by the hardware-level configuration as you say.

Then again I do that anyway, even when using DCS instructions, for the most part. I have all of my DCS instructions automatically reset, and then do the manual falling-edge reset at the output stage. This means as soon as you release the e/stop or close the guard or whatnot, I can see that you've done that and that contacts closed within the right amount of time, and that everything is otherwise healthy, just waiting for my reset signal to energise my safety outputs.

Many ways to skin this cat.

Exactly what I do...my DCS is auto reset, the O1 of the DCS is the actuate to the CROUT, which uses the falling edge trigger to reset the 2 channels to the device (drive, locking gate, servo, etc). Do you ever have issues on a program download? Even with cold start and reset on automatic, sometimes the dcs requires a false to true transition...ive even passed the FP bit to Safety to try and flash the DCS reset to no avail. It's an abnormal situation, doing a download, but wondering if you've encountered this.

 

[ASF]

Yes, I've seen that. It also happens going from Program Mode to Run Mode.

The way my safety programs are (usually) structured is:
1: Safety inputs routine
1a: Generate falling edge reset from safety input, after checking status of input
1b: safety input checking and DCS instructions for all safety input devices (or, if I'm using 5069/1756 safety I/O, a single AOI of my own creation that has a DCS inside and also does the safety input checking for me)
1c: summary OTE of safety input devices (e.g. all e/stops healthy, all guards healthy, etc)

2: Safety outputs routine
2a: safety input and output status checking for each safety output
2b: "actuate" rung for each safety output (usually uses the "all e/stops healthy" and "all guards healthy" from 1c). Programmed as a simple hold-in circuit with the falling edge reset from 1a, and drops out if the .FP is active for the corresponding safety output
2c: CROUT instruction linked to 2a and 2b. Or again, if I have 5069/1756/CIP safety outputs, a simple AOI that also takes care of the I/O checking from 2a

2b takes care of your issue above. I generally create separate safety programs for each safety zone, each more or less following the structure above. Of course there are always little things here and there that end up different (locking guards, zero speed monitoring, and so on), but I generally put everything into more or less that structure.

 

[robertmee]

Yes, I've seen that. It also happens going from Program Mode to Run Mode.

The way my safety programs are (usually) structured is:
1: Safety inputs routine
1a: Generate falling edge reset from safety input, after checking status of input
1b: safety input checking and DCS instructions for all safety input devices (or, if I'm using 5069/1756 safety I/O, a single AOI of my own creation that has a DCS inside and also does the safety input checking for me)
1c: summary OTE of safety input devices (e.g. all e/stops healthy, all guards healthy, etc)

2: Safety outputs routine
2a: safety input and output status checking for each safety output
2b: "actuate" rung for each safety output (usually uses the "all e/stops healthy" and "all guards healthy" from 1c). Programmed as a simple hold-in circuit with the falling edge reset from 1a, and drops out if the .FP is active for the corresponding safety output
2c: CROUT instruction linked to 2a and 2b. Or again, if I have 5069/1756/CIP safety outputs, a simple AOI that also takes care of the I/O checking from 2a

2b takes care of your issue above. I generally create separate safety programs for each safety zone, each more or less following the structure above. Of course there are always little things here and there that end up different (locking guards, zero speed monitoring, and so on), but I generally put everything into more or less that structure.

I have the FP in the actuate, bit still experience the problem. But yeah, I do almost everything you said exactly.