# Codesys Datatypes INT vs WORD



## pawel12345 (2 Juli 2019)

Hallo,

ich lese gerade das Buch "PLC controls with ST" und habe gelesen, dass der INT im Vergleich zum WORD ein rapide Datentyp ist ( rapid data type ). Bedeutet das, dass der Zugriff auf die INT- Daten schneller ist?


----------



## holgermaik (2 Juli 2019)

Ein INT ist eine Ganzzahl mit 16bit. Ein Word ist eine Ansammlung von 16bit. Einen Vergleich halte ich für sinnlos.


----------



## Heinileini (2 Juli 2019)

pawel12345 schrieb:


> ich lese gerade das Buch "PLC controls with ST" und habe gelesen, dass der INT im Vergleich zum WORD ein rapide Datentyp ist ( rapid data type ).


Bei den beiden Datentypen sind lediglich unterschiedliche Operationen mit dem Inhalt des Wortes zulässig.
Eine evtl. Auswirkung auf die Ausführungszeit kann man nicht wirklich ausschliessen.
Wenn ein HochsprachenProgrammierer den Compiler gebastelt hat (sehr wahrscheinlich), hat er die (logischen) Operationen, die bei WORD zulässig sind, mit Sicherheit sooo umständlich realisiert, dass sie um GrössenOrdnungen länger brauchen.

Wer mal gesehen hat, wie früher die SiemensStandard-FBs (in S5) für DUALinGRAY und GRAYinDUAL programmiert waren, versteht wahrscheinlich meine Skepsis und meinen Sarkasmus an dieser Stelle.
Wären die o.g. Siemens-FBs "geradeaus" programmiert worden, wäre auch die Beschränkung auf 15-Bit-Zahlen nicht erforderlich gewesen.

Gruss, Heinileini


----------



## StructuredTrash (2 Juli 2019)

Codesys ist in dem Punkt ja deutlich pragmatischer als die IEC-Norm. Man kann mit einem INT oder UINT auch logische Verknüpfungen ausführen und umgekehrt mit einem WORD auch arithmetische. Bei einem UINT gibt es dabei noch nicht einmal eine Warnung wegen einer impliziten Typumwandlung. Ich gehe deshalb davon aus, dass diese Typen intern gleich behandelt werden.


----------



## oliver.tonn (3 Juli 2019)

StructuredTrash schrieb:


> Codesys ist in dem Punkt ja deutlich pragmatischer als die IEC-Norm. Man kann mit einem INT oder UINT auch logische Verknüpfungen ausführen und umgekehrt mit einem WORD auch arithmetische. Bei einem UINT gibt es dabei noch nicht einmal eine Warnung wegen einer impliziten Typumwandlung. Ich gehe deshalb davon aus, dass diese Typen intern gleich behandelt werden.


Was aber nicht unbedingt positiv zu sehen ist, da man dadurch zur Nachlässigkeit erzogen wird. Ich hatte nämlich immer mit BYTE, WORD, usw. gerechnet ohne mir Gedanken darüber zu machen und war dann ganz erstaunt, dass das eigentlich so nicht korrekt und bei anderen Steuerungen nicht möglich ist.


----------



## StructuredTrash (3 Juli 2019)

Du hast mit WORDs gerechnet?! Ich schicke Dir die heilige IEC-Inquisition auf den Hals! 
Die Frage ist, was man nun negativ sehen soll: Die Lässigkeit von Codesys oder die Engstirnigkeit der Norm?
Wenn ich mehrere Bits in ein BYTE oder WORD packe, dann will ich doch gerade mit arithmetischen Operationen auf mehrere Bits gleichzeitig zugreifen können.
Und umgekehrt bilde ich mir ein, dass auch heute noch ein "Zahl:=Zahl AND 16#03;" schneller ist als "Zahl:=Zahl MOD 4;".


----------



## Heinileini (3 Juli 2019)

StructuredTrash schrieb:


> Du hast mit WORDs gerechnet?! Ich schicke Dir die heilige IEC-Inquisition auf den Hals!
> Die Frage ist, was man nun negativ sehen soll: Die Lässigkeit von Codesys oder die Engstirnigkeit der Norm?
> Wenn ich mehrere Bits in ein BYTE oder WORD packe, dann will ich doch gerade mit arithmetischen Operationen auf mehrere Bits gleichzeitig zugreifen können.
> Und umgekehrt bilde ich mir ein, dass auch heute noch ein "Zahl:=Zahl AND 16#03;" schneller ist als "Zahl:=Zahl MOD 4;".


Das erweckt den Eindruck, dass Du den Begriff "arithmetische" Operationen (Addition, Subtraktion, Multiplikation, Division und Modulo, VorzeichenWechsel alias ZweierKomplentBildung, . . .) ziemlich weit fasst und damit auch die sogenannten "logischen" Operationen (Und, Oder, ExclusivOder, alle Bits Umkehren alias EinerKomplementBildung) einschliesst? "Sogenannte" habe ich gesagt, damit man nicht auf die Idee kommt, die anderen - z.B. arithmetischen - seien unlogisch.
Ich wäre eher geneigt, die Schiebe- und Rotier-Operationen zu den logischen zu zählen, als z.B. UND zu den arithmetischen.

In den "guten alten Zeiten" musste man "nur" wissen, was die verschiedenen Operationen mit den Bits anstellen. Heute muss man zusätzlich wissen, welchen DatenTyp man der Ansammlung von Bits künstlich überstülpen muss, damit der Compiler sein Einverständnis für die gewünschte Operation geben oder verweigern kann.
An der Auswirkung der Operationen ändert das rein gar nichts, nur, man muss länger tüfteln, bis man dem Compiler dies klar gemacht hat. 
Wenn dann aber die dafür erforderlichen KonvertierFunktionen nach nicht zu rechtfertigenden Regeln arbeiten und durchaus Zulässiges unmöglich machen, so dass für einfachste Verknüpfungen umständliche WorkArounds gebastelt werden müssen (StichWort: höchstwertiges Bit), dann hört der Spass auf.
Was ist denn dann im EndEffekt wirklich übersichtlicher, verständlicher, leichter nachzuprüfen, leichter erlernbar???

Gruss, Heinileini


----------



## StructuredTrash (3 Juli 2019)

Nein, mit "logisch" meinte ich schon AND, OR, XOR und Kollegen. Und die sind eben laut IEC-Norm nur für Bitfolgetypen BYTE, WORD usw. erlaubt, aber nicht für die Integertypen.


----------



## pawel12345 (4 November 2019)

Danke für alle Antworten !


----------

