Missing conversion functions

[volsa]

Some missing conversion functions taken from an internal document:

• STRING_TO_BYTE
• USINT_TO_BOOL
• USINT_TO_BOOL
• SINT_TO_STRING
• INT_TO_BOOL
• INT_TO_STRING
• DINT_TO_BOOL
• STRING_TO_DWORD
• STRING_TO_TIME
• STRING_TO_DT
• STRING_TO_SINT
• STRING_TO_INT
• LREAL_TO_DWORD
• TRUNC

[ghaith]

We need to define the exact behaviour of some of these functions. For example INT_TO_STRING would just be an alias for DINT_TO_STRING but LREAL_TO_DWORD is very strange to me, are we reading the LREAL value into a DINT and converting it to DWORD or are we reading the binary representation of the LREAL, in which case it does not fit in a DWORD and needs an LWORD, so LREAL_TO_DWORD should in that case not be supported.

[tisis2]

IEC61131-3 6.6.2.5.3 see the tables e.g. for LREAL_TO_DWORD its defined that it is a binary transfer of the bits on the right side

[ghaith]

IEC61131-3 6.6.2.5.3 see the tables e.g. for LREAL_TO_DWORD its defined that it is a binary transfer of the bits on the right side

LREAL_TO_LWORD ist defined but LREAL_TO_DWORD is not only REAL_TO_DWORD at least in table 25. The problem with a binary transfer between LREAL and DWORD is that the result is not something you could use due to the internal representation of an LREAL. For example 1.0 in LREAL is 00111111 11110000 00000000 00000000 00000000 00000000 00000000 00000000 if we convert it to DWORD, it is just 0 same for 2.0, 3.0 .. (see https://www.binaryconvert.com/convert_double.html) LINT_TO_DWORD is defined as a binrary transfer because it just causes the loss of the left most bits.

[tisis2]

you are right i think i mixed it up with other conversions