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])?
Parameterization in Run (PiR): Benefits and Logic of Safe State
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).