TIA TIA Portal V12 Update 3 verfügbar

Zuviel Werbung?
-> Hier kostenlos registrieren
Eigentlich ist hier auch nicht die Spezifikation von C oder einer anderen Sprache relevant, sondern die von Siemens.
Beim TIA Portal gibt es für SCL aber keine wirkliche Spezifikation, ich schaue gleich mal ob man dazu bei Step7 etwas aussagekräftiges findet, da wurde noch etwas sorgfältiger geschrieben.

Nur ist deine Aussage eben falsch dass die Typkonvertierungen bei allen anderen Sprachen linksseitig (wohl meinend Anhand des Typs linksseitung der Zuweisung) vorgenommen werden.
Es wird immer pro Operation konvertiert, und jede Operation hat eine Ergebnis mit einem entsprechenden Datenyp. Für die Operationen eines gesamten Ausdrucks erfolgt dann die Konvertierung entsprechend der Operationsreihenfolge.
 
Eigentlich ist hier auch nicht die Spezifikation von C oder einer anderen Sprache relevant, sondern die von Siemens.

die Definitionen von Siemens orientieren sich normalerweise immer an der Aussenwelt - aber meistens werden Details vergessen

Um mal von diesem Es-ist-wie-es-ist-Beweisen wegzukommen:

Findest du es persönlich sinnvoll das Siemens sich hier nicht an C (und anderen) orientiert - was ist der Vorteil?

Nur ist deine Aussage eben falsch dass die Typkonvertierungen bei allen anderen Sprachen linksseitig (wohl meinend Anhand des Typs linksseitung der Zuweisung) vorgenommen werden.

Ja diese Aussagen war falsch und ich hab mich jetzt schon genug geschämt - aber verstehe trotzdem nicht warum für die 32 Bit S7 1200 nicht einfach die Integral promotion benutzt wird dir wir sonst so kennen
- oder ist das Historisch kompliziert?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die IEC Spezifikation kennt überhaupt keine implizite Typkonvertierung, bzw. ist alles was damit zusammenhängt "implementation dependent".

In der Spec von Step7 SCL steht folgendes:
Siemens SCL Hilfe schrieb:
Implizite Datentyp-Konvertierung
Innerhalb der in der Tabelle definierten Klassen von Datentypen wird vom Compiler eine implizite Datentyp-Konvertierung entsprechend der angegebenen Reihenfolge durchgeführt. Als gemeinsames Format zweier Operanden ist jeweils der größere der beiden Datentypen definiert - so ist z.B. das gemeinsame Format von BYTE und WORD - WORD.

Beachten Sie bitte, dass bei einer Datentyp-Konvertierung innerhalb der Klasse ANY_BIT führende Bits auf 0 gesetzt werden.

Klassen
Reihenfolge der Konvertierung

ANY_BIT
BOOL > BYTE > WORD > DWORD

ANY_NUM
INT > DINT > REAL

Da dort nichts von Integral Promotion steht, muss ich einfach davon ausgehen dass es das nicht gibt. Ob das nun sinnvoll ist oder nicht sei mal dahingestellt (auf 8-Bit CPUs muss man bei den dabei u.U. entstehenden Effekten auch aufpassen), vor allem weil der C Standard auch viele Punkte offen lässt bzw. abhängig vom Zielsystem sind (z.B. der Typ int nur _mindestens_ 16 Bits hat).

Wichtig ist nur dass das Verhalten irgendwo dokumentiert ist und es auch so funktioniert, bei Step7 SCL ist es eindeutig.

Um bei dem Beispiel zu bleiben: Wenn ich eine DINT Multiplikation haben will muss ich eben DINT#3600 schreiben.
 
Interger oder Integral ?

Die IEC Spezifikation kennt überhaupt keine implizite Typkonvertierung, bzw. ist alles was damit zusammenhängt "implementation dependent".

In der Spec von Step7 SCL steht folgendes:


Da dort nichts von Integral Promotion steht, muss ich einfach davon ausgehen dass es das nicht gibt...schreiben.

Auch mal meinen Senf dazu für ST/SCL: Wenn man das Problem hat, verschiedene Datentypen miteinander arithmetisch zu verknüpfen, dann:

1. hat man oft einen Design Fehler im Programm, den man möglichst bald beheben sollte.

2. verlässt man sich nicht auf den Zufall oder die Implementation sondern macht einen expliziten Typecast z.B. BYTE_TO_INT (bData).


Ansonsten scheint hier eine Sprachverwirrung zu bestehen zwischen den Ausdrücken Integral Promotion und Integer Typecast. Aus der "Bibel" aller C Programmierer hier die Zeilen (ca.1975 geschrieben):

K&R, C Programming Language, 2nd Ed. p. 174

A.6.1 Integral Promotion
A character, a short integer, or an integer bit-field, all either signed or not, or an object of enumeration type, may be used in an expression wherever an integer may be used. If an int can represent all the values of the original type, then the value is converted to int; otherwise the value is converted to unsigned int. This process is called integral promotion.


 
Ansonsten scheint hier eine Sprachverwirrung zu bestehen zwischen den Ausdrücken Integral Promotion und Integer Typecast. Aus der "Bibel" aller C Programmierer hier die Zeilen (ca.1975 geschrieben):

K&R, C Programming Language, 2nd Ed. p. 174

A.6.1 Integral Promotion


Und die C99 Norm spricht von Integer Promotion.
Ist also prinzipiell beides richtig, weil beide das gleiche meinen. Wegen dieser Verwirrung hatte ich auch erst Integral in Integer korrigiert.

2. verlässt man sich nicht auf den Zufall oder die Implementation sondern macht einen expliziten Typecast z.B. BYTE_TO_INT (bData).
Hier ging es aber um ein Problem bei der impiziten Konvertierung, wenn ich selber eine explizite x_TO_y Konvertierung einbaue, ist alles was mit der darauffolgenden Berechnung falsch läuft Problem des Programmierers. Eine implizite Konvertierung von ANY_BIT zu ANY_NUM ist aus gutem Grunde nicht vorgesehen.​
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Eine implizite Konvertierung von ANY_BIT zu ANY_NUM ist aus gutem Grunde nicht vorgesehen.

Muss ich mich für das TIA Portal gleich mal korrigieren.
Denn dort ist es Voreinstellung dass das geht

TIA Informationssystem schrieb:
Ohne IEC-Prüfung (Voreinstellung)
Bei nicht eingestellter IEC-Prüfung werden die folgenden Regeln angewandt:

Die implizite Konvertierung von Bitfolgen in anderen Datentypen ist möglich. Ein Operand vom Datentyp WORD kann z. B. an einem Parameter angegeben werden, wenn an diesem der Datentyp INT erwartet wird.

Wobei man trotzdem nicht schreiben kann:
#int_var := #word_var;

Weil dann die Fehlermeldung
"Eine implizite Konvertierung von Datentyp 'Uint' nach 'Int' ist nicht möglich"
erscheint.

Aha, WORD wird also intern als Uint erkannt. Gleich mal testen:

Ein
#uint_var := #word_var;
funktioniert damit bei deaktivierter IEC-Prüfung.

Allerdings kann man den Haken bei IEC-Prüfung setzen und das Programm wird trotzdem fehlerfrei übersetzt, obwohl es laut Beschreibung nicht funktionieren darf.
Vielleicht kann mal einer in V12 testen ob das dort korrigiert wurde.


Edit:
Passt alles, Fehler saß vor der Tastatur.
Wenn man den globalen Haken bei IEC-Prüfung setzt, wird das nur für neue erstellte Bausteine übernommen. Wenn man das an einem bestehenden Baustein umstellen möchte, muss man das in den jeweiligen Bausteineigenschaften anpassen. Und dann lässt sich die Funktion auch nicht mehr übersetzen.
 
Zuletzt bearbeitet:
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. :rolleyes:
 
In einem vernünftigen Programmentwurf haben "Implizite Datentyp-Konvertierungen" nicht zu suchen.

Dieses ganze Gerede - ich weiß ja was ich tue, wenn ich REAL und INT addiere - ist Schwachsinn.

Man hat klar und transparent zu programmieren - ohne Tricks - dann können einem die verborgenen Compiler-Regeln egal sein.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Ein guter Programmierer sollte sein Werkzeug kennen, und das ist in diesem Fall der Compiler. Die Regeln sind nicht veborgen sondern sie sind da und auch dokumentiert. Hier geht es nicht um irgendwelche Tricks, sondern darum zuverlässige Programme zu schreiben.
Und da sind solche Dinge eben nicht egal und Schwachsinn.
 
Was ist den für den armen Programmierer so schlimm eine explizite Typwandlung zu machen? Bricht da der Zacken aus der Krone?

Ich sage nur
Code:
ITD
DTR

Ist das wirklich so schwer die beiden Zeilen zu schreiben wenn man von INT nach REAL will?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Guten Morgen,
wollte mich abschliessend auch nochmal melden.
Nachdem jetzt hier mehrere Seiten lan über Typen und Definitionen geschrieben wurde.

Der Fehler im TIA v12 VOR dem letzten Update hat NICHTS mit irgendeiner Typumwandlung zu tun.

Ich multipliziere einen REAL mit einer REAL-konstante und das Ergebniss landet in einem REAL.
Das einzigzte Problem von Siemens ist folgendes: Der SCL-compiler (NICHT AWL) macht in meinem Beispiel aus 3600.0 einfach 3 !!! :confused:

Das ist ein unding, dass Siemens so etwas ungetestet veröffentlicht. :sb7:

Dennoch ist dieser Fehler mit dem neuesten Update behoben.
 
Zurück
Oben