Guardlogix - Qualifying standard bits in safety task

[plccontrols]

I have been searching for more information regarding qualifying standard tags in a safety task and all I have found is a quick excerpt in one of the Guardlogix manuals (see attached).

It looks to me that programming in this way will create a situation where, if the standard tag(s) to the left of the one shot become true before the qualifying safety tag(s) to the right of the one shot, there will be a hang up. Unless these safety tag(s) are also routed back to the standard program and included as permissives for the standard tag being qualified (redundant), I don't see a way around this. Am I missing something?

 

[kamenges]

No, I don't think you are missing anything. This same situation would apply to any logical construct similar to what is shown regardless of the data source. The one good thing is the STATE of any safety data can be freely evaluated in the standard program without mapping (assuming they are controller scope tags). You just can't set their value anywhere but in the safety task. So logical permissives using safety tags are pretty easy to implement.

Keith

 

[mk42]

The big advice that i've always heard regarding standard bits in the safety program is that they can be ADDITIONAL requirements on top of the safety bits, but should essentially never route around safety. As long as the safety bits can turn off the logic, the standard bits won't make things unsafe.

You could, perhaps, use a standard bit to select between two safety functions, or in the example you show, use a safety bit as a gatekeeper (Estop_OK or whatever) to the command from the standard program.

That said, yes, also, most safety logic shouldn't allow a system to start automatically without some kind of reset. The rising edge detection is one way to do that, I've also seen logic with literal reset bits that need to pulse before the start command is accepted. It is also typical to disable process logic when safety faults, to prevent exactly that.



My experience is more on the Siemens side than the AB, but I think the logic still holds.

 

[JeremyM]

Realistically, something like a general reset pushbutton (standard IO, not a safety circuit, nor does it need to be) would be the kind of thing mapped to a safety tag. This would enable resetting tripped or faulted safety blocks, which are already coded to work on rising edges (preventing something like a held reset signal). It's just about the only thing I've mapped to safety tags. Maybe some added diagnostic feedback to qualify resettable conditions for the blocks, but that's always case-by-case.

In the standard scope of things, safety stuff would be used in read-only fashion to serve as interlock/permissive conditions. This has been always been another spot where using program-scoped public/output parameters work really well at keeping things organized and easy to service.

 

[plccontrols]

Thank you all for the replies. The project I'm working on has quite a convoluted control system and judging by the way it was previously programmed in a similar machine, in another brand controller, standard tags appear to be used directly in safety FBs. I'm going to discuss further with the customer.

 

[joseph_e2]

I'm in the early planning stages of a safety application in a Compact GuardLogix PLC. The machine is just complex enough that I need to have both safety and standard inputs be able to turn off a motor. That means the motor control needs to be safety outputs controlled in the safety routine, but it's not necessary (or cost-effective or possible in come cases) to replace the standard inputs with safety-rated devices. Since the standard inputs are things that don't affect personnel safety, they don't have to be safety-rated or redundant. I'll be mapping those into the safety routine. As has been mentioned before, be very careful that the safety signals ALWAYS control the hazards, regardless of the state of the standard signals.