dl-breadcrumbs__homedl-breadcrumb-item__separatorConfiguration and programmingdl-breadcrumb-item__separatorProgramming with CODESYSdl-breadcrumb-item__separator...dl-breadcrumb-item__separatorCODESYS Development Systemdl-breadcrumb-item__separatorDownloading an Application to the PLCdl-breadcrumb-item__separatorGenerating Application Code
dl-pagination__prev-inactivedl-pagination__prev-activedl-pagination__next-inactivedl-pagination__next-active
Generating Application Codedl-permalink__symbolPermalink

The application code is the machine code that a PLC executes when you start an application.

CODESYS automatically generates the application code from the source code that was written in the development system. This is done automatically before downloading the application to the PLC. Before the application code is generated, a test is performed for checking the allocations, the data types, and the availability of libraries. Moreover, the memory addresses are allocated when the application code is generated.

You can click “Build  Generate Code” to execute this command explicitly. This is useful for detecting any errors in your source code, even when the PLC is not connected yet. The errors are output in the message view in the "Build" category.

NOTICE

NOTICE
NOTICE
NOTICE

NOTICE

NOTICE

If you have encrypted the application, then consider the following information: If a (new) boot application is generated on request after an online change, then the boot application is formed in the RAM with the current code that is not encrypted.

Explicitly generating the application code

Requirement: The application can be compiled without any errors.

  1. Click “Build  Generate Code”.

    The application code is generated. Detailed information about memory allocation is output in the message view.

Messages when generating the application code

When you generate the application code, CODESYS outputs information about memory allocation in the message view. Gaps form in the memory because reallocation is only for new and changed POUs and variables due to the incremental memory build. Online changes have the same effect. This fragmentation reduces the amount of available memory. However, you can completely reallocate the memory by clicking “Clean” and therefore increase the amount of free memory.

Syntax errors and bugs that CODESYS detects during the code generation and memory allocation are also output in the message view (“Build” category).

Output information about memory allocation:

  • “ Size of the generated code” (in bytes): Sum of all code segments

  • “Size of global data” (in bytes): Total memory used by the global variables. Inputs and outputs are not included unless inputs or outputs are mapped in the area of the global variables.

  • “Total allocated memory size for code and data” (in bytes): The total allocated memory is composed of the already used memory areas plus the reserved, not yet used memory for incremental builds and online changes. After the first build, the already used memory is approximately equal to the highest used address (see below). The largest contiguous memory gap (see below) still corresponds approximately to the difference to the total allocated memory. However, as the number of incremental builds and online changes increases, the number of memory gaps also increases, and the largest contiguous memory gap becomes smaller.

  • “Memory area <n>”: Contents of the individual reserved memory areas

    Background: It depends on the PLC which data and code is stored in which memory areas. For example, code and data are located in the same area on the CODESYS Control Win V3. For the addresses ‎%I‎, ‎%M‎, and ‎%Q‎, memory is always reserved, even when a variable is not assigned to an address. After cleaning the application, the memory is reallocated completely. In this case, small gaps could result from the predefined alignment (normally 8). Larger gaps result from changing a date without cleaning, for example by increasing an array area. In this case, only the affected POUs are recompiled. Furthermore, in the case of an online change, the memory is used only for new variables and new code. Memory that was previously reserved by deleted variables and code is made available again. As a result, memory fragmentation can occur after many incremental builds and online changes. This creates many small gaps that might not be usable at all in some cases. To clarify how much memory is safely available, the "largest contiguous memory gap" of the memory area is output during code generation.

    • “highest used address” (Byte) : This is the highest reserved address in the entire allocated memory area. During the first build after a "Clean" operation, the memory addresses are output to variables in ascending order, taking into consideration the alignment (usually 8 bytes). As a result, the highest address used at this time corresponds approximately to the amount of memory used. The rest of the allocated memory area is still completely available for incremental builds and online changes.

    • “Largest contiguous memory gap” (in bytes): This is the memory size that is available for backup.

      Resulting gaps in the allocated memory are reused whenever possible for other changes. When, for example, a global variable of type ‎Byte‎ is added, it is placed in the first free byte of the memory. Even just a small gap is enough for this. However, an FB instance, a variable of the type structure or array, or the code for a POU has to be stored contiguously and therefore occupies more memory accordingly. As a result, they can be allocated only to the largest contiguous memory area. This is why during code generation the "largest contiguous memory gap" that is safely available is output (in bytes), as well as its percentage of the total memory.

Note the options for generating applications.

Encrypting the application code