# Fehlersicherer Ausgang schaltet CPU in Stopp



## Hardy81 (16 September 2011)

Hallo zusammen, hab da mal folgendes Problem, bei dem ich nicht mehr weiter weiß:

Ich habe ne S7-315F-2DP mit sicheren EAs in einer Anlage drin. 

Versuche ich nun einen sicheren Ausgang zu schalten, dann schaltet die CPU direkt in Stopp mit der Meldung: 

Datenverfälschung im sicherheitsprogramm vor Ausgabe an F-Peripherie.


Die Siemens Hilfe gibt mir da zwar Anhaltspunkte aber die hab ich mitlerweile schon alle durch. 

Ausgang wird direkt im FC mit F-FUP zugewiesen. 

Also ungefähr: 

U DB300.DBX.X
U DB300.DBX.y
= A32.1

Der FC und der DB sind jeweils sichere Bausteine. Woran kann das noch liegen? Bin im Moment echt ein wenig ratlos. 

Darf ich sichere Ausgänge überhaupt so ansprechen? Hab da in der Hilfe was gelesen, dass es über die sicheren EA-DBs laufen soll ???


Wenn ich den Sicherheitsbetrieb deaktiviere funktioniert alles ohne Probleme. Wen wunderts auch? 

Die F-Ablaufgruppe wird im OB35 aufgerufen. 

Andere Ausgänge verhalten sich genauso. Also denke ich mal es liegt an der Art der Ansteuerung selbiger. 

Wäre toll, wenn mir da jemand mal auf die Sprünge helfen könnte. Ist echt dringend.


----------



## centipede (16 September 2011)

Kann es sein, dass du einen Ausgang ansprichst den du gar nicht ansprechen darfst?
Nicht alle Ausgänge der DO dürfen benutzt werden.


----------



## Deltal (16 September 2011)

z.B. eine 4 DO Baugruppe die mit 32 Addressiert ist, kannste schon mit A32.1 ansprechen..

Biste dir ganz sicher das nirgens sonst etwas auf A32.1 schreibt? z.B. über ein AW oder so?


----------



## Hardy81 (16 September 2011)

Als Karte ist eine FDO10xDC24V/2A (6ES7 326-2BF10-0AB0) verbaut. 

A-Adresse: 32-37
E-Adresse: 32-37

Wo liegen da jetzt die Ausgänge?

Ab A32.0 oder irre ich da?

Ist der A32.1 dann überhaupt richtig adressiert im Programm?

Doppelte Zugriffe gibt es keine. Das hab ich schon kontrolliert. War auch meine erste Vermutung.


Oder kann es vielleicht sein, dass es nicht geht, weil die Karte nicht direkt an der CPU hängt sondern über Profibus an einer IM153-2?


----------



## Deltal (16 September 2011)

Haste mal versucht das auf den A32.0 zu legen?

Wenn du den Ausgang nicht ansteuerst, dann läuft alles?


-> der FC wird über den F-Call aufgerufen?

Kannst mal versuchen alles ausm OB1 zu nehmen und nur den F-FC zu benutzen.


----------



## bike (16 September 2011)

Hast du schon versucht mit einem F_Baustein aus der F-Bibliothek den Ausgang anzusprechen?
Hast du das Programm nach dem Programmieren übersetzt?
Hast du einen F-Baustein angelegt in dem du den Ausgang beschreibst?


bike


----------



## Hardy81 (16 September 2011)

@Deltal: Umlegen der Ausgänge bringt nichts. Egal welchen Ausgang ich beschreibe, bei allen tritt der gleich Fehler auf. 

Der A32.1 kommt nur als erste, da er im Programm als erster Ausgang beschrieben wird. Zumindest der erste sichere Ausgang. 

Wenn der Ausgang nicht angesteuert wird, dann haut mir der nächste Ausgang die CPU in Stopp. 

Ich hab einen FC1000 (F-CALL). 
Dann gibts noch einen FC1001 (F_OB1). In diesem F_OB1 wird der Baustein aufgerufen, der mir den Ausgang schreiben soll. 


@Bike: Welchen Baustein benutze ich da? Hab nur welche für CFC gefunden. 

Ja, Programm wurde nach dem Programmieren übersetzt und neu übertragen. 

Ja, der Ausgang wird in einem F-Baustein (erstellt mit F-FUP) geschrieben.


----------



## bike (16 September 2011)

Hardy81 schrieb:


> @Bike: Welchen Baustein benutze ich da? Hab nur welche für CFC gefunden.



Wenn du Distributed Safety installiert6 hast, hast du doch unter Bibliothekenauch die für F-Steuerungen.
Da würde ich zum Test eine FB nehmen, z.B FB216, den beschalten und dann schauen ob die CPU auf stopp geht.


bike


----------



## rostiger Nagel (16 September 2011)

Wenn der F_Ausgang sich nicht mit Standard Zuweisungen 
ansprechen lässt brauchst du es erst garnicht mit
irgendwelchen Bausteinen aus der F-Biblothek versuchen,
die helfen da auch nicht. 
Eine direkte Zuweisung muss auch so Funktionären,
selbst mit einen nicht sicheren merker.


----------



## bike (17 September 2011)

Irgendwie muss man den Fehler einkreisen. 

Wenn es Fehler in der Konfiguration ist und ein Standardbaustein verwendet wird, wird schon beim Parametrieren aangezeigt was falsch ist.
Spätestens beim Übersetzen wird ein genauerer Fehler angezeigt.


bike


----------



## Deltal (17 September 2011)

Mache doch ein neues Projekt, nur mit dem Fcall und dem Aufruf des F-FCs.

Mich würde halt interessieren ob es am schreiben auf den Ausgang oder ob sich da ein genereller Fehler eingeschlichen hat.

Du wirst auch noch jede F-Baugruppe ansprechen müssen, z.B. um ein Bit aus dem Peripherie jeder Baugruppe auslesen.


----------



## Lupo (17 September 2011)

Mich würde es hier mal interessieren, wie der Ausgang in der HW-Konfig konkret konfiguriert ist. Des Weiteren auch noch was und vor Allem wie es an dem Ausgang angeschlossen ist. Das sieht mich doch eher nach etwas systematischen aus.


----------



## rostiger Nagel (17 September 2011)

Vielleicht hilft es auch mal in den F-Datenbaustein der Baugruppe zu schauen, 
dieser wird Automatisch vom System erstellt und müsste in etwa so heißen:
"F00032_SM_326.......".
Dort bekommst Informationen was mit dem entsprechenden F-DO los ist, 
genauer kannst du es mit dem SFC59/13 erfahren, lese dazu bitte die Handbücher
die in der Siemens Step 7 Dokumentation mit installiert werden.

Kann es eigentlich sein das du im F-Programm lesend auf dem F-DO zugreifst,
da meckert die F-CPU schon mal ein wenig.


----------



## Hardy81 (17 September 2011)

@Lupo: 







SO sind die Ausgänge alle konfiguriert. 


An den Ausgängen hängen Ventile dran. Genauer kann ich es jetzt im Moment auch nicht sagen. Müssen das spezielle Aktoren sein, oder reichen da 0-8-15 Dinger? Es muss doch nur der "richtige Strom" wieder in die Karte zurückgeführt werden. 


Die Ausgänge werden nicht lesen benutzt. Das hatte ich am Anfang schon geändert, weil ich dachte es kommt daher. 

Schreibe mir alle Eingänge und Ausgänge in einen DB und benutze dann dort die Bits. 

U Ex.y
= DBxx.dbxx.y

u irgendwas
= A32.0
= DBxx.DBXx.y

So schreib ich mir die EAs in den DB. 


Neues Projekt anlegen ist im Moment ein wenig schwierig. Die Anlage läuft schon und wir können nur am Wochenende abschalten um zu testen. 

Mir ist auch klar, dass wenn ich das Safetyprogramm nochmal neu generiere und übebrtragen will, dann geht das nur mit CPU Stopp. Also auch wieder nur am Wochenende bzw. in längeren Produktionspausen. 


Beim Generieren bekomme ich keine Fehler, keine Warnungen. 

Das mit dem SFC werd ich mal noch ausprobieren.


----------



## bike (17 September 2011)

Hardy81 schrieb:


> Beim Generieren bekomme ich keine Fehler, keine Warnungen.


Ob es hilft nach Fehlern mit SFC im Programm zu suchen, wenn  der Fehler schon beim Übertragen auftritt, sei dahin gestellt.

Wenn du auf die Schnelle schreibst, welche Komponenten verbaut werden, dann kann vielleicht jemand eine  Hardware sich bauen und ggF das einmal testen.

So unbekannt ist mir das Problem nicht und ich musste über DBSAFE.DBWSAFE die Ausgänge ansprechen.
Das war bei einer besonderen Hardware Konfig leider? nötig.


bike


P.S: Nein DBSAFE.DBWSAFEsind keien Siemensbezeichnungen, sondern sollen Platzhalter sein. ;-)


----------



## Hardy81 (18 September 2011)

Hier mal die Hardwarekonfig: 

CPU 315F-2DP (6ES7 315-6FF04-0AB0) Firmwarestand 3.0

über PB an dieser CPU hängen die Failsafe Komponenten:

IM153-2 (6ES7 153-2BA02-0XB0)

FDI24xDC24V (6ES7 326-1BK02-0AB0)
    E-Adresse: 60..69 - A-Adresse: 60..63

FDI24xDC24V (6ES7 326-1BK02-0AB0)
    E-Adresse: 70..79 - A-Adresse: 70..73

FDO10xDC24V/2A (6ES7 326-2BF10-0AB0)
    E-Adresse: 32..37 - A-Adresse: 32..37






> P.S: Nein DBSAFE.DBWSAFEsind keien Siemensbezeichnungen, sondern sollen Platzhalter sein. :wink:



Für...?


----------



## sps-concept (18 September 2011)

*Fdo*

Hallo,

wenns Ventile sind dann gibts ja evtl Probleme mit der kapazitiven Last. Sind es denn Ventile die sicher sind? Einfach Standardkomponenten an sichere Ausgänge anschliessen ergibt noch keine Sicherheit. Dafür gibts Abschaltung der Lastspannung, Einschaltventile usw.

André


----------



## Deltal (18 September 2011)

> Datenverfälschung im sicherheitsprogramm vor Ausgabe an F-Peripherie.



Das bedeutet das die Daten die zur F-Baugruppe geschickt werden dort nicht korrekt ankommen. Ein "Fehler" am Ausgang würde sich als "Kanalfehler" im Log wiederfinden.

Ich könnte mir dort nur vorstellen das an irgendeiner Stelle (z.B. über einen Blockmove -> der taucht ja nicht in den Querverweisen auf) auf den Ausgang geschrieben wird.

An dem IM oder den F-Modulen hast du ja keine Störung @ Hardy81?


----------



## sps-concept (18 September 2011)

*Meldungen*

normalerweise sollte da eine kanalbezogene Meldung kommen, aber man weiss ja nie. Wird ein Taktmerker oder Bits aus der Visu im F-Programm verwendet?

André


----------



## bike (18 September 2011)

Hardy81 schrieb:


> Für...?




Eine Variable, die du in deinem Safe definierst, fiel oder leicht .

Also ich habe deine Konfig für  eine 317F zusammen gebastelt und real getestet,.
Und das ist nicht gut, denn langsam gehen mir die Ideen aus.

Wenn es nicht zu geheim ist, lade die Hardware hoch, dann kann bzw muss ich nur die CPU tauschen und kann dann mit deiner Konfig testen.


----------



## yy1 (19 September 2011)

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 (20 September 2011)

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 (20 September 2011)

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 (20 September 2011)

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 (20 September 2011)

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 (20 September 2011)

maxpapa schrieb:


> 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 (20 September 2011)

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 (20 September 2011)

Hardy81 schrieb:


> 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 (20 September 2011)

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 (20 September 2011)

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 (20 September 2011)

Hardy81 schrieb:


> 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
> ...



 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 (21 September 2011)

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 (25 September 2011)

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.


----------

