AWL-Quelle in Safety-FB übersetzen

Dooni · 18 März 2013

Hallo,

ist es möglich, eine AWL-Quelle in einen Safety-FB zu übersetzen?
Das Übersetzen in einen "normalen" FB ist ja kein Problem und funktioniert. Gibt es hierfür ein Attribut das im Kopf der Quelldatei stehen muss, damit hieraus ein F-Baustein übersetzen kann?

Oder gibt es eine andere Möglichkeit, mit einem Editor ein Datei zu erstellen, die unter Quellen eingelesen werden kann und dann in einen Safety-FB übersetzt werden kann?

In dem FB sollen nur über Merker Ausgänge gesetzt werden, um einen Schaltschrank mit F-CPU im Prüffeld zu prüfen.
Aktuelle wird ein normaler FB aus der Quelle übersetzt und der Inhalt dann in einen Safety-FB kopiert. Deshalb war meine Frage, ob man eine Quelle sofort in einen Safety-FB übersetzen kann.

Wäre super wenn Ihr mir helfen könntet oder Lösungsansätze/Anregungen geben könntet.

Viele Dank
Daniel

IBFS · 18 März 2013

Dooni schrieb:
ist es möglich, eine AWL-Quelle in einen Safety-FB zu übersetzen?

Bausteine gibt es nur in F-KOP und F-FUP. Das muss bereits beim Erstellen des Bausteins angegeben werden. Daher kann
es eigentlich gar nicht möglich sein aus einer AWL-Quelle eine F-Baustein zu erzeugen.

Dooni · 21 März 2013

Die Vermutung bzw. Befürchtung hatte ich auch. Beim exportieren eines F-Baustein zu einer Quelle wird hieraus ein normaler Baustein.
Mein Chef, wo ich das Praktikum durchführe, meinte sich zu erinnern, dass dieses möglich wäre. Ist sich aber auch nicht 100% sicher.
Es gibt Bausteine von Siemens die in F-AWL erstellt wurden laut dem Simatic-Manager.
Ich werde sonst nächste Woche mal bei Siemens direkt anfragen.

nekron · 21 März 2013

moin moin ...

Das Thema F-AWL ist Siemens selbst vorenthalten, das Tool gibt es nur Hausintern.

Gruss
nekron

wattefuk · 23 März 2013

naja bedingt geht das schon.
Versuche folgendes: AWL-Baustein in "Fup" Ansicht darstellen - Netzwerke kopieren - in F-Fup Baustein einfügen.
Habe ich schon x-mal gemacht nachdem ich mir mit excel awl-code generiert habe.
Geht natürlich nur wenn die Netzwerke in Fup dargestellt werden können. Bei Schleifen ect. wirst du scheitern, zu recht. Nicht ohne Grund ist AWL laut norm nicht erlaubt.

IBFS · 23 März 2013

wattefuk schrieb:
Nicht ohne Grund ist AWL laut norm nicht erlaubt.

Das hat meines Wissen nichts mit einer Norm zu tun sondern nur damit, dass
sich alle Netzwerke in einen Inversen Logikcode umwandelbar sein müssen.
Das dürfte mit manchem AWL-Chaos-Spagetti-Code schwierig werden.

Denn Siemens führt den Code auf seinen F-CPU nicht in separaten Kernen wie im PNOZ-Multi
sondern mittels CodeInversion/Zeitdivergenz aus. Das bedeutet, dass der F-KOP/F-FUP
Code zweimal, das zweite Mal Invertiert, ausgeführt wird. sind beide Ergebnisse zueinander
plausibel wird der Ausgang entsprechend geschaltet.

wattefuk · 23 März 2013

Natürlich wird das ausgeschlossen.
Habe mir sogar für dich die Mühe gemacht die Passage aus der 61511 rauszusuchen

In der 61508 steht glaube ich auch so eine Passage drin.

12.4.2.3 Die gewählte Entwurfsmethode und die Anwendungssprache (LVL oder FPL) sollten Eigenschaften
aufweisen, die Folgendes erleichtern:
a) Abstraktion, Modularität und weitere Eigenschaften zur Beherrschung der Komplexität. Die Software
sollte wo immer möglich auf bewährten Software-Bausteinen aufbauen, unter Einschluss von Benutzer-
Bibliotheken und wohldefinierten Regeln zur Verknüpfung dieser Software-Bausteine.

Programmiersprachen mit eingeschränktem Sprachumfang (LVL) (en: limited variability language(LVL))
Art von Sprache, die für Anwender in der Prozessindustrie verständlich ist und es erlaubt, vordefinierte
anwendungsspezifische Bibliotheksfunktionen miteinander zu kombinieren und so die Spezifikation der
Sicherheitsanforderungen zu erfüllen. Die Funktionen einer LVL entsprechen in hohem Maße den für die
Anwendung erforderlichen Funktionen
ANMERKUNG 1 Typische Beispiele für LVL werden in der IEC 61131-3 aufgeführt. Sie umfassen unter anderem
Kontaktplan, Funktionsbaustein-Sprache und Ablaufsprache.
ANMERKUNG 2 Typisches Beispiel für ein LVL-Sytem: standardmäßige SPS (z. B. SPS für Brennersteuerungen).

PN/DP · 23 März 2013

wattefuk schrieb:
Natürlich wird das ausgeschlossen.
Habe mir sogar für dich die Mühe gemacht die Passage aus der 61511 rauszusuchen In der 61508 steht glaube ich auch so eine Passage drin.

12.4.2.3 Die gewählte Entwurfsmethode und die Anwendungssprache (LVL oder FPL) sollten Eigenschaften
aufweisen, die Folgendes erleichtern:
a) Abstraktion, Modularität und weitere Eigenschaften zur Beherrschung der Komplexität. Die Software
sollte wo immer möglich auf bewährten Software-Bausteinen aufbauen, unter Einschluss von Benutzer-
Bibliotheken und wohldefinierten Regeln zur Verknüpfung dieser Software-Bausteine.

Zum Vergrößern anklicken....

Programmiersprachen mit eingeschränktem Sprachumfang (LVL) (en: limited variability language(LVL))
Art von Sprache, die für Anwender in der Prozessindustrie verständlich ist und es erlaubt, vordefinierte
anwendungsspezifische Bibliotheksfunktionen miteinander zu kombinieren und so die Spezifikation der
Sicherheitsanforderungen zu erfüllen. Die Funktionen einer LVL entsprechen in hohem Maße den für die
Anwendung erforderlichen Funktionen
ANMERKUNG 1 Typische Beispiele für LVL werden in der IEC 61131-3 aufgeführt. Sie umfassen unter anderem
Kontaktplan, Funktionsbaustein-Sprache und Ablaufsprache.
ANMERKUNG 2 Typisches Beispiel für ein LVL-Sytem: standardmäßige SPS (z. B. SPS für Brennersteuerungen).

Zum Vergrößern anklicken....

Wo ist in den von Dir mühevoll rausgesuchten Passagen die Anwendung von AWL ausgeschlossen?

Harald

wattefuk · 23 März 2013

" Typische Beispiele für LVL werden in der IEC 61131-3 aufgeführt. Sie umfassen unter anderem
Kontaktplan, Funktionsbaustein-Sprache und Ablaufsprache."
Da steht weder was von Hochsprachen noch von AWL. Und wo bitte hat AWL eingeschränkten Sprachumfang?
Sogar das F-FUP hat einschränkungen gegenüber dem normalen FUP.
Ich kann mir kann mir auch nicht vorstellen dass irgendjemand Ein Progamm abnehmen würde (wenn es denn möglich wäre), das nicht in Fup/Kop geschrieben ist und ein gewisses Performancelevel/SIL erfüllen muss.

Da du das "sollte" so markiert hast.
Klar man kanns auch lassen und auf die Norm sch***n aber dann hast evtl später falls es wegen einem Softwarefehler vor Gericht gehen sollte schlechte Karten.

vollmi · 24 März 2013

Was ist denn der Unterschied zwischen Ablaufsprache und AWL?

marlob · 24 März 2013

vollmi schrieb:
Was ist denn der Unterschied zwischen Ablaufsprache und AWL?

http://de.wikipedia.org/wiki/Ablaufsprache

IBFS · 24 März 2013

wattefuk schrieb:
Klar man kanns auch lassen und auf die Norm sch***n aber dann hast evtl später falls es wegen einem Softwarefehler vor Gericht gehen sollte schlechte Karten.

Muss man das so schreiben? - mit sch***n usw.?

Es geht bei der ganzen Angelegenheit nur darum verifizierbaren Code zuzulassen, der zum Target also PLC-System passt. Da aber mache, wenn man AWL auch für den Endkunden zulassen würde
jeden beliebigen unstrukturierten Müll programmieren würden, hat besser davon abgesehen. Das man SIEMENS-intern mit geprüftem F-AWL dennoch arbeitet ist natürlich verständlich solange der
Code in die invertierte Entsprechung umgewandelt werden kann.

rostiger Nagel · 24 März 2013

Ich bin mir da jetzt nicht so sicher, ein Beckhoff Vertriebler hat mir mal erzählt
das für die V3, Safety in Hochsprache programmiert werden kann. Das würde
sich an große Kunden zb Werkzeugmaschinenhersteller richten, die ganz besondere
Ansprüche an die Sicherheitstechnik haben. Wenn von den ganzen später eine Art
Baumusterprüfung gemacht wird, ist das doch auch in Ordnung.

IBFS · 24 März 2013

rostiger Nagel schrieb:
....., die ganz besondere Ansprüche an die Sicherheitstechnik haben.

Das ist der völlig falsche Ansatz.

Sicherheitstechnik und vor allem Logische Verknüpfungen müssen für einen zweiten unabhängigen Prüfer nachvollziehbar sein.
Wenn ich mir die Sicherheitsprotokolle von einem PNOZ-Multi anschaue, kann das jeder Nichtprogrammierer nachvollziehen.

Auch sollte jeder Programmierer ein Interesse daran haben, das ein zweiter Unhabhängiger Prüfer seine Codekonstrukte mit
etwas Erklärung verstehen kann. Nur so ist sichergestellt, dass der Programmierer sich nicht verrannt hat.

Daher bin ich GEGEN jeder Art undurchschaubaren Codes und bin eindeutig für F-FUP und F-KOP. Alles andere dient in meinen
Augen nicht der Sicherheit sonder wird von Leuten initiiert, die wollen aber die nicht verstehen.

UniMog · 24 März 2013

Ablaufsprache = zB. Graph7 AWL = Anweisungsliste

IBFS schrieb:
Daher bin ich GEGEN jeder Art undurchschaubaren Codes und bin eindeutig für F-FUP und F-KOP. Alles andere dient in meinen
Augen nicht der Sicherheit sonder wird von Leuten initiiert, die wollen aber die nicht verstehen.

Komisch bei Safety ist das ok und sonst findet jeder KOP und FUP schlecht..

rostiger Nagel · 24 März 2013

Frank, was ich meine ist nicht für den kleinen Programmierer wie du und ich gedacht.
Was spricht dagegen das ein großer Maschinenbauer, eine Safety-Routine schreibt, diese
zb von der gleichen Stelle abnehmen lässt, die für Siemens das F_AWL Bausteine abnimmt.
Du als normale Anwender wirst auch niemals diesen Code nur ansatzweise zu Gesicht be-
kommen, wie du auch nicht in die zertifizierten Bausteine von Siemens rein sehen kannst.

Boxy · 24 März 2013

IBFS schrieb:
Sicherheitstechnik und vor allem Logische Verknüpfungen müssen für einen zweiten unabhängigen Prüfer nachvollziehbar sein.
Wenn ich mir die Sicherheitsprotokolle von einem PNOZ-Multi anschaue, kann das jeder Nichtprogrammierer nachvollziehen.

Eigentlich sollte wegen der Redudanz bzw. Fehlermöglichkeit ein 2 Programmierer die Safetyfunktion programmieren!
Nicht das man z.B. den Code für Schutztüre öffnen einfach aus dem "normalen" PLC programm rauskopiert und in den F-Teil kopiert!
Also nicht das beide Teile den selben Fehler enthalten und es dadurch zu einer Gefährdung kommen kann!

IBFS · 24 März 2013

Boxy schrieb:
Also nicht das beide Teile den selben Fehler enthalten und es dadurch zu einer Gefährdung kommen kann!

Diese Fehler findet man durch die finale Abnahme, wo verschiedene Szenarien wie Notaus, SLS, STO usw.
für jeden Antriebsstrand separat vorort getestet werden. Wenn dann Fehler nicht auffallen, wann dann?

Deltal · 24 März 2013

Je komplexer ein Programm, desto schwerer sind Fehler zu erkennen. Deswegen finde ich auch, dass es kein Hochsprache oder AWL in der Failsafetechnik braucht. Das verleitet nur dazu das komplexe Programme auch in den F-Teil wandern, auch wenn sie eventuell keinen Sicherheitsbezug haben. Für die Fehlersuche ist es sicherlich einfacher mir die gemalten Bausteine anzusehen, als irgendeine Zauberei mit Pointern und Lokaldaten.

Im Endeffekt ist es der Programmierer, der dafür zu sorgen hat ob das Programm "sicher" oder "nicht-sicher" ist. Kapitale Fehler kann ich auch in FUP einbauen.

@Daniel: kannst du nicht den Sicherheitsbetrieb deaktivieren und dann die Ausgänge ganz herkömmlich mit ST-Bausteinen ansprechen?

AWL-Quelle in Safety-FB übersetzen

Level-1

Level-1

Level-1

Level-2

Level-1

Level-1

Level-1

User des Jahres 2011-2013; 2015-2017; 2020-2022

Level-1

Level-3

Level-3

Level-1

Forums-Knochenbrecher

Level-1

Level-1

Forums-Knochenbrecher

Level-3

Level-1

Level-3

Similar threads

Wir schützen deine Privatsphäre