TIA Sicherheitsausgänge (F-Technik) unsicher überbrücken?

[Geisterkarle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

aktuell bin ich so böse und überbrücke zur Inbetriebnahme in meinem Sicherheitsprogramm einige Schutzkreise mit unsicheren DB-Variablen, um Sichere Ausgänge zu schalten.
Eigentlich mache ich das schon länger bei Projekten so, allerdings meist mit Merkern und nicht mit DB-Variablen. Und ich weiss nicht, ob das schuld ist, aber aktuell schiesse ich meine CPU (Soft-CPU 1507S-F) desöfteren beim Umschalten (also wenn ich den Status meiner unsicheren Werte ändere) in Stopp! Fehlermeldung laut Onlinediagnose:

Fehler: Sicherheitsprogramm: Datenverfälschung vor Ausgabe an F-Peripherie
F-Ablaufgruppe   1
Anfangsadresse der F-Peripherie:      10462
Offset des Ausgangs:   0
 Software PLC / Software PLC.

Was natürlich etwas uncool ist!

Hat da wer tiefere Erfahrungswerte beim überbrücken von Sicherheitsausgängen, woran das liegen könnte? Gehen Merker vielleicht besser als DBs?
Oder fallt ihr gerade vom Stuhl, weil ich sowas mache?

Für Tipps Dankbar!

 

[acid]

Das Problem ist, wenn du per Beobachtungstabelle oder wie auch immer ein Bit in deinem Inbetriebnahme-DB änderst, während das F-Programm gerade abgearbeitet wird, dann kann es zu dem beschriebenen Fehler kommen. Aus dem gleichen Grund dürfen im Sicherheitsprogramm keine Taktmerker verwendet werden, da sich diese während der Abarbeitung ändern können.

Du könntest beispielsweise einen zweiten DB mit identischem Inhalt erstellen und am Anfang des OB1 den Inhalt von DB1 in den DB2 kopieren, im F-Programm arbeitest du dann mit den Variablen aus dem zweiten DB.
Der Weckalarm des Sicherheitsprogramms unterbricht ja den zyklischen Programmablauf, es ist dann nicht möglich, dass sich Daten in dem zweiten DB ändern, während das F-Programm abgearbeitet wird.

Ob man das so machen sollte musst du selber bewerten, ich kenne deine Anlage und die Gegebenheiten ja nicht.

 

[Howard]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin!
Grundsätzlich sollte das F-Programm auf jeder IBN als erstes fertig sein, damit wir alle nicht wieder lesen müssen, dass es einen weiteren Kollegen zerrissen hat.

Wenn gewisse sicherheitstechnische Einrichtungen vor Ort noch fehlen (z.B. ein Not-Aus), dann überbrücke ich den Eingang dauerhaft mit ODER "Always True".
Das ODER wird dann nach Einbau der Hardware entfernt und vor der Validierung wird das F-Programm nach vielleicht vergessenen "Always True"-Merkern durchsucht.

Wenn du nun aber irgendwelche NICHT dauerhaften Tests im Safety durchführen möchtest, gibt es im TIA in der Safe-Administration dafür die Möglichkeit unter "Allgemein" den "Sicherheitsbetrieb" zu deaktivieren (bleibt bis Stopp->Run-Übergang aktiv). Solange der Sicherheitsbetrieb deaktiviert ist, darf man dann auch Merker oder DB-Einträge im F-Teil umsteuern ohne das die CPU auf Stopp geht.

 

[Geisterkarle]

Das Problem ist, wenn du per Beobachtungstabelle oder wie auch immer ein Bit in deinem Inbetriebnahme-DB änderst, während das F-Programm gerade abgearbeitet wird, dann kann es zu dem beschriebenen Fehler kommen. Aus dem gleichen Grund dürfen im Sicherheitsprogramm keine Taktmerker verwendet werden, da sich diese während der Abarbeitung ändern können.

Ah! Das könnte tatsächlich sein!
Denn ich setze die Bits tatsächlich per Beobachtung oder HMI (was vermutlich gleiche Auswirkungen hat)! Müsste ich mal umstricken hier...

@Howard:
genau sowas mache ich im Normalfall auch. Diese merker sind auch feststehend, da wird nie was geändert. Habe hier mal nen "speziellen" Fall, wo ich Sicherheiten abhängig an- und ausschalten will! Auch mit Inbetriebnahme-VKEs, aber halt änderbar!

 

[acid]

Ah! Das könnte tatsächlich sein!
Denn ich setze die Bits tatsächlich per Beobachtung oder HMI (was vermutlich gleiche Auswirkungen hat)! Müsste ich mal umstricken hier.

Korrekt, es ist egal, ob du das Bit beim Beobachten änderst oder im HMI, auch das HMI kann bei der 1200/1500 zu irgendeinem Zeitpunkt die Daten in die Steuerung schreiben und zu diesem Verhalten führen.