See also the Codesys OnlineHelp on 'Object: Task Configuration' 

Questions:


Questions:

  • What happens, if the computation time of a task is longer than its cycle time? (Linux, rt_Preempt patched kernel)
  • Does the task list then become longer and longer?
  • Or are these task calls discarded?

Answer:

This does depend on their set priority.

Real-time tasks (0-15):
  • The task is restarted immediately.
  • If the task has calculated longer than twice the cycle time, no attempt is made to make up for all lost cycles, only the last one.
non-real-time tasks (16-31):
  • The lost cycles are discarded.
  • Next start time is the next cycle time in the future.


By the setting

[SysTask]
    Linux.SkipLostCycles=1

the same behavior can be achieved for realtime tasks as for non-realtime tasks.

Questions:

  • What is the difference between 'realtime' ( priority 0-15 ) and 'non-realtime' ( priority 16-31 )?  (Linux, rt_Preempt patched kernel)
  • Are the priorities within the range of 0-15 and 16-31 in principle equivalent? 

Answer:

For example, on a Linux Runtime System:
The Prio setting 0-15 is mapped to the Linux Schedule Policy SCHED_FIFO
The Prio setting 16-31 is mapped to the Linux schedule policy SCHED_OTHER

Prio 0-15 runs in the context of realtime, if your Linux has a rt_Preempt patched kernel.

Question:

For a project with only one task, does it make a difference if the task priority is 0 or 15?  (Linux, rt_Preempt patched kernel)

Answer:

Basically, you always have to observe and consider the whole system. That is important!
The IEC tasks competes with the SystemTask of Linux or those of other applications running on the device.

For example, under Linux:
  • SoftIRQS are scheduled with the SCHED_FIFO/50 priority.
  • The IEC-prio 0 is mapped to SCHED_FIFO/56
  • The IEC-prio 10 to SCHED_FIFO/46.

This means the two priorities behave differently with respect to a high interrupt load.
Tasks with priority 10 are not affected in their runtime behavior, but tasks with priority 10 may be affected.

See also: Mapping of Task Priorities on a Linux System

Questions:

  • Type Freewheeling - what is the definition?
  • How exactly does it work?

Answer:

For multitasking systems that use our full scheduler:
This task does not run in a fixed grid, but puts itself to sleep for a certain time when it has finished calculating.

The minimum "sleep time", which is always ensured by the Runtime, is 1ms, the default "sleep time" is 10ms.

Furthermore, the runtime ensures that all freewheeling tasks together do not cause more than 50% PLC load.
Therefore, the "sleep time" is extended if necessary.

Alternatively, the "sleep time" can also be set via the configuration file.

[CmpSchedule]
   Task.Freewheeling.Cycletime=<time in ms>

Question:

What is the advantage of cyclic-interval to freewheeling?

Answer:

None, In terms of behavior, such a freewheeling task is comparable to a cyclic 10ms task with priority 15-31.

Questions:

  • Regarding Type Status - will the execution occurs once?
  • Or will the execution be done again and again as long as the status is true? 

Answer:

It will occur again and again, as long as the status variable is TRUE.

See also: External Event Task

Question:

What is the difference for Type Status to Event?

Answer:

The event task needs a rising edge FALSE->TRUE of the event variable to run.

Questions:

  • What is the purpose of the Watchdog sensitivity setting
  • How exactly does it work?

Answer:

  • With a Sensitivity of 0 or 1, the watchdog is triggered the first time the WatchdogTime is exceeded.
  • With a sensitivity of <n> the watchdog is triggered when
    • the WatchdogTime was exceeded in <n> consecutive task cycles, or
    • if a cycle has calculated longer than <n> times the WatchdogTime.

This is intended for applications, which can tolerate a single exceeding of the specified time, but not a multiple exceeding.

Questions:

  • How is the task monitor to be judged?
  • (Especially the Max. Cycle Time)

Answer:

These values are really true and trustworthy - In the motion area, the jitter display on the right is very helpful.

See also: Monitoring

Question:

Can a user/developer trust the task monitor values blindly, or are they falsified if necessary with the start process of the PLC?

Answer:

Yes!
F.e.g. there can be cycle extensions during startup, but these are real measures.

Questions:

  • How are the task monitor values to be interpreted?
  • How should a "healthy" load look like?

Answer:

Based on our application experience, the load should only exceed 80% in exceptional cases. 
Here the PLCload is much more crucial (See PLCshell command) as the task load itself.

Questions:

  • Are there any recommendations or a guideline how to design a task configuration?
  • When is the point to use more than one task?

Answer:

To be considered here are all things that can block your task processing (like Modbus / Files services / also Visu)
These always belong to their own task.


The highest priority task (most EtherCAT/SoftMotion operations) should not be affected by such things.

Question:

What effects does multicore have on the task configuration?

Answer:

With MultiCore, you can support your tasks much more.
F.e.g. you can run a Visu on its own core, etc..
In principle, you can also achieve smaller jitter times or scale/utilize the system even better.

Questions:

  • Does the PLC already start up, before the fieldbuses are running?
  • Does this have to be taken into account in the program?

Answer:

Yes, this is indeed the case!

The user has to take care, in the application himself, that he is only starting or using things from the fieldbus when the bus is operational.