Fehlersicherer Ausgang schaltet CPU in Stopp

[yy1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Hardy81,

kann es sein, dass Du irgendwo im Standard-Programm auf den F-DB zugreifst?
Hast Du schon die Funktion 'Auf Zugriffe vom Standard prüfen' ausgeführt (Sicherheitsprogrammdialog -> Generieren -> Auf Zugriffe vom Standard prüfen)?

 

[Hardy81]

Ja es gibt Zugriffe vom Standardprogramm auf den F-DB.

Darf das nicht so sein?


Diese Zugriffe, egal ob schreibend oder lesend, haben aber nichts mit dem Ausgang zu tun.

 

[Hardy81]

Zuviel Werbung?
-> Hier kostenlos registrieren

Was ich im Diagronepuffer noch rauslesen kann ist, dass es sich um den Ausgang 32.1 handelt.

Nur leider wandert der Fehler mit. Spreche ich den A32.0 an, dann steht der mit der gleichen Fehlermeldung im Diagnosepuffer drin.

Kanalfehler bekomme ich keine angezeigt. Bei der F-DO Karte und der IM ist alles schön. Keine Fehler.


Gibts irgendwo ne Zusammenstellung wie man Daten ins Sicherheitsprogramm reinbringt und wie Daten "richtig" rauskommen dürfen?


Ich hab die HW-Config mal als Projekt in den Anhang gepackt. Vielleicht kann man darüber noch was rausfinden.

 

[Deltal]

Uhh nen F-DB darfste natürlich nicht beschreiben!

Also Kommunikation zwischen F und ST Programm kannst du Merker benutzen (Achtung keine Taktmerker!). F-DPs darf man im ST lesen, aber nicht schreiben. F-Ausgänge kann man auch im ST lesen, aber nicht schreiben.

 

[maxpapa]

hi ,
hast Du in dem F-Baustein ,wo die Ausgänge beschrieben werden eventuell Deine Lokaldaten (Schnittstellenparameter IN,OUT,TEMP)
nicht initialisiert?
Lt.Programmier- und Bedienhandbuch für "S7-Distributed Safety" steht unter
Kapitel 4.1 - Übersicht Programmieren/S4-12:Operandenbereich Lokaldaten

Beachten Sie bei der Verwendung des Operandenbereichs Lokaldaten, dass der erste Zugriff auf ein Lokaldatum in einem F-Pb/F-FB/F-FC immer ein schreibender Zugriff sein muss, mit dem das Lokaldatum initialisiert wird.
...
Bei Nichtbeachtung kann die F-CPU in STOP gehen. Im Diagnosepuffer der F-CPU wird dann eines der folgenden Diagnoseereignisse eingetragen:
* "Datenverfälschung im Sicherheitsprogramm vor Ausgabe an F-Peripherie"


gruß maxpapa

 

[yy1]

Zuviel Werbung?
-> Hier kostenlos registrieren

hi ,
hast Du in dem F-Baustein ,wo die Ausgänge beschrieben werden eventuell Deine Lokaldaten (Schnittstellenparameter IN,OUT,TEMP)
nicht initialisiert?

Bei fehlenden Initialisierungen sollte eigentlich eine Warnung beim Generieren des F-Programms ausgegeben werden.
Wird aber im Standard schreibend auf F-DB oder Ausgang zugegriffen, wird das nur über die Zusatzfunktion 'Zugriffe vom Standard prüfen' angezeigt (wobei aber teilqualifizierte/indirekte Zugriffe nicht erkannt werden).

 

[Hardy81]

Also wenn ich den F-DB nicht beschreiben darf von "außen" heißt das im Klartext:

Die Daten, die in den F-DB rein sollen im F-Programm einlesen (von der nicht sicheren Seite) und dann in den DB schreiben.


Lokaldaten werden keine verwendet. Von daher schließe ich das schon mal aus.

 

[yy1]

Die Daten, die in den F-DB rein sollen im F-Programm einlesen (von der nicht sicheren Seite) und dann in den DB schreiben.

Genau, das Standard-Programm darf keine schreibenden Zugriffe auf den F-DB haben.
Wenn es sich hier um unsichere Daten handelt, müssen diese im F-Programm in den F-DB übernommen werden.

 

[Deltal]

Zuviel Werbung?
-> Hier kostenlos registrieren

Denke auch daran, das alle Daten die vom ST Teil kommen, NICHT für Sicherheitsfunktionen genutzt werden dürfen.
So kann ein Merker z.B. für den Reset einer Lichtschranke genutzt werden, aber nicht um das Eingangsbit des Lichtschrankenbausteins zu überschreiben.

Ich nutze immer so wenig Merker wie möglich, für den Reset würde ich z.B. lieber direkt den Eingang abfragen.


Warum du keine F-DBs aus dem ST Teil beschreiben darfst, erklärt sich wenn du dich mal folgendes fragst:
Wie stellt die S7 sicher, dass meine Daten in einem F-DB konsistent sind? Immerhin werden in einem F-DB sicherheitsrelevante Daten gespeichert!

 

[Hardy81]

Dann werd ich das Programm mal dahingehend umbauen, dass ich nur noch lesend auf das F-Programm zugreife.


Wenn sich der Ausgang dann immer noch nicht schalten lässt werd ich irre :x

Doof, wenn man nicht so die Erfahrung mit Safety hat und dann eine Anlage von einem Programmierer übernimmt der den Sicherheitsteil "verbockt" hat.


Schon mal ein Dankeschön für die Tipps.

Ich melde mich nochmal, wenn ich Erfolge habe. Aber auch, wenn nicht.

 

[bike]

Dann werd ich das Programm mal dahingehend umbauen, dass ich nur noch lesend auf das F-Programm zugreife.


Wenn sich der Ausgang dann immer noch nicht schalten lässt werd ich irre :x

Doof, wenn man nicht so die Erfahrung mit Safety hat und dann eine Anlage von einem Programmierer übernimmt der den Sicherheitsteil "verbockt" hat.


Schon mal ein Dankeschön für die Tipps.

Ich melde mich nochmal, wenn ich Erfolge habe. Aber auch, wenn nicht.

Du kannst sehrwohl Daten zwischen Standard und F_Programm austauschen.
Also ich quittiere Lichtschranken mit normalen Eingängen, warum auch nicht?
Wenn die Sicherheit nicht okay, kannste quittieren wie du willst, und geschieht nichts.
Also bei mir funktioniert der Datenaustausch zwischen Standard CPU und F-CPU über das Laden der Eingänge und transferieren in den Safe DB.
Und auch in der anderen Richtung ;-)

Ich würde mal die Dokumentation von BigS lesen und da steht einiges und sogar wie richtig funktioniert.


bike

 

[Deltal]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie ich schon geschrieben habe, kannst du sogar Merker nutzen, und das in alle Richtungen.

Ich hatte aber auch schon Programme gesehen wo so ein Merker im "sicherheitsrelevanten" Pfad eingebunden. Der Editor zeigt dir ja auch ziemlich deutlich an, welches Signal "sicher" und welches es nicht ist..

Ich sehe es kritisch, dass es wohl Programmierer (bzw. es fängt ja auch schon bei den Verkäufern an) gibt, die den Punkt "Sicherheitssps" im Pflichtenheft einfach so hinnehmen ohne sich große Gedanken zu machen. Das ganze ist doch schon etwas mehr, als das man ein paar "gelbe E/A Karten" dazubastelt.
Naja ich würde halt kein Abnahmeprotokoll unterschreiben wenn ich nicht genauestens wüsste was da im F-Programm passiert.

 

[Hardy81]

So, hab nun alles über Merker ins sichere Programm eingelesen (im sicheren Baustein).

DB wird also nur noch über sichere Bausteine geschrieben...


Und es funktioniert!


Danke nochmal an alle für die Tipps.