Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 3 von 4 ErsteErste 1234 LetzteLetzte
Ergebnis 21 bis 30 von 33

Thema: TIA Portal V12 Update 3 verfügbar

  1. #21
    Registriert seit
    29.03.2004
    Beiträge
    5.735
    Danke
    143
    Erhielt 1.685 Danke für 1.225 Beiträge

    Standard


    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.

  2. #22
    Registriert seit
    22.11.2007
    Beiträge
    731
    Danke
    6
    Erhielt 89 Danke für 62 Beiträge

    Standard

    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?

  3. #23
    Registriert seit
    29.03.2004
    Beiträge
    5.735
    Danke
    143
    Erhielt 1.685 Danke für 1.225 Beiträge

    Standard

    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:
    Zitat Zitat von Siemens SCL Hilfe
    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.

  4. #24
    Registriert seit
    09.11.2007
    Ort
    Rhein Main (Darmstadt)
    Beiträge
    663
    Danke
    61
    Erhielt 112 Danke für 80 Beiträge

    Standard

    Zitat Zitat von Thomas_v2.1 Beitrag anzeigen
    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.

    Als Freelancer immer auf der Suche nach interessanten Projekten.
    Zitieren Zitieren Interger oder Integral ?  

  5. #25
    Registriert seit
    29.03.2004
    Beiträge
    5.735
    Danke
    143
    Erhielt 1.685 Danke für 1.225 Beiträge

    Standard

    Zitat Zitat von RobiHerb Beitrag anzeigen
    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

    [INDENT] 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.

    Zitat Zitat von RobiHerb Beitrag anzeigen
    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.

  6. #26
    Registriert seit
    29.03.2004
    Beiträge
    5.735
    Danke
    143
    Erhielt 1.685 Danke für 1.225 Beiträge

    Standard

    Zitat Zitat von Thomas_v2.1 Beitrag anzeigen
    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

    Zitat Zitat von TIA Informationssystem
    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.
    Geändert von Thomas_v2.1 (01.06.2013 um 11:17 Uhr)

  7. #27
    Registriert seit
    24.04.2013
    Beiträge
    309
    Danke
    23
    Erhielt 160 Danke für 88 Beiträge

    Standard

    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.

  8. #28
    Registriert seit
    25.06.2007
    Ort
    Dresden
    Beiträge
    3.930
    Danke
    465
    Erhielt 878 Danke für 634 Beiträge

    Standard

    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.
    Geändert von IBFS (03.06.2013 um 10:35 Uhr) Grund: Satzzeichen!
    Grüße Frank

  9. Folgende 2 Benutzer sagen Danke zu IBFS für den nützlichen Beitrag:

    RobiHerb (03.06.2013),vollmi (03.06.2013)

  10. #29
    Registriert seit
    29.03.2004
    Beiträge
    5.735
    Danke
    143
    Erhielt 1.685 Danke für 1.225 Beiträge

    Standard

    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.

  11. Folgender Benutzer sagt Danke zu Thomas_v2.1 für den nützlichen Beitrag:

    Perfektionist (03.06.2013)

  12. #30
    Registriert seit
    25.06.2007
    Ort
    Dresden
    Beiträge
    3.930
    Danke
    465
    Erhielt 878 Danke für 634 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    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?
    Grüße Frank

Ähnliche Themen

  1. Modbus Slave im TIA Portal V12 - S7-1500
    Von shutdown_TIA12 im Forum Simatic
    Antworten: 4
    Letzter Beitrag: 07.11.2013, 16:08
  2. Antworten: 19
    Letzter Beitrag: 10.08.2013, 17:02
  3. TIA TIA PORTAL V12: Erste Eindrücke
    Von vita-2002 im Forum Simatic
    Antworten: 188
    Letzter Beitrag: 23.05.2013, 04:29
  4. TIA Portal v12 mit S7 1200
    Von dentech im Forum Simatic
    Antworten: 2
    Letzter Beitrag: 27.03.2013, 08:39
  5. [Parallelthread] TIA-Portal V12: erste Eindrücke
    Von Perfektionist im Forum Stammtisch
    Antworten: 11
    Letzter Beitrag: 08.03.2013, 16:45

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •