IEC 61131-3 3rd Edition

W

Werner29

Level-2
Beiträge
297
Reaktionspunkte
117
Zuviel Werbung?
-> Hier kostenlos registrieren
Liebes Forum,

die 3rd Edition der 61131-3 ist seit ein paar Wochen käuflich erhältlich, z.B. hier:
http://webstore.iec.ch/webstore/webstore.nsf/Artnum_PK/47556

der Standard wurde komplett runderneuert und enthält jetzt auch Objektorientierung.

Ich hatte das Vergnügen (das ist nicht mal Ironie) an dieser Edition mitarbeiten zu dürfen und bin ein bisschen
enttäuscht, dass die einschlägigen Fachzeitschriften das noch überhaupt nicht wahrgenommen haben.
Also mach ich hier mal ein bisschen Werbung, auch wenn es noch ein bisschen dauern dürfte, bis der neue Standard
am Markt ankommt.

 
Für den Preis wird sich das aber kein Anwendungs-Programmierer hinlegen. Vor allem weil es auch nicht wirklich hilfreich ist wenn die Implementierung des Standards vom Standard abweicht, oder erweitert wird wie bei Codesys (z.B. Pointer).
Eigentlich schade dass es nicht wie andere genormte Sprachspezifikationen frei verfügbar ist.

In der 2nd Edition war gerade bei der formalen Sprachdefintion der ein oder andere Fehler vorhanden. Bei einem Standard sollte man schon prüfen ob das zusammenpasst was drin steht. Vielleicht ist es in der 3rd ja behoben.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
CoDeSys 3.x

Hallo Werner,

irgendwie ist die 3rd Edition doch nichts neues mehr. CoDeSys 3.x ist bereits länger verfügbar, die 3rd Edition implementiert und wird vielfach verwendet.
Mit der Veröffentlichung von CoDeSys 3.x habe ich auch vielfach Artikel in den Fachzeitschriften gelesen.

Oder enthält der Standard nun noch Änderungen/Erweiterungen gegenüber der aktuell verfügbaren Implementierung in CoDeSys 3.x?

Gruß, Neals
 
Ich habe mir mal in der Vorschau das Inhaltsverzeichnis angesehen. Irgendwie bin ich mir nicht ganz sicher wer die Zielgruppe dieses Buches sein soll (ich denke eher Entwickler die Programmierumgebungen und Compiler für Steuerungen entwickeln, oder?)
340€ für 230 Seiten ist jedenfalls schon eine ordentliche Hausnummer.
 
Ich würde auch sagen eher für Compilerbauer oder Tool-Entwickler.
Wobei ich auch als Anwender einer IEC 61131-Implementierung ganz gerne in eine Norm reinschaue, um zu prüfen wie ich normgerecht programmieren kann, damit mein Norm-IEC Programm auch auf anderen IEC 61131 konformen Umgebungen läuft.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Thomas_v2.1 schrieb:
Ich würde auch sagen eher für Compilerbauer oder Tool-Entwickler.
Zum Vergrößern anklicken....

Natürlich, für den SPS-Programmierer wird es erst dann interessant, wenn die Tools den Standard unterstützen. Und genauso richtig:
im Moment gibt es nur CODESYS V3, dass den neuen Standard zum grössten Teil unterstützt.
Insofern hat sich tatsächlich erstmal nichts geändert.
Dass Interessante für euch ist vielleicht, dass alle (in Europa) relevanten Marktteilnehmer, also insbesondere auch Siemens, an dem Standard mitgearbeitet haben.
Ob das auch ein Bekenntnis ist, diesen Standard umzusetzen, weiss ich natürlich nicht.

Die Preise für Normen erklären sich wahrscheinlich durch die Stundenlöhne in der Schweiz. Und schliesslich muss jede Norm ins Französische übersetzt werden.
Die Firmen, die die Arbeit geleistet haben, machen das jedenfalls auf eigene Kosten. Ich wollte auch niemanden zum Kauf auffordern, das macht vermutlich nur für die wenigstens hier Sinn.

Zum Inhalt: ich habe letztes Jahr in Aachen folgenden Vortrag gehalten über den neuen Standard, das sollte einen Überblick verschaffen:

http://www.plt.rwth-aachen.de/fileadmin/plt/events/2012/Sommerkolloquium/Werner-61131-3.pdf
 
Exceptions

Werner29 schrieb:
Zum Inhalt: ich habe letztes Jahr in Aachen folgenden Vortrag gehalten über den neuen Standard, das sollte einen Überblick verschaffen:

http://www.plt.rwth-aachen.de/fileadmin/plt/events/2012/Sommerkolloquium/Werner-61131-3.pdf
Zum Vergrößern anklicken....

Die Zusammenfassung finde ich sehr schön und wenn ich auch noch einen Wunsch äussern dürfte für Version 4, wäre das in etwa folgendes:

Es fehlt das Konzept der Exceptions, sprich Auffangen von Zuständen (die eigentlich nicht eintreten dürften aber die reale Welt ist immer noch etwas komplexer als der Theoretiker/Programmierer sich vorstellen kann).

Das ist bei einer SPS natürlich nicht mit einer Messagebox möglich aber man kann sich bestimmt einiges einfallen lassen.

Also z.B. Reaktionen etwa so je nach Typ:

TRY_BEGIN
MACHEETWAS (); // hier könnte es schief laufen
TRY_END
CATCH_BEGIN (EXCEPTION (EX))
CASE (EX.TYP) OF
CASE COMTIMEOUT:
; // führt zur Neuinitialisierung der Kommunikation
BREAK;

CASE MATHERROR:
; // führt zum Warm Reset
BREAK;

CASE LIMIT:
; // führt zur Abschaltung der Ausgänge,
BREAK;

CASE NOCONNECT:
; führt zur Inselbildung,
BREAK;

DEFAULT: // Etwas, was überhaupt nicht absehbar war
; // führt zum Notaus,
BREAK;
CATCH_END


Das kann man sich natürlich besser überlegen, nur so eine Anregung. Wichtig ist mir ein sauberes organisiertes Reagieren des Systems unter Vermeidung von Absturz oder Totalblockade. Einschliesslich des Durchfallens durch die gesamte Aufrufkette bis ein Catch Handler gefunden wird.
 
Da bin ich schon am überlegen.
Für die Implementierung wäre es von Vorteil wenn man ausschliesslich Funktionsaufrufe (und Methodenaufrufe) in ein strukturiertes Exception Handling packen kann.
In etwa stelle ich mir folgende Syntax vor:

__TryCall (<Funktionsaufruf>)
__Except
<beliebiger Code>
__EndTry

Das wäre natürlich erstmal eine CODESYS-Lösung. Bis zur 4th Edition werden noch ein paar Jährchen vergehen...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Braucht es wirklich Exceptions?
In den Hochsprachen werden Ausnahmen ja von den Methoden geworfen wenn sie einen Fehler erkennen.
Wenn ich meine FBs mit einen ERR Ausgang und evtl. noch einem ERRNO ausrüste, erreiche ich das Gleiche. So oder so muss ich die Fehlererkennung selber implementieren.

Code: 
_Try
  FBlock();
_Except
  MachWas();
_endTry

oder

FBlock();
if FBlock.ERR then
  MachWas(Fehler := FBlock.ERRNO);
end_if

nimmt sich irgendwie nicht viel. Oder Übersehe ich da was?
 
Dein Code geht ja davon aus, dass der FBlock alle seine Fehlerzustände detektiert und man diese Fehler behandeln kann.
Aber ein Programmierfehler in dem FBlock der eine Exception auslöst, kann man so natürlich nicht behandeln, wie beispielsweise Division by zero.

Exceptions sollten meiner Meinung nach nur für wirklich unerwartete Situationen verwendet werden, und nicht um einen "normalen" Fehlerzustand nach aussen zu melden.

Aber es kann schon die Situation geben, dass die gesamte Applikation, oder ein Teil einer Applikation nicht mehr weiterarbeiten kann und in einen sicheren Zustand versetzt werden
muss. Man kann dann mit Exceptions ganz angenehm arbeiten, weil die Behandlung des Fehlers über den gesamten Aufrufstack an eine zentrale Stelle transportiert werden kann.

Also wie immer geht es auch um den persönlichen Programmierstil.
 

Similar threads

M
IEC 61131-3 3rd Edition Buch - oop
Antworten
3
Aufrufe
3K
murillo
M
Zurück
Oben