Sicherer Eingang im Prozess nutzen

[Lipperlandstern]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo liebe Kollegen.

Spricht irgendetwas dagegen das ich einen Sicheren Eingang (in diesem Fall von einem Sicherheitslichtgitter) in meinem Prozess als "normale" Lichtschranke nutze.

Meiner Meinung sollte das kein Problem darstellen aber ich hab keine Ahnung was in den tiefen der Norm so versteckt ist.

 

[SPSAlex83]

Moin Lipp,

du meinst, dass du neben der Sicherheitstechnischen Auswertung dieses Signal auch zum Verarbeiten in deinem normalen Programmbereich nutzen kannst?
Sollte gehen.

VG

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Meiner Meinung sollte das kein Problem darstellen aber ich hab keine Ahnung was in den tiefen der Norm so versteckt ist.

Da spricht meiner Meinung nach nichts dagegen ( und ist ja auch nicht unüblich ). Die Vorgehensweise ist halt wichtig.
Schau mal hier ab Seite 28:

Programmierleitfaden Safety für SIMATIC S7-1200/1500

 

[Lipperlandstern]

Moin Lipp,

du meinst, dass du neben der Sicherheitstechnischen Auswertung dieses Signal auch zum Verarbeiten in deinem normalen Programmbereich nutzen kannst?
Sollte gehen.

VG

Das es geht ist klar. Aber spricht irgendetwas dagegen ?

 

[Lipperlandstern]

Da spricht meiner Meinung nach nichts dagegen ( und ist ja auch nicht unüblich ). Die Vorgehensweise ist halt wichtig.
Schau mal hier ab Seite 28:

Programmierleitfaden Safety für SIMATIC S7-1200/1500
Anhang anzeigen 72547

So gehe ich vor um die Daten auszutauschen. So weit so klar.

Den Eingang der Sicherheitslichtschranke wollte ich jetzt direkt im Standartprogramm nutzen.

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Den Eingang der Sicherheitslichtschranke wollte ich jetzt direkt im Standartprogramm nutzen.

Leider steht im Safety Programmierleitfaden nichts dazu. Also nicht dass es ok ist, aber auch nicht, dass es nicht ok ist.
Der Compiler akzeptiert den lesenden Zugriff eines fehlersicheren Eingangs im Standard-PRG ohne meckern.
Komischerweise schluckt der Compiler sogar einen schreibenden Zugriff im Standard-PRG auf einen
sicheren Eingang ( es kommt nur eine Warnung ). Wobei dann die CPU auf STOP gehen wird wegen Datenverfälschung.

Ich kann es dir nicht sagen.

 

[Botimperator]

Grüße aus den Schulungsunterlagen des TIA-Safety Lehrgangs.
Die Tabelle bezieht sich auf direkten Zugriff aus dem Code auf die Peripherie.
Brauchst nicht über die Austausch-DBs des Safety-Programms gehen.

 

[DeltaMikeAir]

Gerade gefunden ( Seite 185 ):
SIMATIC Safety - Projektieren und Programmieren

 

[maxder2te]

Zuviel Werbung?
-> Hier kostenlos registrieren

So gehe ich vor um die Daten auszutauschen. So weit so klar.

Den Eingang der Sicherheitslichtschranke wollte ich jetzt direkt im Standartprogramm nutzen.

Das kannst du schon machen, aber dir muss klar sein dass der Eingang der Sicherheitslichtschranke in einem anderen Prozessabbild liegt und sich während dem OB1-Durchlauf ändern kann.

Wenn ich sowas mache dann im PreSafety oder Postsafety Programm.

 

[MFreiberger]

Moin,
ich würde das Signal (wie ich es auch tatsächlich mache, wenn ich sowas programmiere), den (F)-Eingang auf ein (Standard)-Koppelbit legen und damit im Standardprogramm weiter arbeiten.
Ich würde den (F)-Eingang nicht direkt im Standardprogramm abfragen.
Ich habe mir angewöhnt, eine Koppel-DB für Standard => Failsafe und einen für die Gegenrichtung anzulegen. Beides Standard-DBs. Das halte ich auch konsequent ein.
Immer, wenn ein Baustein geändert und geladen werden soll, der irgendwie auf Failsafebereiche (auch Eingänge) referenziert, will TIA das F-Programm neu übersetzen und die Steuerung in Stopp schicken.
Ua. deswegen bin ich da bei der Signaltrennung so strikt.

VH

 

[ducati]

Immer, wenn ein Baustein geändert und geladen werden soll, der irgendwie auf Failsafebereiche (auch Eingänge) referenziert, will TIA das F-Programm neu übersetzen

incl. neuer Checksumme? Dann wär das ja der offizielle Grund, sowas garnie zu machen...

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

ich würde das Signal (wie ich es auch tatsächlich mache, wenn ich sowas programmiere), den (F)-Eingang auf ein (Standard)-Koppelbit legen und damit im Standardprogramm weiter arbeiten.

Für einen regulären Signalaustausch (Zustände) habe ich das auch schon so gemacht - aber nicht mit F-Inputs. Die Zustandsmeldungen waren dann aber meißtens ins F-Programm hinein ...

Immer, wenn ein Baustein geändert und geladen werden soll, der irgendwie auf Failsafebereiche (auch Eingänge) referenziert, will TIA das F-Programm neu übersetzen und die Steuerung in Stopp schicken.

Das kennen ich nur wenn an einem der F-Bausteine irgendwas geändert wird - wenn ich einen F-Input im Standard-Programm verwende hat das doch überhaupt keinen Sinn ...

@Lipperlandstern : zu deiner Frage : warum sollte das nicht gestattet sein. Denk doch mal an einfache Verriegelungen zum Abschalten eines Ausgangs oder noch simpler an einen Leuchtmelder bei z.B. Not-Stop.

 

[rostiger Nagel]

Ich würde den (F)-Eingang nicht direkt im Standardprogramm abfragen.
Ich habe mir angewöhnt, eine Koppel-DB für Standard => Failsafe und einen für die Gegenrichtung anzulegen. Beides Standard-DBs. Das halte ich auch konsequent ein.
Immer, wenn ein Baustein geändert und geladen werden soll, der irgendwie auf Failsafebereiche (auch Eingänge) referenziert, will TIA das F-Programm neu übersetzen und die Steuerung in Stopp schicken.

Ich nutze auch die Koppel-DBs, allerdings frage ich
für Meldungen die F-Eingänge direkt im Standardprogramm ab.
Der Grund ist, das ich die F-Programme „Knackig und Kurz“ halten
will, da kommt nur das wirklich notwendige rein.

Das mit dem F-Programm übersetzen und einen Stop beim übertragen,
bei Abfragen des F-Eingangs ist mir nicht bekannt. Nur wenn du den F-Eingang
selber anpackst zb die Adresse änderst, dann muss man das übersetzen und übertragen.

 

[DeltaMikeAir]

Das mit dem F-Programm übersetzen und einen Stop beim übertragen,
bei Abfragen des F-Eingangs ist mir nicht bekannt.

Ist das evtl. abhängig von der TIA Version?

 

[rostiger Nagel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ist das evtl. abhängig von der TIA Version?

Ich probiere es Montag noch einmal aus.

 

[Botimperator]

Ist das evtl. abhängig von der TIA Version?

Ich hab TIA-Safety bisher nur mit V16 & V18 gemacht.

Bei beiden Versionen war das Verhalten immer:
Das F-Programm (=>SPS-Stop) wird nur geladen wenn etwas geändert wurde, dass die F-Gesamtsignatur beeinflusst.

TIA fragt manchmal nach dem F-Passwort, auch wenn nichts am F-Programm geändert wurde.
Z.B. wenn du auf "Software komplett übersetzen" gehst.
Solange man nichts an den oben genannten F-Bereichen ändert kommt immer die gleiche F-Gesamtsignatur raus.
F-Gesamtsignatur online = offline => F-Programm wird nicht geladen.

Dazu aus den Siemens-Schulungsunterlagen:


Habs eben auch nochmal mit V18 & einer 1513F-1 PN, V2.9.7, ausprobiert.
Aufrufen von F-DI im Standard-Anwenderprogramm erfordert kein Neu-Übersetzen des F-Programms, also auch kein Laden.

 

[Windoze]

Ich greife auf alle Safety-Signale von Standard-Programm zu ohne sie umzurangieren (In der Umgekehrten Richtung habe ich einen Koppel-DB).
Habe noch nie deswegen die Safety neu Übersetzen oder Laden müssen. Ich nutze Hauptsächlich TIA v15.1