Probleme mit Berechnungen auf Wago SPS

[JPO]

Zuviel Werbung?
-> Hier kostenlos registrieren

Liebe Community,

ich habe ein Problem mit meiner Wago SPS 750-8102 und hoffe, dass jemand hier Erfahrung oder Lösungsvorschläge für mein Problem hat.

Ich habe ein Programm auf der SPS laufen, in dem diverse Berechnungen durchgeführt werden. Es handelt sich um einfache Berechnungen wie Addition, Subtraktion und andere mathematische Operationen. Normalerweise funktioniert alles einwandfrei und die Ergebnisse werden korrekt angezeigt.

Jedoch tritt nach ein paar Stunden Laufzeit des Programms das Problem auf, dass bei bestimmten Berechnungen plötzlich "NaN" (Not a Number) als Ergebnis angezeigt wird. Dies geschieht, obwohl die Operanden der Berechnung normale Zahlen sind und die gleiche Berechnung zuvor korrekt durchgeführt wurde.

Ich wäre sehr dankbar für jede Hilfe und jeden Hinweis, um dieses Problem zu lösen. Vielleicht hat jemand von euch eine Idee oder bereits Erfahrungen mit ähnlichen Problemen gemacht.

Vielen Dank im Voraus!

 

[JSEngineering]

Moin,
bitte Code dazu...
Spontan würde ich nicht von einem Rechenfehler ausgehen, sondern daß Ihr vermutlich mit Pointern arbeitet oder aber Array-Grenzen verletzt.
Implementiert mal die Funktion CheckBounds (steht in der Hilfe beschrieben) und prüft mal, ob Ihr Array-Grenzen verletzt.
Wo wird denn NaN angezeigt? Beim Debuggen oder im HMI?

 

[JPO]

Zuviel Werbung?
-> Hier kostenlos registrieren

Vielen Dank für die schnelle Antwort.

Ich denke, es könnte an den Array-Grenzen liegen, da ich mit Arrays arbeite. Ich habe unten mal zwei Zeilen vom Code angefügt, bei denen dies der Fall ist. Und es wird auf dem HMI angezeigt. Wenn ich anschliessend über das Cockpit auf die Steuerung zugreife, ist dies auch zu sehen.

ms_ABL[1] := rho_tr_ABL[1] * Vs_ABL[1];

ms_ZUL[1] := rho_tr_ZUL[1] * Vs_ZUL[1];

 

[JSEngineering]

irgendwo schreibst Du mit Schleifen auf die Arrays? Dann prüf mal die Grenzen.
Wie gesagt: Implementiere die Funktion CheckBounds und schau Dir das Schauspiel online an... dann findest Du die Stelle, wo's passiert.

 

[Oberchefe]

Division durch 0?

 

[JSEngineering]

Zuviel Werbung?
-> Hier kostenlos registrieren

Division durch 0?

Dann sollte aber die Steuerung in Stop gehen, oder nicht?

 

[holgermaik]

Ein NaN kann über eine Rechenoperation nicht erzeugt werden.
Bitte zusätzlich noch die POE "CheckDivReal, *INT, * LINT einfügen.
Im WBM den Status der PLC mal ansehen. Eine Exception sollte hier aufgeführt dein.

 

[PN/DP]

Ein NaN kann über eine Rechenoperation nicht erzeugt werden.

Bist Du sicher? (ich kenne mich mit Wago nicht aus)

 

[holgermaik]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bist Du sicher?

Wenn ich 2 Faktoren multipliziere kann des Produkt niemals ein NaN sein, es sei denn einer der Faktoren ist bereits ein NaN. Dann liegt mein Problem aber bereits weiter vorn.
Ist das bei Siemens anders?

 

[JPO]

Ist das richtig, dass ich dann bei jeder Division im Programm diese Funktion ausführe?

 

[JSEngineering]

Ja, das sind Diagnose-/Debug-Funktionen, die deaktivierst oder löschst Du am Ende, wenn das Programm fertig ist.

 

[holgermaik]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ist das richtig, dass ich dann bei jeder Division im Programm diese Funktion ausführe?

Die Funktionen werden automatisch durch die PLC ausgeführt bei z.B. jeder Division. Darum auch den Code im unteren Teil der Funktion sinnvoll ausprogrammieren. Nachdem du den Fehler gefunden hast die Funktionen wieder löschen.

 

[JPO]

Die Funktionen werden automatisch durch die PLC ausgeführt bei z.B. jeder Division. Darum auch den Code im unteren Teil der Funktion sinnvoll ausprogrammieren. Nachdem du den Fehler gefunden hast die Funktionen wieder löschen.

Ich verstehe noch nicht ganz wie ich dies implementieren muss. Kann ich einfach eine POU für implizite Prüfungen hinzufügen?

 

[JSEngineering]

Du fügst die Prüffunkiotnen hinzu. Sind diese in Deinem Programm vorhanden, werden sie automatisch ausgeführt bei jeder Berechnung bzw. bei jedem Array-Zugriff. Deshalb müssen die Funktionsnamen genau so übernommen werden, wie sie in der Hilfe vorgegeben sind.
Später löschst Du sie oder schließt sie von der Übersetzung aus, dann wird das Programm wieder performanter.
Aufrufen mußt DU selber die Funktionen nicht.
Wichtig ist nur, daß Du z.B. globale Zähler-Variablen nutzt, um die beobachten zu können. Rührt sich was, dann kannst Du auf die IF-Bedingung im Baustein einen Breakpoint setzen und Dich dann zum aufrufenden Baustein durchtickern und siehst, wo das Problem liegt.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ein NaN kann über eine Rechenoperation nicht erzeugt werden.

z.B.: Wenn man die Wurzel aus negativen Zahlen zieht, entsteht eine NaN.

 

[JPO]

Ich bin leider noch nicht weitergekommen, aber ich habe mal einen Screenshot angefügt. Vielleicht sieht ja jemand etwas.

 

[JPO]

Ich bin leider noch nicht weitergekommen, aber ich habe mal einen Screenshot angefügt. Vielleicht sieht ja jemand etwas.

Anhang anzeigen 71603

Oder ist das Ergebnis von ms_ABL[1] einfach zu klein?

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wird ms_ABL[1] (und evtl. Ws_ABL[1] ) woanders später im Programm nochmal irgendwie mit für REAL unzulässigen Werten überschrieben?
Die Wert-Anzeigen beim Beobachten zeigen vermutlich nicht die Werte bei der Anweisung, sondern die Werte am Zyklusende? ( 1.12 * 2.78E-05 ergibt nicht NaN )
Nimm mal testweise andere/frische Variablen.

 

[holgermaik]

Ich würde das Problem in der Funktion "Waermekapazitaetsstrom_Luft" vermuten.
Setze bei der Mutiplikation doch mal einen Breakpoint und gehe in Einzelschritten weiter um zu sehen wann die Variable NaN wird.

@PN/DP du hast natürlich recht. Meine Formulierung war nicht präzise genug, da der TE eine Multiplikation angegeben hat.

 

[PN/DP]

@PN/DP du hast natürlich recht. Meine Formulierung war nicht präzise genug, da der TE eine Multiplikation angegeben hat.

Hier hast Du es ja präzise formuliert:

Wenn ich 2 Faktoren multipliziere kann des Produkt niemals ein NaN sein, es sei denn einer der Faktoren ist bereits ein NaN.

So ist es.
Deshalb fällt in dem Bild in #16 mittlere Zeile auf, daß der Wert NaN nicht Ergebnis der Berechnung sein kann, sondern erst später in die Variable ms_ABL[1] kommt.

ms_ABL[1]    := rho_tr_ABL[1]     * Vs_ABL[1]        ;
         NaN                 1.12            2.78E-05

Das Ergebnis müsste 3.1136E-05 sein, und nicht NaN.

Ich würde das Problem in der Funktion "Waermekapazitaetsstrom_Luft" vermuten.

Könnte es sein, daß die Funktion irgendwie den NaN auf den ersten Parameter zurückschreibt? Könnte das ein IN_OUT-Parameter sein?
Oder wird irgendwo außerhalb des gezeigten Codes der NaN in die Variable ms_ABL[1] geschrieben?