Step 7 Datenverfälschung im Sicherheitsprogramm bei CPU 317-TF

[Blackmike]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich tippe bei dir auch auf den Taktmerker.

Die Taktmerker sind Asynchron zum CPU Zyklus.

Wenn dein Sicherheitsprogramm aufgerufen wird und sich während des ABlaufs des Sicherheitsprogramms der Taktmerker nicht ändert, ist alles OK.

ABER

Sollte sich zufällig während des Ablauf des Sicherheitsprogrammes der Zustand des Taktmerkers verändern, bekommst du das beschriebene verhalten.

(genauso böse wäre das, wenn du im Sicherheisprogramm einen Merker benutzt (nur lesen reicht da), und in einer höherprioritären OB Ebene wird das Sicherheitsprogramm unterprochen und der Merker verändert... ok, wäre auch ein bitchy Programmierstiel, aber letztlich der gleiche Effekt.

Lösung mi deinem Taktmerkerproblem:
Vor Aufruf der Ablaufgruppe in dem OB umkopieren des Taktmerkerbytes in einen anderes merkerbyte und diesen neuen Merker dann im Sicherheitsprogramm verwenden.

gruss,

Black

 

[Eraser]

Ja das habe ich jetzt gemacht und schaue mal die nächsten Tage, ob dieser Fehler nochmals auftritt.

Wie sieht es jetzt mit den F-DB's aus, z.B. DB1000 bei mir. Darf ich diese im normalen Programm abfragen oder kann es da auch Komplikationen geben?

Danke an alle für die Hilfe!

mfg

 

[Blackmike]

Zuviel Werbung?
-> Hier kostenlos registrieren

du darfst FDB aus dem Sicherheitsprogramm im Standartprogramm abfragen, sooft du willst und es die Zykluszeit zulässt ^^

Ebenso darfst du auch FDI im Standartprogramm lesen. Allerdings bitte nicht im Standardprogramm versuchen, auf FDO´s schreibend zuzugreifen ^^, aber das sollte klar sein, denk ich mal.

Gruss, Black

 

[Eraser]

Das mit den F-DO schreiben ist klar

Wollte nur auf Nummer sicher gehen wegen den DB's lesen. Machen das schon länger so und gab bisher keine Probleme, aber sicher ist sicher...

Thx

 

[Matze001]

Ausnahmen bestätigen die Regel!

F-DBs lesen geht mit TIA V13 SP1 nicht mehr und wird angemeckert Ob das nun ein Fehler ist oder gewollt ist?
Vor allem ist die Fehlermeldung sehr toll "Ein Baustein wird in mehreren F-Ablaufgruppen verwendet". TIA macht aus einem FC oder FB der auf die DBs zugreift dann einen gelben und motzt.

Grüße

Marcel

 

[rostiger Nagel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Diese Lampe ist in einem beleuchteten Taster eingebaut, der wiederrum der Quittiereingang der Safety ist.
Wenn jetzt z.B. eine Schutztür geöffnet wurde, muss man nach dem Schliessen der Schutztür ja mit dem Quittiereingang der Safety mitteilen, dass jetzt quittiert wurde (F_SFDOOR-Baustein).
Und so blinkt jetzt automatisch der Knopf, wenn irgendwas geöffnet oder etwas noch nicht quittiert wurde. Ist leichter zum Bedienen, da man gleich erkennt, wenn der Taster blinkt, draufdrücken bis er ausgeht.

Wenn es nicht gerade eine Mutinglampe ist, hat so etwas absolut nichts, in einem F-Programm zu suchen.
F-Programme sollen so schlank wie eben möglich sein, wenn ich meinen Siemens F-Fachberater richtig
in Erinnerung habe. Mir entschließt sich jegliche Begründung, warum eine normale Signallampe, so angesteuert
werden muß.

 

[Eraser]

Wenn ich sie mit einem normalen Ausgang ansteuern würde, müsste ich:

-) Eine eigene Ausgangskarte dafür dazu bauen, welche mit der 24V-Versorgung der Eingangsspannung und nicht der Ausgangsspannung versorgt wird
-) Die ganzen Safety-DB-Zugriffe von den Schutztüren wieder im normalen Programm machen, was dann meiner Meinung nach die Übersichtlichkeit der Programmierung seht zerstört.
So ist jetzt die ganze Programmierung bezüglich Not-Aus, Schutztüren, Lichtvorhang, Schutztürüberbrückung und die ganzen STO, SOS, SLS, SS1, SS2, usw. im Safety-Programm in einem Baustein beisammen.

Im Endeffekt ist es nur ein Netzwerk und ich denke nicht, dass es der F-CPU das Genick bricht
Aber du hast schon recht, es sollte kein unnötiger Mist drin sein...

 

[rostiger Nagel]

neh es geht dann schon eher um die Sicherheitsbetrachtung, du musst es Validieren und Dokumentieren.

 

[Blackmike]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ausnahmen bestätigen die Regel!

F-DBs lesen geht mit TIA V13 SP1 nicht mehr und wird angemeckert Ob das nun ein Fehler ist oder gewollt ist?
Vor allem ist die Fehlermeldung sehr toll "Ein Baustein wird in mehreren F-Ablaufgruppen verwendet". TIA macht aus einem FC oder FB der auf die DBs zugreift dann einen gelben und motzt.

Grüße

Marcel

hmmm, vllt stimmt da bei dir irgendwas nicht mit der Installation... Also ich hab an meinen Anlagen immer einen Standart FC, der die Peripherie F_DB´s ausliest und die Daten umschreibt in einen Standart DB, dann ein bisschen aufbereitet, damit in der Visu schon eine Diagnose des F-Teils möglich ist. (Passivierung Kanalfehler und Diagnosebyte)

und bei mir geht das unter V55, V13 und V13 SP1.

gruss, Black

 

[SPS_Admin]

Servus,

beim zweiten Problem kann ich dir schon mal helfen, du hast sicherlich in der Hardware bei den Sicherheitsparameter "Passivieren der gesamten Baugruppe" ausgewählt.
Es muss aber Passivieren des Kanals angewählt werden wenn du nicht die ganze Baugruppe auf Störung gehen lassen willst (siehe Anhang)!

Zu deinem ersten Problem:

Bei mir kam es einmal vor das ich eine falsche GSD verwendet habe und mir das nicht angezeigt wurde, normalerweiße bekommst du ja in der Hardware eine Fehlermeldung.
Kontrolliere mal deine ganzen GSDs auf Richtigkeit!

mfg

 

[Eraser]

Das ist ja aber nur das Verhalten bei Kanalfehlern, welche ich aber nicht habe (Safety-Verkabelung ist OK), da ohne weitere Karten nach der F-DI alles einwandfrei funktioniert.
Das mit dem Passivieren der gesamten Baugruppe hat aber leider nichts damit zu tun, dass die ganze Station so auf Störung geht, dass die Karten dann nicht einmal mehr erkannt werden.

mfg