Grundrechenarten lassen sich nicht übersetzen

[SLe]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich habe ein laufendes Programm von einer ILC150ETH auf eine ILC350PN übertragen.
Dabei kam beim Übersetzen der Fehler, dass sich Grundrechenarten mit WORD-Variablen nicht übersetzen lassen. ("prozessorspezifischer Codegenerator")
Also z.B. WORD#A * WORD#B
Ich habe alles auf INT umstellen müssen und dann lief es. Gibt es eine andere Möglichkeit?

 

[Larry Laffer]

Nein - es gibt keine andere Möglichkeit.
BYTE, WORD und DWORD sind nur "Bit-Speicher" - die lassen sich vergleichen, verknüpfen (AND , OR , XOR) oder zuweisen. Rechnen kann man damit nicht.

Gruß
Larry

 

[SLe]

Zuviel Werbung?
-> Hier kostenlos registrieren

Warum geht es dann mit einer ILC 150Eth? Und warum gibt die Hilfe von PCWorx die Möglichkeit an?
Ist das nicht in der IEC61131 verankert?

 

[RONIN]

Warum geht es dann mit einer ILC 150Eth? Und warum gibt die Hilfe von PCWorx die Möglichkeit an?
Ist das nicht in der IEC61131 verankert?

Eigentlich ist es schon in der IEC verankert, anscheinend hält sich auch Codesys nicht immer daran
PN/DP hatte das in einem ähnlichen Thema schon mal schön erklärt.

Das Problem ist: beim Speichern des DWORD in einen REAL darf der Wert des DWORD nicht konvertiert/verändert werden, weil es schon einen REAL enthält, Codesys tut es aber, weil es DWORD = UDINT gleichsetzt, was nach meiner Meinung ein Designfehler ist, der aber nun anscheinend nicht mehr beseitigt werden kann (oder nicht soll), weil es bereits tausende Programme gibt wo dieses dokumentierte Verhalten dummerweise genutzt wird.


Empfehlung nach IEC 61131-3
UDINT ist ein Datentyp = unsigned double INT = Ganzzahl 0 bis 4294967295
Nach IEC 61131-3 gehört UDINT zur Gruppe der generischen Datentypen ANY_NUM, Untergruppe ANY_INT. ANY_INT kann man in Ganzzahl-Rechenoperationen direkt verwenden.
DWORD ist eine Bitfolge (Bitstring) von 32 Bit, die 4 Byte Speichergröße belegt. Egal was für ein Datentyp in dem DWORD abgelegt ist, es wird nicht interpretiert. Codesys behandelt aber: DWORD = UDINT
Nach IEC 61131-3 gehört DWORD zur Gruppe der generischen Datentypen ANY_BIT. Mit ANY_BIT kann man nicht rechnen, nur vergleichen, ob der Wert 0 oder <> 0 ist. Wenn man mit ANY_BIT rechnen will, dann müsste man immer erst den ANY_BIT in einen ANY_NUM typecasten (übernehmen, z.B. WORD_TO_INT), was lästig ist und zum nachdenken und verstehen zwingt. Und vielleicht deshalb von Codesys für die Bequemlichkeit der Programmierer ANY_BIT = unsigned ANY_INT als gleichwertig festgelegt wurde?
Harald

#WORD_A * WORD_B sollte also korrekterweise nicht zugelassen sein.
Welche Steuerung sich dran hält und welche nicht, ist eine eigene Sache.

 

[Phoenix Contact]

Hallo,

Das liegt an den unterschiedlichen Targets. Die ILC 1xx Arbeitet mit eCLR und ILC 3xx mit ProConOs.
Leider unterstütz das ProConOs System kein bitweises Zählen, hier muss leider mit Beispielsweise int gerechnet werden.
Gruß Uwe

 

[SLe]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke an alle für die hilfreichen Antworten!