TIA OK-Flag mit TIA in SCL

[Earny]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich suche das OK-Flag zum Einsatz bei SCL im TIA-Portal (V11.2).
Bei STEP7 muss das OK-Flag zuerst in den Compiler-Optionen aktiviert werden. Dann kann es im Programmcode eingesetzt werden. Im TIA-Portal habe ich diese Option noch nicht gefunden.
Irgendwie muss es aber gehen!?

 

[Thomas_v2.1]

Die Funktion heißt jetzt "ENO automatisch setzen" in den Bausteineigenschaften.

In SCL kannst du ENO ganz einfach mit

ENO := true;

setzen.

Bei gesetzter Option "ENO automatisch setzen" funktioneren die meisten Operationen in SCL wie in FUP, d.h. der EN/ENO zieht sich durch die verschalteten Bausteine, Funktion wird unter Umständen durch die zusätzlichen Prüfungen langsamer.

 

[HelleBarde]

Zuviel Werbung?
-> Hier kostenlos registrieren

Und mit

IF ENO THEN ...

abfragen.

Wenn du von einer Funktion oder einem Funktionsbaustein ein ENO brauchst, dann sieht das bei TIA etwa so aus

myFC( para1 := wert, ENO => #tmpBOOL )

oder

myFC( para1 := wert, ENO => ENO )

Ersteres geht sogar, wenn "ENO automatisch setzen" nicht sitzt

'n schön' Tach auch
HB

 

[Earny]

Geht die Auswertung des Wertes von ENO auch in dem Baustein, indem der Fehler passiert? Mir ist das lieber, als die Auswertung des Fehlers im aufrufenden Baustein.
Mit dem OK-Flag in SCL bei STEP7 ist das möglich.

 

[HelleBarde]

Klar

angenommen du hast eine Rechnung:

a := b+c

dann kannst du danach

IF NOT ENO THEN
    "Nothalt" := true;
END_IF

schreiben. Dazu muss das Attribut am Baustein sitzen. Die Voreinstellung bei SCL ist jedoch keine Überlauferkennung bei der Arithmetik.

 

[Earny]

Zuviel Werbung?
-> Hier kostenlos registrieren

Funktioniert bei mir leider doch nicht.

Ich habe folgendes Beispiel:

"MD_30":=BCD16_TO_INT("EW_16")**BCD16_TO_INT("EW_18");
IF NOT ENO THEN "MD_30":=0; END_IF;

Ich rechne a**b (Potenzieren). Dabei kann es leicht zum Zahlenüberlauf kommen. MD_30 ist ein Real. Im EW_16 und EW_18 stehen max. dreistellige BCD-Zahlen.
Beim Zahlenüberlauf müsste 0 im MD_30 stehen. Steht aber 1.#INF00e+000 drin.
Es spielt keine Rolle, ob der Haken bei "ENO" sitzt oder nicht. Ich meine den Haken in Extras - Einstellungen - PLC-Programmierung - SCL...

Wäre ich in STEP7, würde ich das ENO durch OK ersetzen. Das funktioniert dann. Beim Zahlenüberlauf steht dann 0 im MD_30, wenn bei Compiler-Optionen das OK-Flag gesetzt ist.

 

[Thomas_v2.1]

Was hast du denn für eine CPU? 300/400, 1200 oder 1500?

Laut Doku soll bei einer Migration eines SCL Programmes OK durch ENO ersetzt werden. Dann sollte es ja schon genauso funktionieren.

Probier doch mal was der ENO-Ausgang in FUP/KOP bei so einer Operation ausgibt.

 

[Earny]

Ist ein CPU314C-2DP.
Ich werde mal das S7-Projekt mit dem OK-Flag nach TIA migrieren. Mal schauen, ob das dann geht.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bei der 300er kann man sich ja zum Glück noch ansehen was für ein AWL-Code der Compiler erzeugt.
Ich habe mal vergleichen:

1) Step 7 V5.5 SP4

{SetOKFlag := 'y'}

FUNCTION FC1 : VOID

VAR_INPUT
    a : REAL;
    b : REAL;
END_VAR

VAR_OUTPUT
    o_k : BOOL;
END_VAR

VAR_TEMP
    r : REAL;
END_VAR

BEGIN
r := a ** b;
o_k := OK;
END_FUNCTION

erzeugt:

      SET   
      SAVE  
      =     L      4.1
      L     #a
      LN    
      SPO   I007
      SPA   I008
I007: CLR   
      =     L      4.1
I008: L     #b
      *R    
      SPO   I009
      SPA   I00a
I009: CLR   
      =     L      4.1
I00a: EXP   
      SPO   I00b
      SPA   I00c
I00b: CLR   
      =     L      4.1
I00c: T     #r
      CLR   
      U     L      4.1
      =     #o_k
      SAVE  
      BE

2) TIA Portal V11 SP2 Upd 4

FUNCTION "TestOkFlag" : Void
{ S7_Optimized_Access := 'FALSE' }
VERSION : 0.1
   VAR_INPUT 
      "a" : Real;
      "b" : Real;
   END_VAR

   VAR_OUTPUT 
      "o_k" : Bool;
   END_VAR

   VAR_TEMP 
      "r" : Real;
   END_VAR



BEGIN
	#r := #a ** #b;
	#o_k := ENO;
END_FUNCTION

mit gesetzter Option "ENO automatisch setzen" erzeugt:

      SET   
      SAVE  
      =     L      4.0
      =     L      6.0
      L     #IN0
      L     #IN1
      TAK   
      LN    
      SPO   M001
      SPA   M002
M001: CLR   
      =     L      6.0
M002: *R    
      SPO   M003
      SPA   M004
M003: CLR   
      =     L      6.0
M004: EXP   
      SPO   M005
      SPA   M006
M005: CLR   
      =     L      4.0
      =     L      6.0
M006: T     #TEMP3
      CLR   
      U     L      4.0
      =     #OUT2
      CLR   
      U     L      4.0
      SAVE

Wenn du nur den Zustand des Endergebnisses abfragst sollte es keinen Unterschied geben.
Bei Step7 fließt in das OK-Flag aber der Zustand der Zwischenergebnisse mit hinein. Das landet beim TIA-Portal in L6.0 und wird dann nicht weiter verwendet, keine Ahnung was die sich dabei gedacht haben. Vielleicht generiert eine neuere Version oder ein anderes SP oder Update auch wieder völlig anderen Code. Die TIA V11 würde ich auch nicht produktiv einsetzen (persönliche Meinung: V12 und V13 auch nicht).

 

[Earny]

Dann heißt das wohl, dass die Funktionalität des OK-Flags im TIA nicht mehr existiert.

 

[Thomas_v2.1]

Ich würde behaupten dass wenn dein Endergebnis "unendlich" anzeigt, dass auch bei den Code vom TIA Portal Auswirkungen haben sollte. Außer die Wertanzeige im TIA-Portal und die Verarbeitung in der SPS sind nicht identisch.

Lade das Programm über das TIA-Portal in die SPS, und schau dir dann mit dem Classic-Step7 den Code an. Am Besten online.

Habs grad nochmal mit TIA V12 Upd 3 getestet, die macht nochmal anderen AWL-Code, aber von der Funktion her ist es näher an dem was Step7 erzeugt hat.

      SET   
      SAVE  
      =     L      4.0
      L     #IN0
      L     L#0
      <R    
      TAK   
      SPB   M001
      SPA   M002
M001: CLR   
      =     L      4.0
M002: L     #IN1
      TAK   
      LN    
      SPO   M003
      SPA   M004
M003: CLR   
      =     L      4.0
M004: *R    
      SPO   M005
      SPA   M006
M005: CLR   
      =     L      4.0
M006: EXP   
      SPO   M007
      SPA   M008
M007: CLR   
      =     L      4.0
M008: T     #TEMP3
      CLR   
      U     L      4.0
      =     #OUT2
      CLR   
      U     L      4.0
      SAVE

Wie gesagt, TIA-Portal ist eine Wundermaschine wo mit jedem SP und Update an Funktionen rumgefrickelt wird die schon lange hätten funktionsfähig sein müssen.

 

[HelleBarde]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Earny

Funktioniert bei mir leider doch nicht.

"MD_30":=BCD16_TO_INT("EW_16")**BCD16_TO_INT("EW_18");
IF NOT ENO THEN "MD_30":=0; END_IF;

SCL hat mitunter unerwartete Regeln für die implizite Konvertierung. Du wandelst zwar die BCD nach INT. Aber dein Ergebnis soll REAL werden. Also muss SCL hier nochmal konvertieren. So wie ich das an anderen Beispielen sehe, wird das EW16 von BCD nach INT nach REAL gewandelt und dann mit dem von BCD nach INT gewandelten EW18 potenziert.
Maximal 999 --> 999.0 ** 999 = 3,6806348825922326789470084006052e+2996 ... bestimmt zu groß für ein Real.
Die 999 Wurzel aus 1e38 ist 1.09. Also wenn dein EW18 wirklich bis 999 kommt, dann darf dein EW16 nicht größer 1 sein ...


Also wenn der Haken sitzt, dann klappt es im Allgemeinen schon mit dem ENO, aber nach dem was S. da schon alles verbockt hat, könnte es auch sein, dass beim Potenzieren ein neuer Murks drin ist. Das muss ich morgen mal ausprobieren.

Ich setze die V13 produktiv ein -- kein Mitleid bitte -- so schlimm ist es gar nicht mehr, nur laaaaangsam

'n schön' Tach auch
HB

 

[Earny]

Hallo HelleBarde

Die fehlende Konvertierung INT_TO_REAL ist eine Klasse-A-Konvertierung. Diese wird in diesem Fall automatisch ausgeführt. Ich weiß aber auch, dass die Klasse-A-Konvertierungen nicht immer implizit erfolgen. Das spielt aber hier keine Rolle. Die Rechnung wird im übrigen ja richtig ausgeführt. Wenn du z.B. im EW16 den Wert 10 eingibst und im EW18 den Wert 38 dann wird als Ergebnis 1.000004e+38 angezeigt (in PLCSim). Die Ungenauigkeit interessiert mich nicht. Bei dieser Rechnung bleibt - wie gefordert - das ENO auf True.
Wenn ich jetzt bei EW16 den Wert 10 und im EW18 den Wert 39 eingebe, dann gibt es einen Zahlenüberlauf, weil das theoretische Ergebnis (1.0e39) außerhalb des Zahlenbereichs der Real-Zahlen liegt. In diesem Fall müsste ENO auf False gehen, macht es aber nicht.

Ergebnis: Der ENO-Mechanismus vom TIA-Portal ist unbrauchbar. Er funktioniert nicht, jedenfalls nicht bei Zahlenüberläufen.

 

[Thomas_v2.1]

Wieso guckst du dir den generierten AWL Code nicht mal mit dem Classic Step7 an? Dann kannst du genau sehen woran es scheitert.

 

[Earny]

Zuviel Werbung?
-> Hier kostenlos registrieren

Für mich ist wichtig zu wissen, dass bei möglichen Zahlenüberläufen (mit gravierenden Folgen) SCL unter TIA (V11) nicht eingesetzt werden darf, da der ENO-Mechanismus nicht funktioniert. Ich wüsste auch nicht, wie ich bei meinem Beispiel "Potenzieren" das Problem in TIA-SCL lösen könnte.

Ich schau auch nicht nach, wie der AWL-Code aussieht der vom SCL-Compiler erzeugt wird, sondern programmiere dann gleich in AWL. Hier nehme ich das OS-Bit und frage es mit SPS ab. Das funktioniert.

 

[HelleBarde]

Hi Earny

richtig, es sollte nicht unser Bier sein, den AWL Code zu kontrollieren. Die V11 macht beim Potenzieren jedenfalls was falsch. In der V13 ist es dann richtiger. V12 habe ich nicht probiert.

Hi Thomas

aber unsereiner ist eben so gnadenlos neugierig. Du hast ja im #9 so schön die verschiedenen AWLs gepostet. Mein Gott sind die alle schlecht.
Statt

[COLOR=#333333]          SPO   I007[/COLOR][COLOR=#333333] 
          SPA   I008
[/COLOR][COLOR=#333333]I007: CLR
   [/COLOR][COLOR=#333333]        =     L      4.1 [/COLOR]

hätte man doch ohne die ganze Springerei

    U OV
    R L4.1

schreiben können.

Und es hätte wahrscheinlich heißen sollen

[COLOR=#ff0000]        U     L 6.0 [/COLOR][COLOR=#333333] 
        =     #OUT2 [/COLOR]

Offenbar haben sie das aber selber bemerkt und machen es inzwischen richtiger, aber nicht besser.
Gut dass es jetzt bei 1200 einen POW_R gibt und vermutlich auch bei 1500 ;-)

'n schön' Tach auch
HB

 

[Sudoku]

Hi Earny

richtig, es sollte nicht unser Bier sein, den AWL Code zu kontrollieren. Die V11 macht beim Potenzieren jedenfalls was falsch. In der V13 ist es dann richtiger. V12 habe ich nicht probiert.
h auch
HB

Meine TIA V11, Update2 macht beim Potenzieren (obiges Beispiel) auch nichts falsch. Wenn du die Rechenungenauigkeit meinst, dann ist das völlig normal. Bei Rechnungen mit Real-Zahlen sind nur 6 bis 7 Ziffern korrekt. Der Rest ist "geraten". Das wird erst besser - und die Zahl der richtigen Ziffern ist dann ca. 14 - wenn man anstelle der 32 Bit- die 64 Bit-Kommazahlen einsetzt (Double anstelle von Real). Aber die gibt es nicht bei der S7-300/400.

Gruß
Sudoku

 

[HelleBarde]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi Sudoku

es geht nicht um Genauigkeit. Earny beschwert sich ganz zu Recht über ein falsches ENO

'n schön' Tach auch
HB