xx:=16#11220000 OR (WORD_TO_DWORD (ROR(16#4433,8)) AND 16#0000FFFF);

xx2:=16#11220000 OR (WORD_TO_DWORD (ROR(16#4433,8)) );

xx=16#11223344

xx2=16#11663344 ---- Why?

CoDeSys 2.3.9.16

that is because the result of the ROR is a word in the first line and in the other line unknown (not really but it is rolled over in a dword

you are doing wrong as you should always use a variable even when used only once, now the system does not know if it is a word or a byte or whatever.

it has another advantage too, you can not change constants while running but variables you can.

That might be the case what happens, but if you consider the description in the help file (for ROR), it doesn't seem correct:

Zitat:
Please note, that the amount of bits, which is regarded for the arithmetic operation, is pretended by the data type of the input variable !. If the input variable is a constant the smallest possible data type is regarded. The data type of the output variable has no effect at all on the arithmetic operation.

In other words the result of ROR(16#4433,8 ) is / or should always be a WORD because 'The data type of the output variable has no effect at all on the arithmetic operation.' and the smallest possible data type for 16#4433 is WORD.

yes it is wrong, however as you do not define the length it is your fault.

i repeat always give constants a name and a type

if you are rolling over a byte same happens because of the use of memory.

I wouldn't be so sure...have you actually tried this ?

Zitat:
VAR
TestDWord1:DWORD;
END_VAR
TestDword1:=WORD_TO_DWORD(ROR(WORD#16#4433,8 ));

AND

Zitat:
VAR CONSTANT
abc:WORD:=16#4433;
END_VAR
VAR
TestDWord2:DWORD;
END_VAR
TestDWord2:=WORD_TO_DWORD(ROR(abc,8 ));

Both produce 16#00443344. Which is wrong. And in both cases the length of the constant IS defined. In the second case it is also an explicitly declared constant with a name and I type. So how is this anyone's fault but a bug ?!?