Hi again
da habe ich mit meiner Frage ja mächtig Wirbel ausgelöst. Andereseits ist das aber auch ein dicker Hammer.
Ich hatte ein wenig Urlaub und komme erst jetzt dazu mit wieder einzubringen.
MSB schreibt
Wenn du eingibst L 1.0 dann landet das letzten Endes als Hex-Wert im Speicher. Also in der Form L DW#16#...
Heißt also im Klartext, du rechnest nicht mit 1.0 sondern mit was anderen.
Früher, in der guten alten Zeit, konnte man das auch noch Nativ als MC7 Code sehen, leider hat sich Siemens davon mit TIA aber verabschiedet (wenigstens von den "einfachen" Möglichkeiten.
Die Auswirkung ist: Du rechnest Murks.
Das stimmt nicht -- also das mit der guten alten Zeit. Auch bei der 1200 und der 1500 ist im Speicher ein REAL nach IEEE754 abgelegt. Kann man sehen, wenn man mit Wireshark das Laden eines DB beobachtet. Warum sollten sie das auch ändern, dann könnten sie ja die FPU auf dem Controller (welchen sie auch immer nehmen) nicht verwenden.
Das was VISTAnwender schreibt, das ist das wovor ich Angst hatte. Au weia. Update3 beseitigt das und das ist auch gut so. Haben sie das jetzt selber gemerkt oder ist ein erboster Anwender Sturm gelaufen? Wir werden es wohl nie erfahren. Genauso wenig, wie man uns verraten wird wie lange der Fehler wohl drin war.
Meine alten SCL Programme tun also alle noch, denn die sind ja mit V5 gaschrieben. Die Neuen für die 1200 und die 1500 funktionieren auch, denn der Fehler bezog sich laut S nur auf 300/400. Da hatte ich aber Glück, dass ich keine neuen Programme für alte CPUs machen musste. Das wird auch noch länger so bleiben, so lange es kein PDIAG im Portal gibt.
Implizite Konvertierungen waren und sind schon immer mit gaaaanz viel vorsicht zu geniesen. Ich kann mich erinnern, dass ich beim Umstieg von Visual Studio 4 auf Visual Studio 5 drei Tage nach einem Fehler gesucht habe, der dadurch zustande kam, dass sich die Reihenfolge der Auswertung in einem Ausdruck geändert hat. Heute ist es so, dass Visual Studio 2010 einen Ausdruck unterschiedlich auswertet und zwar in Abhängigkeit, ob dieser für CLR oder native übersetzt wird. Nochmal ganz langsam zum mitdenken. Da steht was in C++. Wenn das für .Net übersetzt wird, dann kommt was anderes raus wie für x86. Obwohl doch beides auf dem selben Windows 7 läuft. VS hat also zwei unterschiedlich C++ Compiler. Der für .Net ist gar nicht nett. Der für x86 liefert das was auch GCC liefert. Doch zurück zum Portal.
SCL hat einen Satz Regeln, wie Typen implizit konvertiert werden. Und einen zweiten Satz Regeln wie zwei unterschiedlich Typen miteinander verknüpft werden. Leider stell das Handbuch das in keinster Weise übersichtlich dar. Ich wünsche mir zwei Tabellen.
In der Ersten sollte drin stehen, wie ein Typ in den anderen verwandelt wird. Also sowas wie INT_TO_WORD ist ein bitcopy. INT_TO_DINT ist eine vorzeichenrichtige Erweiterung. INT_TO_REAL ist eine Zweierkomplement nach IEEE754 Konvertierung. REAL_TO_DWORD ist ein bitcopy .... Das sind so meine bisherigen Erfahrungen
In der Zweiten sollte drin stehen, wie zwei Typen miteinander verknüpft werden. Also INT+DINT=DINT, INT+REAL=REAL, INT+WORD=INT, ... Vielleicht muss man da auch noch die Operation beachten. Ein ADD ist nun mal was anderes wie ein AND.
Ach wie einfach sind doch KOP und FUP. Da sagt die Box wie gerechnet wird und die zu kleinen Kästchen an den Anschlüssen sagen dir ob konvertiert wird. (In den meisten Fällen übrigens so wie das SCL auch tut.)
Über AWL sag ich da mal nix, das ist halt Assembler. Hier kann man ein REAL mit einem DINT als INT addieren und 16 bit unter den Tisch fallen lassen.