PROFINET Forum

Question from the PROFIsafe Designer Workshop in October 2023:

Did I understand it correctly that you cannot "circumvent" the "safe state" [editor's note: i.e., externally ensuring the safety of the part of the machinery/plant that is affected by the F-Device on which PiR is performed]? What is the benefit of PiR then? May the F-Device leave the "FS_activated" state and later on (re-)starts delivering process values (within watchdog time 2 [F_WD_Time_2])?

PS-cE wrote: ↑13 Nov 2023, 14:10 Question from the PROFIsafe Designer Workshop in October 2023:

Did I understand it correctly that you cannot "circumvent" the "safe state" [editor's note: i.e., externally ensuring the safety of the part of the machinery/plant that is affected by the F-Device on which PiR is performed]? What is the benefit of PiR then? May the F-Device leave the "FS_activated" state and later on (re-)starts delivering process values (within watchdog time 2 [F_WD_Time_2])?

The external monitoring of the safety of the affected machinery/plant part has to be performed because during PiR, the F-Device will not perform its usual functionality, i.e., delivering current process values.

The F-Device does not go into the safe state (FV_activated) on a logical level. It holds the last output value, which is then also held on the F-Host's side as input value. So the process values are "frozen" during PiR.

On a technical level it is true that the F-Host sets FV_activated:=1 for the first three communication cycles when restarting communication after re-parameterization, but this is to respect the PROFIsafe protocol which expects this.

Especially in Process Automation, production processes have high inertia, so it makes much more sense to perform a (relatively short) PiR process than to stop and restart production (which could take hours or even days).