Conversion WORD o REAL
It is about the problem of converting a WORD variable into a REAL variable:
With the help documents of PLCnext Engineer, the TO-REAL function block can convert a DWORD variable into a REAL value. This works correctly for a fixed DWORD number at the input (also for a WORD variable, why also for WORD??).
If you convert the WORD variable with a TO_DWORD function block and connect the output of TO_DWORD with the input of TO_REAL, in this case there is an incorrect REAL value at the output of TO_REAL.
If a TO_DINT function block is used (instead of TO_DWORD) to convert the WORD, the result is correct.
Why does the upstream WORD -> DWORD conversion not work together with the TO_REAL?
In the attachment is a test code to explain the problem.
Many thanks
Reinhard
[attachment]WORD_REAL_question.jpg[/attachment]
With the help documents of PLCnext Engineer, the TO-REAL function block can convert a DWORD variable into a REAL value. This works correctly for a fixed DWORD number at the input (also for a WORD variable, why also for WORD??).
If you convert the WORD variable with a TO_DWORD function block and connect the output of TO_DWORD with the input of TO_REAL, in this case there is an incorrect REAL value at the output of TO_REAL.
If a TO_DINT function block is used (instead of TO_DWORD) to convert the WORD, the result is correct.
Why does the upstream WORD -> DWORD conversion not work together with the TO_REAL?
In the attachment is a test code to explain the problem.
Many thanks
Reinhard
[attachment]WORD_REAL_question.jpg[/attachment]
Comments
The behaviour you show is as expected.
Firstly, here are the categories of generic data types (from the PLCnext Engineer help), which will be referenced below.
Here are the conversion rules for the TO_REAL function block (with numbers added by me):
The first two examples, on the top line of your screen shot, do not have DWORD and WORD inputs. They are UDINT and UINT inputs, in hexadecimal format. You can see that the conversion is the same when you explicitly specifiy UDINT and UINT before the values:
Since these are all ANY_INT variables, the conversions are correct according to rule 2 in the above table.
If you mean "why for an INT" - why not? Every possible INT value can be converted to a REAL value, so this is allowed.
The second line of your screen shot is not converting a WORD to DWORD, it is converting a UINT to DWORD. The TO_REAL conversion in this case is also correct according to rule 5 in the above table. The conversion of ANY_BIT values - like DWORD - is done by interpreting the value as bits in IEEE 754 format. Using an IEEE 754 converter, you can see that the bit pattern 0x7fff (padded with leading zeros) equals 4.59163467805e-41, which is what you are seeing.
The final line of your screen shot is not converting a WORD to DINT, it is converting a UINT to DINT. As seen above, the TO_REAL conversion is also correct according to rule 2 in the above table.
Summary:
a) To avoid confusion, it is best to specify the data type of numeric literals - e.g. WORD#16#7fff when you want a WORD, and UINT#16#7fff when you want a UINT. Then, it will be clear if you are working with an ANY_BIT or an ANY_INT value.
b) The TO_REAL conversion rules are different for ANY_BIT and ANY_INT values, as described in the PLCnext Engineer help.
Hope this helps.
~ Martin.