Due to the broad variety of functionality which can run in parallel on AC500 PLCs, it is recommended, or even mandatory depending on the desired functionality, to adjust system behavior to better match the needs of the individual application.

Due to hardware limitations and constraints, it’s necessary to prioritize functionality, especially if it’s intended to execute multiple features in parallel. Prioritizing can be very difficult due to the complexity of the underlying software components. Besides of task priorities, it might also be necessary to adjust low level system configuration to achieve the best possible performance for a specific feature.

To reduce complexity, and thus the risk of negative side-effects the CPU parameter ‎Communication schema‎ has been introduced. This parameter enables the user to specifically define the primary purpose of the corresponding PLC and lay focus on a specific functionality.

Priority classifications and their purpose

The functionality prioritized by each communication schema is grouped into 3 different classes:

High priority real-time functionality

Functionality with strict timing requirements, e.g., drivers with hardware access or hardware watchdog monitoring failures might lead to exception errors, loss of communication with hardware and other problems which are non-recoverable and might cause a stop of the user application.

Functionality of this class can’t be influenced by activity of user defined IEC tasks. As a result of this, related functionality can interrupt or delay IEC tasks and therefore increase IEC task jitter and the duration of IEC task cycles.

IEC tasks with real-time priority

This is the priority range of user defined real-time IEC tasks. Priorities 0 to 15 are real-time priorities (IEC priority 16 is mapped to non-real-time priority) and can be used to define an IEC task’s priority in Automation Builder.

Task in this range can be interrupted or delayed by high priority functionality. It’s not possible for IEC user code to suppress high priority activity, thus increasing safety and reducing the risk of negative side effects caused by bugs in IEC user code or libraries or misconfiguration of IEC tasks.

Low priority non-real-time functionality

The low priority range is intended for non-real-time functionality which doesn’t have any specific timing requirements and which is supposed to execute its activity without delaying or interrupting the user application and its related functionality.

Activity assigned to this range can be suppressed by high priority and real-time IEC tasks. Therefore might show high jitter, sporadic activity or large reaction times, depending on the overall system load.

To avoid suppression of the tasks of this group, the system reserves a short time slot to process low-priority functionality if the CPU load reaches nearly 100%. Under normal circumstances (below an average system load of 80%), this mechanism shouldn’t be engaged. Although this time slot could cause high priority tasks to jitter slightly (± 100 microseconds), it ensures that the system remains responsive and will always be able to run fundamental jobs which must be executed regularly. Note that tasks of low priority still play an important role and need to be scheduled regularly to meet their individual timing requirements.