Step 7 Funktionsbausteine Ausgangsparameter

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Thomas,
könntest Du da mal bitte konkreter werden, bei welchen Datentypen das passiert? Wenn ein INT in einen DINT geschrieben wird kann man warnen aber man muss es nicht. Ich sehe das jetzt nicht als so problematisch an.

Du kannst bei Codesys z.B. eine UINT Variable ohne Warnung auf eine INT schreiben. Und die haben einen komplett anderen Wertebereich.
Ist das Ergebnis definiert, oder abhängig von der Zielhardware? Ich weiß es nicht, und in der Codesys-Doku (2.3) kann ich es nicht nachlesen.

Die Datentyp-Klasse ANY_BIT mit BYTE, WORD, DWORD usw. gibt es bei Codesys auch nicht. Man kann diese kreuz und quer Variablen anderen Datentyps zuweisen. Ohne Sinn ist diese Klasse nicht in die IEC-Norm gekommen. Was da im Hintergrund abläuft ist unbekannt, ob WORD als UINT oder was auch immer erkannt wird.

Bei Siemens mit eingeschalteter IEC-Prüfung ist das nicht erlaubt.

Ob man INT auf DINT immer warnen muss meine ich auch nicht, aber solche Konstrukte führen gerne mal zu wahrscheinlich nicht erwünschten Ergebnissen, wenn die Summe der beiden INT den Wertebereich eines INTs überschreiten:
DINT := INT + INT;

Ein C-Compiler gibt dir zumindest eine Warnmeldung (mindestens wenn es Konstanten sind) "integer overflow in expression".

Bei Siemens SCL lässt sich ein:
INT := 32000 + 32000;

nicht übersetzen. Bei Codesys - kein Problem.

 

[oliver.tonn]

Danke für die Rückmeldung, hatte es gerade such selber gesehen. Das sind zugegebenermaßen sehr unschöne Konstrukte.

Von irgendwas mit Internetzugang gesendet.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Eben, es ist schon sehr unschön.
Warnungen kann man ignorieren, noch schlimmer ist es aber wenn das System überhaupt keine Warnmeldungen erzeugt.
Wenn das Ignorieren von Warnmeldungen fahrlässig ist, was ist dann davon zu halten wenn überhaupt keine erzeugt werden?

Mir stößt das nur auf, dass diese Aussage von jemandem kommt der kürzlich behauptet hat "in C werden keine Steuerungen programmiert", aber dann ein System verwendet was mindestens genauso undefiniert ist, überhaupt keine Warnmeldungen erzeugt, und die anderen "gefährlichen" Features von C wie Zeigerarithmetik ebenfalls erlaubt.

 

[RobiHerb]

Initialisierung

Mit was für einem Nicht-IEC-konformen System programmierst du denn da? Denn die IEC61131 gibt die Initialwerte bei elementaren Datentypen vor, und die sind bei INT := 0. Das heißt was du da in deinem Screenshot zeigst ist überflüssig, da in der Norm festgelegt...

Das war das aktuelle Codesys 3.5 SP8 Patch 1 im zitierten Beispiel ein paar Anworten zuvor.

Aber ich habe einige Projekte am Laufen und die betreffen verschiedene Systeme, das sind u.a.

Codesys 3.4,
Codesys 3.2,
Codesys 2.3
Codesys 2.1

TIA seit V.11,

Microsoft Visual C++ 6.0,
Microsoft Visual Studio in allen Versionen von .NET und C# und C++.

Intel PLM zur gelegentlichen Systemprogrammierung.


Und damit ist eigentlich auch schon alles beantwortet, wir initialisieren in unseren Projekten bei der Deklaration jede Variable, somit sind wir sicher, dass das drinsteht, was wir wollen. Wenn ein Kollege oder Reviewer in den Source Code reinschauen muss, der nicht die IEC Norm im Kopf mit herum trägt, weiss er auch sofort, was Sache ist.

Wenn der IEC Compiler diese Variablen sowieso auf den gleichen Wert initialisiert, möge er mir verzeihen und meine Angaben als erledigt betrachten. Compiler von heute sollten das können.

Die Frage, die hier mit angeschnitten wurde, war aber:

Wie bekomme ich die vielen Warnungen in den Griff oder darf ich sie ignorieren.

Eine Flut von Warnungen auf dem Schirm führt dazu, dass man sich dran gewöhnt und die "echten" Warnungen gleich mit übersieht.
Sobald die Projekte grösser werden, hilft nur noch eiserne Disziplin , "KISS (keep it simpel and stupid") und beseitige die Warnungen.

Aus Erfahrung programmiere ich defensiv und weiss, dass noch genug Fallen und Hürden rumgeistern, die das Leben stressig machen.