“Type not allowed in EVL” SIL2 error may occur when CODESYS 3.5 SP10 application code is generated (Build> Generate code).

This will happen if an application's global variable list is defined as non-safety using location attribute 0x800 and an instance of a non-safety library function block (FB) or STRUCT is declared.

This is caused by a non-safety function block (FB) implementing an interface (e.g. CANVXD or CANopen).

See the example below.

A workaround is to use a global variable list which does not define a non-safety location attribute. The CODESYS compiler will automatically detect that the function block (FB) is implemented in a non-safety library and move the instance to non-safety memory during code generation. SIL2 extension’s output gives a message regarding this.

For example, the workaround is used in code template's G_CANopen_CAN1 global variable list.

Note that non-safety global variables of basic data types still need to be defined in a global variable list using the non-safety location attribute (e.g. G_CANopen_CAN1_VAR).

"Type not allowed in EVL" error is also given when a safety library’s function block (FB) instance is defined in a global variable list using the non-safety location attribute. A workaround is to define the function block (FB) instance to a non-safety program where the instance is used.

When an unsigned 32-bit variable's value is compared with "greater than zero" using a constant 0 value, the comparison  returns as FALSE even though it should be TRUE.

This applies at least to data types UDINT, DWORD and TIME when the  variable value is greater than the signed 32-bit data type's (DINT) positive maximum value (2147483648...4294967295). See the example below.

This does not apply when comparing two variables to each other.

A workaround for this is to always use "not equal to zero" comparison with UDINT, DWORD and TIME variables.

CODESYS 3.5 SP10 Function Block Diagram (FBD) editor does not correctly detect all SAFE type variables used in POU interface. This will result in a red background color in the variable assignment even if the correct type of variable is used.

The following example of this error uses the EPEC_SPVC.S_CurrentRequest function block. This issue is cosmetic and does not affect the code compilation.

CODESYS 3.5 SP10 sometimes gives an unhandled exception error popup when opening a project.

This is caused by leaving POUs open containing safety code when the project is saved.

Close all POUs before saving a project, to avoid this error.

A workaround for this error is to press the Continue.

CODESYS IDE may behave differently depending on the project or PC:

• In some cases Continue needs to be pressed several times

• In some cases it is required to click on CODESYS IDE (behind the popup) and then press Continue

This error does not affect the project or code.

When logging in to a safety control unit with CODESYS 3.5 SP10, the user name and password are required. On the first login CODESYS asks for the password again even if the password was correct.

Type the user name and password again to login.

CODESYS 3.5 SP10 Generate code compilation will crash in the following case:

• structA has a member varX with type POINTER TO structB

• structB has a member varY with type POINTER TO structA

• Application defines variable instances for structA and structB in non-safety memory (e.g. Global Variable List).

A workaround for this is to use POINTER TO BYTE and then assign a variable to the correct pointer type in code implementation.