Configuring CPU 314-2DP for Multiple Cyclic Tasks Safely

A Siemens CPU 314-2DP supports OB35 as its cyclic interrupt block; downloading OB36 is therefore rejected. Configure one base period for OB35, then derive slower periodic tasks with counters inside that block. If a task does not require cyclic-interrupt timing, use a timer-generated start pulse or a CPU-generated time pulse instead.

Symptom interpretation

The defining symptom is that OB35 can be used while another attempted cyclic interrupt block, such as OB36, is rejected during download. This points to a CPU capability limit rather than a defect in the task that the rejected block was intended to execute.

Read the behavior in this order:

Confirm the hardware capability directly in the CPU properties. Open the hardware configuration, double-click the CPU, and inspect the Cyclic interrupts tab. For the CPU 314-2DP described here, the usable cyclic interrupt shown there is OB35.

Cyclic-interrupt mechanism

The term cyclic interrupt here means execution initiated periodically by the CPU rather than by the normal program scan. The CPU associates supported cyclic interrupt resources with defined organization blocks. Creating a block whose number is not supported does not add another interrupt resource; the CPU must already provide the corresponding event and dispatch mechanism.

This distinction explains why correct logic inside OB36 cannot make the download succeed. The rejection occurs because the target CPU cannot host that additional cyclic interrupt block. Recompiling the same block, simplifying its logic, or changing its intended interval does not remove the hardware capability limit.

One supported interrupt can still act as a scheduler. Each execution of OB35 is a base tick. A retained counter divides those ticks into slower rates, and the slower task runs when its counter reaches the calculated threshold. This creates multiple logical periods without claiming multiple hardware cyclic interrupts.

Base-period selection

Select a base period that divides every required interrupt-derived task period into a whole number of ticks. For a base period T_base and a required task period T_task, calculate:

Tick count = Ttask / Tbase

The result must be an integer for an exact counter-based division. With a required 200 ms task and a required 3 s task, configure OB35 for 200 ms and calculate:

3 s / 200 ms = 3000 ms / 200 ms = 15 ticks

Run the fast activity on every OB35 invocation. Increment a counter on each invocation, run the 3 s activity when the counter reaches 15, and then restart that counter.

The shortest required interval is not automatically the correct choice. It must also be supported by the configured cyclic interrupt and leave enough processing time for the work assigned to each invocation. Read the permitted period from the CPU configuration rather than entering an assumed value. If a requested period is not an integer multiple of the selected base, change the base period or use a different scheduling method; rounding the tick count changes the actual period.

OB35 scheduling procedure

1. List every required task period and separate tasks that need cyclic-interrupt execution from tasks that merely need an occasional start pulse.
2. Open the CPU hardware configuration, double-click the CPU, and select the Cyclic interrupts tab. Confirm that OB35 is the available cyclic interrupt for this CPU.
3. Select a supported OB35 base period that divides the required interrupt-derived periods into integer tick counts. For the 200 ms and 3 s case, use 200 ms and a divisor count of 15.
4. Place only the base-rate work directly in the every-cycle path. Increment a retained counter for each slower task once per OB35 invocation.
5. When a counter reaches its calculated tick count, execute or request the corresponding slower task and restart that counter. Define the comparison and restart order consistently so that a threshold of 15 produces one request per 15 invocations, not per 14 or 16.
6. Keep each periodic action bounded. A cyclic scheduler cannot compensate for work whose execution time exceeds the available processing window.
7. For work that does not need cyclic-interrupt timing, generate a start pulse with a timer or use an appropriate CPU-generated time pulse configured in the hardware settings.
8. Download the supported hardware configuration and program, then test each rate independently before enabling all periodic activities together.

Functional verification

1. Check 1: Inspect the CPU properties. Expect the Cyclic interrupts tab to identify OB35 as the available cyclic interrupt for the CPU 314-2DP.
2. Check 2: Download the configuration and OB35. Expect acceptance without attempting to add OB36.
3. Check 3: Observe the base-rate activity. With a configured 200 ms example period, expect one scheduler tick for each OB35 invocation.
4. Check 4: Observe the slower counter. Expect it to advance once per base tick and request the 3 s activity once per 15 ticks.
5. Check 5: Monitor the counter transition around its threshold. Expect one task request followed by the defined counter restart, with no duplicate request at the boundary.
6. Check 6: Run all scheduled work together. Expect the counters to continue advancing regularly and the CPU to remain in its intended operating state.

Recurring implementation pitfalls

Wrong practice starts with treating an organization-block number as a software-created resource. The hardware configuration defines which cyclic interrupts exist; adding OB36 to the project cannot extend the CPU.

A second error is selecting a base period that does not divide the slower periods. Integer truncation or rounding then creates a repeatable timing error. Convert all periods to the same unit before division and accept the result only when it is a whole number.

Off-by-one counter logic is another common fault. Decide whether the counter is incremented before or after comparison, then verify the number of actual OB35 invocations between successive task requests. Resetting at an inconsistent point can shift the interval by one base tick.

Do not place every periodic activity unconditionally in OB35. That makes all activities run at the fastest rate and increases interrupt workload. Gate slower work with its calculated counter, or issue a request that other program logic services when the application permits it.

Timer pulses and CPU-generated time pulses are valid alternatives only when their execution context and timing behavior fit the process. Use OB35 for the work that requires cyclic-interrupt scheduling; move less timing-sensitive work out of that path.

FAQ