V4006

Code

V4006

Message

String is not convertible to the target numeric type

A STRING_TO_<numeric> conversion received a string that is not convertible to its target type, and the program was compiled with the trap failure policy (the default). The message names the target type and the offending string.

A string is not convertible when it is not a numeric literal under the selected non-numeric policy (for example '12abc' under reject), or when it is a literal whose value does not fit the target type (for example '4294967296' for UDINT, '300' for SINT, or '1e39' for REAL, whose magnitude rounds to infinity). A value that does not fit is never wrapped, and no conversion produces an infinity or a NaN. STRING_TO_BYTE, STRING_TO_WORD, STRING_TO_DWORD and STRING_TO_LWORD convert as USINT, UINT, UDINT and ULINT, so the message names the unsigned integer type. The message shows the first sixteen characters of the string. See Type Conversions for what each policy accepts and the range of each target.

Example

The following code will generate error V4006:

PROGRAM Main
VAR
    text : STRING := '12abc';
    value : UDINT;
END_VAR
value := STRING_TO_UDINT(text);  (* Error: '12abc' is not a UDINT literal *)
END_PROGRAM

The string '12abc' has characters after the digits, so under the default reject policy it is not convertible, and the default trap policy halts the program rather than producing a number the program did not ask for.

To fix this error, convert only strings the program knows are literals of the target type, or select the behavior policy that matches the platform the program was written for. A program written for CODESYS or TwinCAT expects the leading digits and a zero on failure; compile it with --dialect codesys or --dialect twincat, or select the policies directly:

ironplcc compile --policy-string-to-num-non-numeric ignore-trailing \
                 --policy-string-to-num-failure zero \
                 -o main.iplc main.st

The policies are described in Enabling Dialects and Features.

Think IronPLC is wrong about this?

If you believe this diagnostic is incorrect, open an issue on GitHub with a small sample that demonstrates the problem.