TIA TIA Warnmeldungen nach Übersetzen

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mittlerweile generiert TIA einiges an Warnmeldungen beim Übersetzen. Ich bin aber etwas "unzufrieden" mit dem Prinzip nach dem diese Warnmeldungen generiert werden.

Beispiel der Warnmeldungen bei identischem Programm: Lesender Zugriff auf eine Out-Variable in einem FB (out_int := out_int + 1
Ergebnis:

- FUP: "Die Variable '#out_int' ist als Output deklariert. Der lesende Zugriff auf die Variable wird nicht empfohlen."
- SCL: "Der Parameter '#out_int' wird möglicherweise nicht initialisiert."

Hingegen führt ein Lesender Zugriff auf eine Temp-Variable ohne voriges Schreiben weder in SCL noch in FUP zu einer Warnmeldung.

Was ungemein sinnvoll ist, denn dort wo der Zugriff zu einem definierten Ergebnis kommt bekomme ich eine Warnmeldung, da wo es garantiert nicht sinnvoll ist bekomme ich aber keine. Gerade der erste Punkt mit dem lesenden Zugriff auf die Out-Variable eines FB nervt. Wenn ich keine Warnmeldung beim Übersetzen bekomme, muss ich jetzt immer zusätzlich eine stat-Variable anlegen und dann am Ende umkopieren. Ich habe gerade einige Bausteine von der S7-300 auf die 1500er umgeschrieben wo ich das so machen musste. Das benötigt unnötig Speicher und Code, bläht den Code unnötig auf und führt ggf. zu Problemen bei parallelem Zugriff vom HMI.

Was ist die Lösung: Warnungen abschalten?

 

[ducati]

bei den TEMP ist es wohl so, dass die zumindest bei optimierten FC/FB und 1500 nicht mehr undefiniert sind.
Das mit dem Lesen von OUT-Paramtern ist zB bei FCs ganz boese, wenn da an mehreren OUTs die gleiche Variable verschalten wird. DiesesVerthalten ist auch noch von FB zu FC und abhaengig vom Variablentyp unterschiedlich, so dass man das wirklich lieber unterlassen sollte...

PS: also diese Call by Value / Call by Reverence Geschichte...

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bei einem FC sehe ich das ja ein, aber bei einem FB nicht.
Selbst bei InOut könnte der Compiler prüfen ob es sich um einen elementaren Typ handelt, er hat ja schließlich alle Informationen und weiß auch welchen Code er generiert.

Und wenn schon Warnungen, warum bei identischen Code in SCL und FUP völlig verschiedene Warnmeldungen?
Wenn ein FB-Out in SCL möglicherweise nicht initialisiert ist, ist er es dann etwa nicht in FUP?
Und ist der Lesende Zugriff in SCL empfehlenswert, wenn er es in FUP nicht ist?

Fragen über Fragen, das soll mir Siemens mal beantworten.
Auch wenn Temp mit 0 initialisiert werden ist es doch meistens ein Fehler oder zumindest eine Schlampigkeit. Hier wäre zumindest eine Warnung angebracht. Ist die Frage ob das bei der S7-300 eine Warnung generiert.

Nur wie geht man damit um? Um den Siemens Unfug herumprogrammieren nur damit keine sinnlosen Warnmeldungen mehr kommen?

 

[ducati]

Fragen über Fragen

Nur wie geht man damit um?

Naja, da man eh nix genaues weiss, bzw. ich auch nicht immer die Zeit habe, das alles auszuprobieren mach ich das konkret für die 2 Fälle so:

Temp immer beschreiben, bevor ich lese.

OUT intern im Baustein nie lesen.


Aber generell gabs ja auch schon den Fall, dass in ner alten TIA V13 irgend ein Programmierausdruck als Warnung angesehen wurde und in TIA V14 als Fehler, so dass Du ohne Änderung nicht mehr Laden konntest. Das setzt dem Ganzen noch die Krone auf...

Den ganzen Compiler hätten die viel länger Testen sollen, evtl. auch mal an richtigen Anlagen, bevor die das auf den Markt werfen. Aktuell ist das TIA nicht besser als Classic, eher schlechter/verwirrender/komplizierter...

Gruß.

 

[Thomas_v2.1]

Bei der Erkennung von Gleitkommazahl-Konstanten gibt es auch eine Inkonsistenz. Denn mal nimmt der Compiler wohl an, das sei eine LREAL Konstante (also 64 Bit), und mal eine REAL (32 Bit).

#realVar := SEL(G := #boolVar, IN0 := 0.0, IN1 := 100.0);
--> Warnung: Die Genauigkeit des Wertes kann verlorengehen

#realVar := SEL_REAL(G := #boolVar, IN0 := 0.0, IN1 := 100.0);
--> Warnung: Die Genauigkeit des Wertes kann verlorengehen

#realVar := SEL(G := #boolVar, IN0 := 0.0, IN1 := 100.0);
--> Warnung: Die Genauigkeit des Wertes kann verlorengehen

#realVar := 100.0;
--> Keine Warnung

#realVar := SEL(G := #boolVar, IN0 := REAL#0.0, IN1 := REAL#100.0);
--> Keine Warnung

#realVar := SEL_REAL(G := #boolVar, IN0 := REAL#0.0, IN1 := REAL#100.0);
--> Keine Warnung

Warum wird 100.0 im SEL-Aufruf als LREAL erkannt, bei der Zuweisung aber allem Anschein nach als REAL?
Die IEC-Prüfung ist im Baustein aktiviert.

 

[RONIN]

Zuviel Werbung?
-> Hier kostenlos registrieren

#realVar := SEL(G := #boolVar, IN0 := 0.0, IN1 := 100.0);
--> Warnung: Die Genauigkeit des Wertes kann verlorengehen

Das hab ich auch nicht durchschaut, brauch auch des öfteren ein scheinbar unnötiges LREAL_TO_REAL()...

Mit dem OUT-lesen stimme ich zu. Geht mir voll auf die Nerven immer extra Datenpunkte mitzuschleppen.
Wahrscheinlich kommt das von den neuen tollen IEC-Timern. Da hat das lesen des OUT ja jedesmal eine Konsequenz...

 

[Thomas_v2.1]

Das hab ich auch nicht durchschaut, brauch auch des öfteren ein scheinbar unnötiges LREAL_TO_REAL()...

Oder halt REAL# oder LREAL# als Typspezifizierer.
Wenn jede Gleitkommazahl vom Compiler als LREAL erkannt würde, dann müsste die Warnung wenn man es genau nimmt auch bei der Zuweisung einer solchen Kostante auf eine Variable von Datentyp REAL erscheinen.

Darum auch mein Test mit SEL_REAL() die ja explizit den Typ REAL und nicht LREAL zurückgeben. Also scheint es so, also ob doch die Konstante als LREAL erkannt wird man aber die Warnung bei einer einfachen Zuweisung irgendwie manuell unterdrückt hat.

 

[Thomas_v2.1]

Die Warnung stammt so wie es aussieht daher, dass SEL_REAL() dem Namen nach zwar ein REAL zurückgeben sollte, es aber in Wirklichkeit ein LREAL zurückgibt wenn der Compiler gerade Lust dazu hat (ich vermute da schlägt trotz der Typisierung irgendeine automatische Erkennung zu). Denn mit

#realVar := LREAL_TO_REAL(SEL_REAL(G := #boolVar, IN0 := 0.0, IN1 := 100.0));

lässt sich die Warnung auch beseitigen.

Und in FUP gibt es mal wieder überhaupt keine Warnmeldung wenn ich dort einen Selektor mit gleichen Parametern wie aus dem SCL-Beispiel verwende.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wird ja immer besser. Bei Siemens hat eine 32 Bit Gleitkommazahl anscheinend 17 signifikante Stellen und nicht ungefähr 7.

#realVar := 0.12345678901234567; // keine Warnung
#realVar := 0.123456789012345678; // Warnung

 

[ducati]

tritt das Prob nur in SCL auf oder auch in AWL?

 

[Thomas_v2.1]

tritt das Prob nur in SCL auf oder auch in AWL?

In AWL sind Warnungen ja generell nicht sehr sinnvoll, da ich mit L/T einen String oder Char auf eine REAL-Variable transferieren kann, ohne dass es eine Warnung oder Fehlermeldung gibt. Das liegt in der Eigenschaft der Sprache, dass dort nichts geprüft werden kann.

Aber diese Warnmeldungen die da jetzt generiert werden, sind doch durchgehend unbrauchbar weil teilweise einfach falsch und inkonsistent.
Und um diese Warnmeldungen soll ich jetzt herumprogrammieren? Ich glaube ich deaktiviere die Option bis sich da bei Siemens mal jemand mit Verstand dransetzt.

In einem anderen Thread meinte jemand, in einem Nicht-Optimierten Baustein sind Temp-Variablen im Gegensatz zu denen in Optimierten nicht mit Null initialisiert. Und da gibt es auch keine Warnungen wenn ich diese verwende ohne dieser Variable vorher einen Wert zuzuweisen.

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

ist das wirklich nur ein Problem mit den Warnungen, oder steckt da noch nen Bug in der SPS-Firmware???

 

[ducati]

Im AWL sieht's so aus:

L 0.1234567890123456
T #Wert_real

ist gültig, wird im Tooltip als LREAL angezeigt. Wenn ich dass aber nem REAL zuweise, geht die Genauigkeit verloren, ansonsten stimmt der Zahlenwert aber gerundet.

L #LREAL0.1234567890123456

ist bei nichtoptimierten FCs gleich rot und funktioniert so nicht...

naja, schon komisch das ganze...

 

[Thomas_v2.1]

Im AWL sieht's so aus:

L 0.1234567890123456
T #Wert_real

ist gültig, wird im Tooltip als LREAL angezeigt. Wenn ich dass aber nem REAL zuweise, geht die Genauigkeit verloren, ansonsten stimmt der Zahlenwert aber gerundet.

Das kann eigentlich nicht funktionieren, denn ein LREAL hat 11 Bits für den Exponent, ein REAL aber nur 8. Dementsprechend sind auch die Mantissenbits verschoben.
Zumindest kann dann in der REAL Zahl nicht der gleiche Wert stehen, außer TIA fügt da eine (unsichtbare) Konvertierung ein.

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

außer TIA fügt da eine (unsichtbare) Konvertierung ein.

Jo, deshalb hab ich das ja heute für AWL gleich getestet, mir war da schon ganz schlecht

AWL wird ja bei der 1500er auch compiliert, von daher wird da der Compiler da ne Art Datentypkonvertierung machen...

 

[Thomas_v2.1]

Was für eine TIA Version verwendest du denn?
Bei V14 SP1 kann ich LReal Variablen in AWL überhaupt nicht verarbeiten. Wenn ich 0.1234567890123456 eingebe kürzt der Editor das gleich zu 0.1234568 zusammen.

 

[ducati]

V13sp1.....

 

[RONIN]

Zuviel Werbung?
-> Hier kostenlos registrieren

Scheint so als wäre das Verhalten für V14 geändert worden.
Bei v13 ist noch eine Eingabe von 0.123456789... möglich, bei v14 nicht mehr.

Insofern eh sinnvoll, damit wäre zumindest theoretisch klar dass LREAL-Konstanten nur als solche angenommen werden sollten wenn der Präfix vorne dran steht.
Dann sollte es aber eindeutig sein und die Compilerwarnungen ausbleiben...