dl-breadcrumbs__homedl-breadcrumb-item__separatorConfiguration and programmingdl-breadcrumb-item__separatorProgramming with CODESYSdl-breadcrumb-item__separator...dl-breadcrumb-item__separatorAutomation Builderdl-breadcrumb-item__separatorProgramming of Applications dl-breadcrumb-item__separatorTask Configuration dl-breadcrumb-item__separatorMulticore
dl-pagination__prev-inactivedl-pagination__prev-activedl-pagination__next-inactivedl-pagination__next-active
Multicore dl-permalink__symbolPermalink

With the CODESYS Multicore feature, the IEC tasks themselves can be assigned to dedicated CPU cores, taking the acquired number of CPU cores into account. This can result in improved performance.

  • The IEC task is executed on all CPU cores:

    The operating system takes control of distributing one or more tasks of a group on the CPU cores.

When the IEC tasks are distributed over CPU cores, some changes result in the behavior in the IEC program, which have to be considered.

  • The processing of IEC tasks by priority is no longer a given. They are processed by priority only if the tasks are bundled together to one CPU core.

  • The cycle consistency of the data in the IEC task with the highest priority is no longer a given. Therefore, the data has to be copied locally at the beginning of the IEC task cycle if the values should not change during the cycle.

  • For all tasks, there is a shared process image from which the tasks operate. The ‎ReadInputs()‎ function is called at the start of each task and the ‎WriteOutputs()‎ function is called at the end. As a result, the IPO model applies for each task individually. These functions read and write to the shared process image. The process image is also physically written and the packets transmitted only when the bus cycle task is called. However, the bus cycle task waits for each call of ‎WriteOutputs‎ and ‎ReadInputs‎ of the tasks. This ensures the data consistency within the bus cycle task.

    • Outputs can be assigned only to one task.

    • Inputs can be assigned to multiple tasks, but direct access should be avoided. The inputs have to be written to local variables of the task by means of atomic operations.

    • A second task, which updates the process image with ‎ReadInputs()‎ in parallel to the first task, also updates the inputs of the first task while it is running.

    • As a result, the data consistency of a task is ensured only on single cores for the highest priority task.

    Note: You can set the bus cycle task on the “PLC Settings” tab.

    Note: You can display the I/O access on the Tab: Task Deployment.

  • For consistent counters (incrementer, decrementer), the atomic external library function ‎SysCpuAtomicAdd()‎ should always be used (for more details, see ‎SysCpuHandling.library‎).

Data consistency

Data consistency

  • Bit access (data type ‎BIT‎) is not processed consistently (atomically) on multicore CPUs in the IEC program. For this we recommend that you use the external library function ‎SysCpuTestAndSetBit()‎. (For details, see: ‎SysCpuHandling.library‎)

  • Simple data types up to a width of 32 bits (‎BOOL, BYTE, WORD/INT, DWORD/DINT‎, etc.) are processed consistently (atomically) in the IEC program on multicore CPUs as well.

  • Data types with 64 bits (‎LINT, LWORD‎, and ‎LREAL‎) are processed consistently (atomically) in the IEC program on 64-bit systems and multicore systems only. To do this, you do not need to take any precautions.

  • To access complex data types (‎STRING, FB, STRUCT‎, and ‎ARRAY‎), you need to make arrangements yourself for the synchronization/consistency.

  • In the task configuration, on the Variable Usage tab, you can define whether a variable in an IEC task has read or write access.

  • On multicore systems, a "memory reordering effect" can occur. For more information, see: IEC Operator: ‎__MemoryBarrier()‎.

  • Distributing tasks over multiple processor cores
  • Displaying the processor load per processor core in the trace