Fehlercodes

Themenpunkte:

  1. Datentyp für Fehlercodes [++]
  2. Fehlerinformation an Funktionen und Methoden [+]
  3. Fehlerinformation an Funktionsbausteinen [+]

Datentyp für Fehlercodes

Fehlercodes sollten als hrErrorCode (Typ HRESULT) spezifiziert und weitergegeben werden. Der Typ HRESULT hat die Besonderheit, dass Fehler durch negative Werte repräsentiert werden. Warnungen oder Informationen können optional mittels positiver Werte ausgegeben werden.

Als Alternative können Sie nErrorID (Typ UDINT) spezifizieren.

Deklaration

Fehlerbereich

Kein Fehler

Meldung/Info

Prüffunktionen

hrErrorCode : HRESULT;

<0

>=0

>0

IF SUCCEEDED(hrErrorCode) THEN
...
END_IF

IF FAILED(hrErrorCode) THEN
...
END_IF

nErrorID : UDINT;

>0

0

 

IF nErrorID = 0 THEN
...
END_IF

IF nErrorID <> 0 THEN
...
END_IF

Fehlerinformation an Funktionen und Methoden

Funktionen und Methoden benötigen keine Fehlerinformation, sofern kein Fehler eintreten kann. Beispiel: c := AddTwoValues(a, b);

Funktionen und Methoden können in Ausnahmefällen einen Fehlerfall allein mittels Boolean ausgeben, sofern es nur eine einzige Fehlerursache geben kann.

In den meisten Fällen geben Funktionen und Methoden einen Fehler mittels Fehlercode (HRESULT) am Rückgabewert an. Oft gibt ein Funktionsbaustein den Fehler der zuletzt aufgerufenen Methode aus. Siehe hierzu auch den Themenpunkt Fehlerinformation an Funktionsbausteinen.

Fehlerinformation an Funktionsbausteinen

Funktionsbausteine benötigen keine Fehlerinformation, sofern kein Fehler eintreten kann.

Es wird die Bereitstellung von Fehlerinformationen an Funktionsbausteinen in folgender Weise empfohlen.

Bei kleinen Funktionsbausteinen, welche wenige Fehlerursachen haben, sind folgende Ausgänge ausreichend:

VAR_OUTPUT
    bError          : BOOL;        // TRUE if an error occurred.
    hrErrorCode     : HRESULT;     // '< 0' = error; '> 0' = info; '0' = no error/info
END_VAR

Bei komplexeren Funktionsbausteinen, welche viele verschiedene Fehlerursachen mit ggf. verschiedenen Fehlerquellen haben, wird ein weiterer Ausgang empfohlen:

VAR_OUTPUT
    bError          : BOOL;        // TRUE if an error occurred.
    hrErrorCode     : HRESULT;     // '< 0' = error; '> 0' = info; '0' = no error/info
    ipErrorMessage  : I_TcMessage := fbErrorMessage; // shows detailed information about occurred errors, warnings and more
END_VAR
VAR
    {attribute 'conditionalshow'}
    fbErrorMessage  : FB_TcMessage;
END_VAR

bError ermöglicht eine möglichst einfache Abfrage, ob ein Fehlerfall vorliegt. Auch im Online View des SPS-Editors können Sie einen Fehler einfach sehen, sofern er über mehrere Taskzyklen ansteht.

hrErrorCode gibt den Fehlercode an und kann als solcher einfach weitergereicht werden. Im Online View des SPS-Editors wird der hexadezimale Wert angezeigt.

ipErrorMessage (alternativ ipResultMessage) zeigt detaillierte Informationen zum aufgetretenen Fehler. Im Online View des SPS-Editors wird unter anderem ein sprachabhängiger Klartext zur Fehlerbeschreibung angezeigt. Zudem kann diese Nachricht an den TwinCAT 3 Eventlogger übermittelt werden. Eigene Texte für eigene Fehlercodes können mittels eigener Eventklassen in Eventlisten definiert werden. Weitere Informationen finden sich in der Dokumentation der SPS Bibliothek Tc3_EventLogger und dem zugehörigen Beispiel. Am Ausgang des Funktionsbausteins sind die Informationen als Interface bereitgestellt, um den Zugriff auf relevante Inhalte zu begrenzen. Empfohlen wird allerdings, intern dafür zu sorgen, dass der Interfacepointer immer gültig ist.

Zu dem Thema Fehlercodes beachten Sie auch den folgenden Themenpunkt der Programmierkonventionen: