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

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 12

Thema: Implizite und explizite Konvertierungen bei SCL

  1. #1
    Registriert seit
    04.04.2008
    Beiträge
    389
    Danke
    85
    Erhielt 39 Danke für 24 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo,

    hätte mal eine Frage zur impliziten (KLasse A) bzw. expliziten Konvertierung (Klasse B) bei SCL. Mir ist nicht klar, was der eigentliche Unterschied ist. Ich dachte bisher, implizite Konvertierungen können entfallen, weil der Kompiler sie implizit ausführt.

    Beispiel 1: Folgende Anweisungen rechnen richtig. Das habe ich in PLCSim getestet:
    Code:
    FUNCTION FC1: VOID
    //MW_16 wurde als INT deklariert
    //MW_18 wurde als INT deklariert
    //MD_20 wurde als DINT deklariert
    MD_20:=INT_TO_DINT(MW_16) + INT_TO_DINT(MW_18);
    END_FUNCTION
    Beispiel 2: Folgende Anweisungen rechnen z.B. bei negativen Zahlen falsch:
    Code:
    FUNCTION FC1: VOID
    //MW_16 wurde als INT deklariert
    //MW_18 wurde als INT deklariert
    //MD_20 wurde als DINT deklariert
    MD_20:=MW_16 + MW_18;
    END_FUNCTION

    Ich dachte, die Typ A-Konvertierungen können entfallen. "INT_TO_DINT" gehört zu den Klasse A Konvertierungen.
    Irgendwas habe ich da wohl nicht verstanden.

    Was heißt dann also Klasse A bzw. Klasse B?


    Gruß
    Earny
    Zitieren Zitieren Implizite und explizite Konvertierungen bei SCL  

  2. #2
    Registriert seit
    18.03.2008
    Beiträge
    267
    Danke
    3
    Erhielt 26 Danke für 26 Beiträge

    Standard

    Da hast du recht, ich seh das Problem auch nicht wirklich, nur mal eine Vermutung:

    Versuch das ganze mal mit Temp-Variablen zu machen, dann gehts vielleicht.
    Ich könnte mir vorstellen, dass der ein Problem mit den Merkerworten hat, weil das für ihn keine richtigen INT sind, sie werden nur als INT interpretiert. Darum verhaspelt er sich vielleicht mit dem Vorzeichen, welches das höchstwertige Bit in deinem Merkerwort ist...

    Für mich ist das ein Compilerfehler... ??!!??

  3. #3
    Registriert seit
    18.03.2008
    Beiträge
    267
    Danke
    3
    Erhielt 26 Danke für 26 Beiträge

    Standard

    Welche Version von SCL hast du denn im Einsatz?

  4. #4
    Registriert seit
    20.02.2008
    Beiträge
    332
    Danke
    16
    Erhielt 40 Danke für 37 Beiträge

    Standard

    Also auf dem ersten Blick scheint der SCL-Editor deine Deklarationen aus der Symboltabelle zu ignorieren. Er addiert Word und speichert das mit Hilfe von Akku1 in ein Dword. Dann ist natürlich das Bit für negative Werte an der Stelle 15, im Dword muss es aber an Stelle 31 sein. Ohne Umwandlung (AWL: ITD, SCL INT_TO_DINT) wird das nichts. Anders ist es, wenn Du Variablen direkt im Editor deklarierst, dann kann der Übersetzer das berücksichtigen.

  5. #5
    Earny ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    04.04.2008
    Beiträge
    389
    Danke
    85
    Erhielt 39 Danke für 24 Beiträge

    Standard

    MW_16 (MW16) und MW_18 (MW1 wurden in der Symbole jeweils mit INT deklariert. Es müssen deshalb zwei Variablen mit dem Datentyp INT sein.
    Ich habe die Version V5.3 + SP5 + HF1.

    Gruß
    Earny

  6. #6
    Earny ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    04.04.2008
    Beiträge
    389
    Danke
    85
    Erhielt 39 Danke für 24 Beiträge

    Standard

    Dann jetzt mal mit Temp-Variablen:

    das nachfolgende Programm rechnet stes richtig:

    Code:
    FUNCTION FC2: VOID
    VAR_TEMP
        Temp1:INT;
        Temp2:INT;
    END_VAR
    Temp1:=MW_16;
    Temp2:=MW_18;
    MD_20:=INT_TO_DINT(Temp1) + INT_TO_DINT(Temp2);
    END_FUNCTION
    Lasse ich INT_TO_DINT weg, rechnet es meistens falsch.
    Ich steuere wieder in PLCSim Werte ins MW16 und MW18. Beide Speicher stehen auf INT!


    Gruß
    Earny

  7. #7
    Earny ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    04.04.2008
    Beiträge
    389
    Danke
    85
    Erhielt 39 Danke für 24 Beiträge

    Standard

    Habe noch herausgefunden, dass die beiden folgenden Varianten richtig rechnen:

    FUNCTION FC1: VOID
    //MW_16 wurde als INT deklariert
    //MW_18 wurde als INT deklariert
    //MD_20 wurde als DINT deklariert
    MD_20:=INT_TO_DINT(MW_16) + MW_18;
    END_FUNCTION

    FUNCTION FC1: VOID
    //MW_16 wurde als INT deklariert
    //MW_18 wurde als INT deklariert
    //MD_20 wurde als DINT deklariert
    MD_20:=MW_16 + INT_TO_DINT(MW_1;
    END_FUNCTION

    Möglicherweise sind nur automatische Konvertierungen rechts vom Gleichheitszeichen gemeint?

    Gruß
    Earny

  8. #8
    Registriert seit
    03.04.2008
    Beiträge
    6.200
    Danke
    237
    Erhielt 815 Danke für 689 Beiträge

    Standard

    Du musst deinem Ergebnis das richtige Format zumindest einmal gönnen.
    Ob es der erste oder der zweite Term ist völlig egal.
    Wenn du nur 16 Bit rechnest, wie soll dann dein Ergebnis das Vorzeichen bekommen.
    Auch rechnen deine beiden letzten Versionen falsch, wenn du die 32767 in einem Term überschreitest.
    Aber das ist ja verständlich.
    Zumindest habe ich das noch so am Rande in Erinnerung.

    bike

  9. Folgender Benutzer sagt Danke zu bike für den nützlichen Beitrag:

    Earny (07.03.2012)

  10. #9
    Earny ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    04.04.2008
    Beiträge
    389
    Danke
    85
    Erhielt 39 Danke für 24 Beiträge

    Standard

    ja, ist dann wohl so. Deshalb arbeiten meine beiden Varianten von 21:31 Uhr beide richtig.
    Das mit -32768 bis +32767 bei 16 Bit-Ganzzahlen war mir klar.

    Gruß
    Earny

  11. #10
    Registriert seit
    29.03.2004
    Beiträge
    5.739
    Danke
    143
    Erhielt 1.686 Danke für 1.225 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Earny Beitrag anzeigen

    Beispiel 2: Folgende Anweisungen rechnen z.B. bei negativen Zahlen falsch:
    Code:
    FUNCTION FC1: VOID
    //MW_16 wurde als INT deklariert
    //MW_18 wurde als INT deklariert
    //MD_20 wurde als DINT deklariert
    MD_20:=MW_16 + MW_18;
    END_FUNCTION
    Zeig doch mal den generierten AWL Code von der Funktion.

    Eigentlich kann da nur etwas schiefgehen wenn der Übersetzer als Operation in AWL ein +D ohne voriges ITD anstelle eines +I generiert.

    Bei mir ist der erzeugte AWL Code so wie man es erwarten würde:
    Addition von zwei INT -> keine Konvertierung
    Zuweisung des Ergebnisses auf ein DINT -> Vorherige implizite Konvertierung (ITD in AWL)

    Und ich habe die gleiche SCL Version.

Ähnliche Themen

  1. Antworten: 1
    Letzter Beitrag: 23.01.2012, 17:06
  2. Antworten: 9
    Letzter Beitrag: 10.02.2011, 10:46
  3. Fehlerfenster bei SCL
    Von flyer im Forum Simatic
    Antworten: 1
    Letzter Beitrag: 25.03.2008, 17:46
  4. Hilfe bei SCL
    Von Gast im Forum Simatic
    Antworten: 3
    Letzter Beitrag: 30.05.2006, 18:28
  5. Brauche Hilfe bei SCL.SFC Aufrufen in SCL
    Von Gerold im Forum Simatic
    Antworten: 10
    Letzter Beitrag: 06.10.2005, 10:47

Lesezeichen

Berechtigungen

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