Guardlogix Help

Hello!

I am using guardlogix first time and i have some queries.There are 2 areas Main program and safety task.So, Main area is just like controllogix area.

What i have understand that safety task area is actually in case of failure that safety task shall be priority task for partner.
Off course it will be keep running in normal operation.Right?
Second SIL3 system should have safety task to prevent any failure.

But now come to my system.There is no redundancy at all for both PLC(1756-L81ES) and IOs(Point IOs).

I have only DIs and DOs where DIs act as Causes and DOs as Effects.I have developed everything in the safety task area from IOs mapping to Cause and effect.

My question is it ok to keep everything in safety task?Or I should keep IO mapping in standard/Main area and create cause and effect in safety task?

Are they safety point IO, or regular point IO?
Any safety function should be programmed entirely in the safety task.

Safety PLC is different to redundant PLC. With redundant PLC, if one PLC fails, the other one takes over and keeps the process running. With safety PLC, they both run the same code, then compare their results. And if their results disagree, they assume a hardware fault and put outputs to safe state.

Sure, there are redundant safety PLCs, but the GuardLogix is not one.

These are safety Point IOs and Safety PLC 1756-L81ES with no partner

I mean whether logic in normal main program or safety task.So, is it really effective in that specific case?

But, I believe i should keep everything in Safety task as Standard logic cant write on safety output.

obi1987 said:

These are safety Point IOs and Safety PLC 1756-L81ES with no partner

I mean whether logic in normal main program or safety task.So, is it really effective in that specific case?

But, I believe i should keep everything in Safety task as Standard logic cant write on safety output.

Click to expand...

You won't be able to put safety logic or write to safety outputs in the normal program, you have to use the safety task.

Normally everything that would be in your safety relay would slot into the safety task.

You can only read safety tags in the normal program, which, for example you would bring a drive to a controlled stop before your safety delayed outputs are turned off.

You can map standard tags to safety tags for use in the safety routine, for example a reset PB, but everything safety related is in the safety routine.

Redundancy is a different kettle of fish entirely.

Thanks.I have got it.
Actually, I have already implemented everything(IO Mapping ,C&E) in safety routine.
It wouldn't be any issue?

obi1987 said:

Thanks.I have got it.
Actually, I have already implemented everything(IO Mapping ,C&E) in safety routine.
It wouldn't be any issue?

Click to expand...

Depends on your risk assessment. More logic in the safety task causes longer cycle time of the safety task. Longer cycle time means longer response time. Longer response time means larger safe stop distances.

Thanks.
Ok, I will look in it.

Seems not having the safety partner limits the SIL or PL of your system.

Without the safety partner you only get a SIL2 rating. Place all of your safety functions in the safety routine. Example estops, safety gates, safety relays. Your general logic goes in the main routine. Ie motor start/stops non safety limit switches. You always have more memory in the main routines and the more logic you have the longer your scan times get. I read the safety inputs in the general logic to force my drive run commands off. So not only are the drives being turned off through the safety relay wired to the safe start contacts in the drive but it is unlatching the run command on the software side.

AustralIan said:

Seems not having the safety partner limits the SIL or PL of your system.

Click to expand...

You are correct. Without the safety partner controller, the best you can get is SIL2 PLd.

The SIL safety ratings are not based solely on having a safety PLC, but the entire system design as a whole. Dual channel safety intputs running into a safety IO card with a safety rated parnter PLC, other wiring considerations, failover redundancy, safety signature control, etc all affect how one can determine the SIL safety factor.