TIA Muß man Real in TIA-SCL tatsächlich mit E+000 angeben?

Ralle

Super-Moderator , User des Jahres 2006-2007
Teammitglied
Beiträge
15.404
Reaktionspunkte
4.039
Zuviel Werbung?
-> Hier kostenlos registrieren
Kann mir das mal jemand erklären:

1 Zahlen_1.jpg

2 Zahlen_2.jpg

Kann es wirklich sein, dass TIA-SCL 2.13 nicht als Real erkennt?

1 habe ich vor Update 3 aufgenommen.
Nach Update 3 war es noch genauso.
Dann habe ich die Zahlen auf 2 geändert, nun wurde korrekt gerechnet.
Anschließend habe ich das E+000 wieder entfernt und:

3 Zahlen_3.jpg

nun wird auch korrekt gerechnet.

Ein neu angelegter Baustein hat ebenfalls richtig gerechnet.

Ist das der Bug, den Siemens mit Update 3 behoben hat?

Das ist doch unglaublich, wer kann nun überhaupt noch mit gutem Gewissen eine Siemens-SPS mit TIA programmiert einsetzen?
Welches Kraftwerk fliegt in die Luft, weil nicht einmal eine primitive Real-Rechenoperation korrekt funktioniert?
Autohersteller hätten spätestens jetzt eine Rückrufaktion gestartet, aber Siemens jubelt uns ein "harmloses" Update 3 unter!

Haben die eine Macke? Was soll das sein???

Ich finde das ungeheuerlich.

Lieber Perfektionist, hoffentlich fliegt dir deine letzte Maschine nicht um die Ohren, ich würde hier sofort mal Tests durchführen.
 
Zuletzt bearbeitet:
Naja... Test3 macht auch keinen Sinn

2/8 ist auch nicht 3 sondern wäre wenn überhaupt 0,3 (mit dem schönen runden wie es die anzeige tut)

Vielleicht ist es eine Anzeigeoption? Das die Rechnung korrekt ist, die Anzeige aber nicht.

Gib die Variablen mal in WinCCflex aus und teste es in der RT oder so...

Grüße

Marcel
 
Ich hab das mal ergänzt, jetzt sollte das klar sein.
Ich finde das unglaublich und halte die möglichen Konsequenzen für äußerst gefährlich.
Wer sich z.Bsp. die Zahl PI selbst als Konstante definiert hat rechnet u.U.einen Haufen Müll zusammen.

@Matze

Ich hab die Zahlen in der Variablentabelle und direkt im Online-Modus getestet, das sollte reichen.
Das gaze trat unter Update 3 noch auf, bis ich die Zahlen einmal mit E+000 und dann wieder in herkömmlicher Weise geschrieben habe.
Seitdem ist das weg, auch ein neu erzeugter Baustein rechnet nun korrekt, also kann ich das nicht mehr mit der Version vor Update 3 testen.
Das scheint aber auch zu heißen, dass man nach Update 3 alle Zahlen kontrollieren und korrigieren muß!!!!!!!!!!!
 
Zuletzt bearbeitet:
Okay das macht jetzt Sinn...

aber Wahnsinn ist das schon.

Ich bin froh, dass ich TIA nur bei 1200er einsetzen muss, und da sind es max. 10 FUP-netzwerke... da ist mir bisher noch nichts schlimmes passiert!

Grüße

Marcel
 
Uiui, das würde auch den Effekt von VISTanwender erklären. Der Fehler scheint wohl in V12 eingebaut worden zu sein, denn in V11 ist er noch nicht enthalten.
Sieht wirklich aus als ob es bei Siemens überhaupt keine Qualitätssicherung gibt. Es muss doch eigentlich ein Testprogramm geben an dem geprüft wird ob alle Ausdrücke korrekt übersetzt werden, aber da scheint es wirklich nichts zu geben. Jeder pröttelt am Programm rum und dann ab zum Kunden damit.
Könnte ja mal einer beim Forentreffen fragen ;-)
 
Also bei TIA V11 kann ich das nicht sagen, es war eine TIA 11-Programm, das ich in V12 getestet habe. Auch eine "Neu schreiben" des Bausteins in TIA V12 half nicht, erst Update 3 und dann noch die händische Korrektur.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das heisst wenn ich ein Programm aus V11 in V12 benutzt habe (noch vor Upd3) muss ich jede Verwendung von einem Real-Wert nachprüfen.

Hätte ich mir jetzt die Arbeit gemacht und bereits meine Programme konvertiert, würde ich jetzt wieder 200-300 Real-Konstanten vor mir haben -> schönen Dank auch!

Ich bleibe bei Classic, da weiß ich was mich (nicht mehr) überrascht!

Grüße

Marcel
 
Moin,

ich möchte mich hier mal kurz mit anhängen.

Ich bin zur Zeit dabei eine 314C-2 PN/DP V3.3 mit dem TIA V12 Update3 zu programmieren. BZW bin schon auf der IBN
Dabei hab ich natürlich festgestellt, dass SCL mit REAL irgendwie große Grütze ist. Könnt ihr nir die beiden angehängten Bilder mal erklären?
Bild TEST_SCL_TIA_FC ist eine FC .._Temp sind Temp-Var. .._Input sind IN-Var. Alles aufgerufen im OB und übergeben wird am INT_Input 580 und REAL_Input 580.0

Bei Bild TEST_SCL_TIA_FB ist es ein FB mit dem selben und zusätzlich noch Stat_Var.
Ich muss dazu sagen, das ich gerad erst in den Kinderschuhen stecke, was SCL angeht.
Ich fande es aber sehr interessant zu proggen, da ich doch eine etwas längere Rechnung machen musste und diesen in AWL sehr unübersichtlich wäre.
Warum funktioniert die REAL Geschichte nur, wenn ich diese von IN übergebe???
 

Anhänge

  • TEST_SCL_TIA_FB.jpg
    TEST_SCL_TIA_FB.jpg
    420 KB · Aufrufe: 71
  • TEST_SCL_TIA_FC.jpg
    TEST_SCL_TIA_FC.jpg
    401,2 KB · Aufrufe: 56
Zuviel Werbung?
-> Hier kostenlos registrieren
Das sieht ja putzig aus.
Hast du die Möglichkeit den generierten AWL Code hier mal reinzustellen?
Ich weiß nicht ob das mit dem TIA Portal auch möglich ist, ansonsten in Plcsim oder eine SPS laden, und dann mit Step 7 einen AG-Abzug machen.
 
off-topic, sorry.
aber bei siemens fällt mir in letzter zeit nur noch eins ein: "siemens hat nur noch bananen-produkte, die reifen beim kunden, vor ort"
 
So ich hab das mit Step7 gemach, hab keine Lust zu suchen

OB1:
Code:
ORGANIZATION_BLOCK OB 1
VERSION : 0.1


VAR_TEMP
  TEMP0 : BYTE ;	
  TEMP1 : BYTE ;	
  TEMP2 : BYTE ;	
  TEMP3 : BYTE ;	
  TEMP4 : BYTE ;	
  TEMP5 : BYTE ;	
  TEMP6 : INT ;	
  TEMP7 : INT ;	
  TEMP8 : INT ;	
  TEMP9 : DATE_AND_TIME ;	
END_VAR
BEGIN
NETWORK
TITLE =

      CALL FC     1 (
           IN0                      := 580,
           IN1                      := 5.800000e+002);
      NOP   0; 
NETWORK
TITLE =

      CALL FB     1 , DB     1 (
           IN0                      := 580,
           IN1                      := 5.800000e+002);
      NOP   0; 
NETWORK
TITLE =

END_ORGANIZATION_BLOCK

FC1:
Code:
FUNCTION FC 1 : VOID
TITLE =
VERSION : 0.1


VAR_INPUT
  IN0 : INT ;	
  IN1 : REAL ;	
END_VAR
VAR_TEMP
  TEMP2 : REAL ;	
  TEMP3 : INT ;	
  TEMP4 : REAL ;	
  TEMP5 : REAL ;	
  TEMP6 : REAL ;	
  TEMP7 : REAL ;	
END_VAR
BEGIN
NETWORK
TITLE =

      SET   ; 
      SAVE  ; 
      =     L     22.0; 
      L     L#1084227584; 
      T     #TEMP2; 
      L     L#1084227584; 
      T     #TEMP7; 
      L     580; 
      T     #TEMP3; 
      L     L#1084227584; 
      T     #TEMP4; 
      L     #IN0; 
      ITD   ; 
      DTR   ; 
      T     #TEMP5; 
      L     #IN1; 
      T     #TEMP6; 
      CLR   ; 
      U     L     22.0; 
      SAVE  ; 
END_FUNCTION

FB1:
Code:
FUNCTION_BLOCK FB 1
TITLE =
VERSION : 0.1


VAR_INPUT
  IN0 : INT ;	
  IN1 : REAL ;	
END_VAR
VAR
  STAT2 : REAL ;	
  STAT3 : INT ;	
  STAT4 : REAL ;	
  STAT5 : REAL ;	
  STAT6 : REAL ;	
  STAT7 : REAL ;	
END_VAR
VAR_TEMP
  TEMP8 : REAL ;	
  TEMP9 : INT ;	
  TEMP10 : REAL ;	
  TEMP11 : REAL ;	
  TEMP12 : REAL ;	
  TEMP13 : REAL ;	
END_VAR
BEGIN
NETWORK
TITLE =

      SET   ; 
      SAVE  ; 
      =     L     22.0; 
      L     L#1084227584; 
      T     #TEMP8; 
      L     L#1084227584; 
      T     #TEMP13; 
      L     580; 
      T     #TEMP9; 
      L     L#1084227584; 
      T     #TEMP10; 
      L     #IN0; 
      ITD   ; 
      DTR   ; 
      T     LD    24; 
      L     LD    24; 
      T     #TEMP11; 
      L     #IN1; 
      T     #TEMP12; 
      L     L#1084227584; 
      T     #STAT2; 
      L     L#1084227584; 
      T     #STAT7; 
      L     580; 
      T     #STAT3; 
      L     L#1084227584; 
      T     #STAT4; 
      L     LD    24; 
      T     #STAT5; 
      L     #IN1; 
      T     #STAT6; 
      CLR   ; 
      U     L     22.0; 
      SAVE  ; 
END_FUNCTION_BLOCK

DB1:
Code:
DATA_BLOCK DB 1
VERSION : 0.1

 FB 1
BEGIN
   IN0 := 580; 
   IN1 := 5.800000e+002; 
   STAT2 := 5.000000e+000; 
   STAT3 := 580; 
   STAT4 := 5.000000e+000; 
   STAT5 := 5.800000e+002; 
   STAT6 := 5.800000e+002; 
   STAT7 := 5.000000e+000; 
END_DATA_BLOCK

Wieso wird nur bei IN0 mit ITD und DTR gewandelt und nicht auch bei L 580???? :shock:
Ich glaube ich werde das mal an Siemens weiter geben.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
hab mich gleich mal an der ersten zeile (SCL, in vergleich zu AWL) versucht.
also "L L#1084227584; " ist schon falsch:

Code:
1084227584
->hex
4    0    A    0    0    0    0    0
0100|0000|1010|0000|0000|0000|0000|0000|
VZ
 |   exp  ||          mantisse        |
VZ 0 = pos
exp= 10000001 = 129
mantisse
0*2^-1=0
1*2^-2=0,25
0*2^-3=0
0* ...
...

Wert= (1+mantisse)*2^(exp-127)= 5 (!!!)

es wird einfach 5.0 geladen, nicht 580.0, sieht nach einen compiler-fehler aus. die 5.0exp0 ist ja auch in dem bild zu sehen. wie damals bei ralle.
hoffe mal ich hab mich nicht vertran, hab nebenher noch nen anderes projekt laufen...
 
Wieso wird nur bei IN0 mit ITD und DTR gewandelt und nicht auch bei L 580???? :shock:
Ich glaube ich werde das mal an Siemens weiter geben.

meinst du bei:
Code:
 L     580; 
T     #TEMP3;
?
dort ist es ja _int := _int, da braucht man keine wandlung, bei L 580.0 (Real) wird das normal schon vom compiler gewandelt im quellcode steht der entsprechende wert. dann muss das bei konstanten nicht bei jedem durchlauf von der sps erledigt werden. was normal ein zeitgewinn ist, wenn es funktioniert.^^

EDIT: bei sowas wie lade int_temp ist es dann wieder das selbe, auch wenn der wert x zeilen weiter oben als konstante 580 steht und erst im verlauf des code's gewandelt wird, das optimiert der compiler weg. was ein normales verhalten ist. nur muss die compilerinterne umwandlung halt richtig funktionieren, was sie hier offenbar nicht tut. :-(
Code:
[FONT=Helvetica]#INT_TEMP:=580;[/FONT][FONT=Helvetica]...[/FONT]
[FONT=Helvetica]
[/FONT]
[FONT=Helvetica]REAL_Temp2:=INT_TO_REAL(#INT_TEMP);[/FONT]
[FONT=Helvetica]
[/FONT]
[FONT=Helvetica]compiler macht daraus:[/FONT]
[FONT=Helvetica]
[/FONT]
[FONT=Helvetica]REAL_TEMP2:=580.0;[/FONT]
[FONT=Helvetica](da der wert eh konstant ist, optimierung!)[/FONT]

der fehler sollte also immer auftreten, wenn konstanten zugewiesen werden. ob nun direkt per wert, oder über den umweg eines symbolischen namen.
-> der Funktions(baustein) aufruf ist offenbar von der code-optimierung ausgenommen, dort erwartet man sicher keine konstanten.

EDIT2:
Welches Kraftwerk fliegt in die Luft, weil nicht einmal eine primitive Real-Rechenoperation korrekt funktioniert?
aber dafür gibt es doch spezielle sicherheitsmechanismen:
http://www.industry.siemens.com/top...step7-safety-advanced-v11/seiten/default.aspx
;-) :idea:

EDIT3: sollte mit dem neusten update wieder weg sein: #32
oder du hast ein zu neues update, dann is es wieder drinn, man kann sich ja auch nicht immer neue bug's ausdenken.^^
 
Zuletzt bearbeitet:
S7-300/S7-400: Die Berechnung von Real Werten als Konstanten wurde korrigiert.
http://support.automation.siemens.c...e&objid=68321809&Datakey=47071380&caller=view

ach, iwie komm ich von den bug nicht weg. das fasziniert mich so...
also is anscheinend mit update 2 gekommen und durch 3 wieder behoben.
was für eine "verbesserung"

Der Inhalt von Update 2 wird ab Update 3 bereitgestellt.
gibt es daher schon garnicht mehr. :cool:
ich hätte gerne gewusst, was da als "verbesserung" stand, vielleicht "funktionalität wurde über die grenzen hinaus optimiert, quasie wegoptimiert"

EDIT1: den bug gab es offenbar nur in SCL (laut siemens), da sieht man wie wenig leute SCL nutzen. das das keinen großen aufschrei gab. ich hab hier nur 2 beiläufige themen entdeckt.
 
Zuletzt bearbeitet:
Zurück
Oben