FT-PT1: Ãœberlauf (Funktion SPS)

[mg]

Hallo Leute

Strg: S7-300
Portal: TIA12 SR4
Oscat: STEP7-TIA-V3.32

Nun habe ich einen Fehler im FT-T1 entdeckt. Der geht irgenwann oder irgendwie mal in den Überlauf:
"out" steht dann ein für allemal auf 16#7FFFFFFF.
Aber ich bin der Meinung daß dieser Fehler auf alle Funktionen zutrifft. Es wird in den Oscat-Funktionen kein Überlauf abgefragt (und schon gar nicht wie wie in der S7 mit dem Statuswort - mit abfragen und löschen) und die Siemens-Steuerung speichert die Überlaufmeldung bis sie gelöscht wird, dh.: wenn mal eine Variable in dem Überlauf rauscht wird die nie mehr berechnet. (im AWL mit der Funktion SPS im SCL bin ich noch am studieren wie ich das bestens lösen soll).
Dieses Problem hatte ich in der einen oder anderen Art schon bei meinem Code nun aber auch im original OSCAT Code

Vielen Dank

Mg

[mg]

Hallo Leute

Testbedingungen: CPU 314
Software: TIA12

a) warum der Baustein den Überlauf/Divison durch 0 oder sonst was für einen Fehler hat, kann man nach 1 Jahr Betrieb nicht mehr 100%tig rekonstruieren.
b) definitiv stürzt der Baustein bei einem solchen Fehler ab. Das bedeutet der Baustein geht bis in den Nimmerleinstag auf out 16#7FFFFFFF

Nach SEHR vielen Tests und viel Kopfzerbrechen verstehe ich wieso hierzu niemand antwortet:
Den Code "NAN" oder "16#7FFFFFFF" kann man mit herkömmlichen Mitteln nicht abfragen. Es soll zwar irgendwo ("ganz sicher") ein ENO Bit für eine fehlerhafte Berechnung gesetzt werden aber auf das wollte ich mich nicht verlassen (diese Funktion kann man evtl. sogar ein- bzw. ausschalten). Aber das ganze Zeugs mit dem (ENO-Bit, Ok-Bit, OV-Bit und VIELE Kostrukte mehr) funktioniert im TIA anders wie im STEP 7/5.5 und sowieso anders im KOP,AWL,SCL. Für die Abhandlung der Überläufe gibt es für jede Sprache,Software eigene Sonderlösungen  (der Support hat mir da auch nicht wirklich helfen können). ZUMINDEST BEI MIR HAT EIN DERARTIGER FEHLER NOCH NIE ZU EINER FEHLERMELDUNG IN DER SPS GEFÜHRT - "DIAGNOSE" IST SOMIT SINNLOS (ich bin bisher nur zufällig auf diese Fehler gestoßen - aber vielleicht weiß da jemand einen Trick - WÄRE SEHR DANKBAR).

Irgendwann habe ich dann mal erkannt, daß eine IF-Anweisung bei der auf eine solche Zahl abgefragt wird IMMER in den ELSE-Zweig rennt. Und genau hier liegt das Problem des FT-T1. Die Lösung ist ganz simpel:


(* read system time *)
#tx := "T_PLC_US"();
 
(* startup initialisation *)
IF #init AND #T <> t#0s  AND #out<+3.402823e+38 AND #out>-3.402823e+38 THEN
  #x1:=DWORD_TO_DINT(#tx) - DWORD_TO_DINT(#last);
  #x2:=DINT_TO_REAL(DWORD_TO_DINT(#tx) - DWORD_TO_DINT(#last));
  #x3:=(#in * #K - #out);
  #x4:=(#in * #K - #out) * DINT_TO_REAL(DWORD_TO_DINT(#tx) - DWORD_TO_DINT(#last));
  #x5:=DINT_TO_REAL(TIME_TO_DINT(#T)) * 1.0E-3;
  #x6:=(#in * #K - #out) * DINT_TO_REAL(DWORD_TO_DINT(#tx) - DWORD_TO_DINT(#last)) / DINT_TO_REAL(TIME_TO_DINT(#T)) * 1.0E-3;
  #out := #out + (#in * #K - #out) * DINT_TO_REAL(DWORD_TO_DINT(#tx) - DWORD_TO_DINT(#last)) / DINT_TO_REAL(TIME_TO_DINT(#T)) * 1.0E-3;
  IF ABS(#out) < 1.0E-20 THEN #out := 0.0; END_IF;
ELSE
  #init := TRUE;
  #out := #K * #in;
END_IF;
#last := #tx;


(+/- 3.402823e+38ist eigentlich irrelevant. Es reicht irgendeine Abfrage statt AND #out<+3.402823e+38 AND #out>-3.402823e+38 kann man auch richtigerweise AND #out=#out verwenden ... das sieht aber dann sehr suspekt aus!)


Für mich taucht nun noch ein weiteres Problem auf. Ich will natürlich nicht alle Funktionen der SIEMENS OSCAT nach Rekursionen durchschauen. Da werde ich nimmer fertig. Kann man in einem zukünftigen Release diese Problematik bei der S7 vielleicht berücksichtigen.

[mg]

Habs nochmals bei einer CPU 315 probiert.

Hier reicht "#out=#out" nicht da braucht es die Abfrage  "#out<+3.402823e+38 AND #out>-3.402823e+38"

Ein Test mit der CPU 1513 steht noch aus.
 

[mg]

Funktioniert auch in der 1511 und 1513.

Grundsätzlich tauchen die Probleme irgendwann mal völlig unkontrolliert auf. DER BAUSTEIN MUSS UNBEDINGT DERART VERÄNDERT WERDEN.

Mg

[martin.k]

Hallo!

Betrifft diese Sache nur die S7-Welt? Oder auch andere "Sprachen" sprich andere Hardware betroffen?

Gruß
Martin

[mg]

Das weiß ich nicht. Ich verwende auch die Beckhoff/Wago Codesys aber da hatte ich bisher keine derartigen Probleme. Allerdings ist die sowieso etwas weiter entwickelt.