Configuring an S7-300 Timer for a 20-Second Delay Guide

On this S7-300, replace the STL busy loop with a cyclic FB state machine and a timer that holds the current DB position while the PLC continues its normal scan. Start the 20-second interval after the instruction has been processed, then advance to the next instruction only after the timer expires.

Commission the cyclic processing sequence

Call the processing FB repeatedly from OB1. Each call should perform only the work required by the current state; it must return to OB1 rather than wait in a loop. Keep the processing position and wait state in FB static data so they survive between calls.

1. Prerequisite: Define how the sequence starts and how it recognizes the last instruction. Set a static state such as Ready, Process, or Wait, plus a static DB byte offset or other restartable cursor. Check: Confirm these values are visible as FB static data and that OB1 calls the FB on each scan.
2. Prerequisite: Identify the instruction format in the global DB, including the word used for the instruction code and the data types and number of its arguments. Set the cursor to the first record and initialize any instruction count. Check: Monitor the initial cursor and confirm it points at the first instruction word.
3. In Process, read the instruction and required arguments, dispatch the operation, and issue the write. After the write has been accepted, set the state to Wait. Do not advance the cursor yet. Check: Confirm the intended instruction and argument values were read and the write path completed before the wait state begins.
4. In Wait, call the timer on every FB execution. When its done output becomes true, advance the cursor by the full record size, set the state back to Process, and allow the next record to be read. Check: Confirm the cursor changes once per completed wait, not on every scan.

This sequence applies the requested delay between processed instructions while preserving progress. If the intended interval is between attempts rather than between completed writes, place the timer start at that different event and verify it with a trace or monitored state.

Set the timer instance and preset

SFB 4 (TON) with its instance data block. Set the preset to T#20S and drive IN from the wait state. Execute the timer call each time the processing FB runs. The timer accumulates while IN remains true; its Q output indicates that the preset has elapsed. When IN becomes false, the on-delay timer resets.

Declare or assign the timer instance in the FB call interface according to the project’s STEP 7 setup; do not create a fresh timer instance on each scan. Check the CPU and project’s available timer instructions if SFB 4 is unavailable. The required behavior remains the same: a retained timer instance, a stable true input during the wait, and a done indication to release the next record.

Keep the DB cursor and instruction context between scans

The sample uses AR1 and accumulators to read words with indirect addressing. These are working CPU registers, not a suitable place to keep the only copy of a cursor across a return from the FB. Store the logical byte offset and any required context in static FB data, then reconstruct the address register and load the needed accumulator values each time the FB resumes processing.

Do not assume every record is two bytes long. The example increments its pointer by two for one word, but the described data also includes a real value, which occupies more bytes than a word. The instruction code determines how many arguments follow and their types. Calculate the next offset from the actual record layout and argument lengths, or store an explicit record length alongside each record.

For example, if a record contains one instruction word followed by two word arguments and one real argument, its data extent is the instruction word plus both word arguments plus the real argument. Confirm the layout against the DB declaration and actual offsets before implementing pointer arithmetic. Check: Monitor the cursor at each instruction boundary and verify it lands on the next instruction word rather than on an argument or the middle of a real value.

Replace the uninterrupted LOOP path

The STL LOOP instruction repeats execution immediately while its counter permits. A delay instruction placed inside this path does not make a safe 20-second wait; a synchronous wait would hold execution in the same scan, while repeated logic can consume scan time and approach the configured cycle-time watchdog. PLC scans already repeat, so return from the FB and let later scans check the retained state and timer.

Remove the jump back to Next as the mechanism for waiting. In the cyclic design, the FB’s state decides whether a scan processes a record, waits, or finishes. The scan that finds Q true should perform one state transition, not run the next instruction and continue through multiple records in the same call. Check: Monitor the state and confirm the FB returns to OB1 during the entire 20-second interval.

Choose cyclic timing or a periodic interrupt deliberately

A timer inside a cyclic FB is the direct fit when the requirement is “process this instruction, wait 20 seconds, then process the next.” A periodic interrupt organization such as OB35 can suit a task that must be scheduled at a configured recurring interval, but it changes where and when code executes. It is not a reason to use an uninterrupted LOOP; the interrupt routine still needs bounded work and retained position.

Do not use a 20-second watchdog setting as a substitute for the delay. The watchdog protects scan execution time; lengthening it does not create an orderly wait between records. If choosing a periodic interrupt, confirm the CPU supports and is configured for the required interval, and design the state and data access to avoid overlapping or duplicated work with OB1. Check: Document which organization block owns the processing and verify the configured scheduling mechanism before enabling the sequence.

Handle completion, restart, and write status

Define the end-of-sequence behavior explicitly. Use the instruction count or a validated end marker to decide whether to reset the cursor, stop in an idle state, or report completion. Do not let a counter underflow or permit the cursor to read past the DB. Initialize the cursor and state on a deliberate start command, not on every cyclic FB call.

Only start the 20-second timer after the write operation reaches the completion condition required by the application. If the write function reports status, examine its return value and decide how errors affect sequence progress: halt and report, retry under a defined policy, or continue only when that is acceptable. A timer expiration alone does not prove that a peripheral or drive accepted the data. Check: Monitor the write status, completion state, and sequence-end condition independently of the timer.

Verify one complete instruction cycle

Commission with a small, known DB sequence and observe the FB online before running the full data set. Record the cursor, decoded instruction, arguments, state, timer input, timer elapsed value, timer done output, and write result for each cycle. Compare those readings with the DB layout.

1. Start the sequence once and confirm the cursor points to the first instruction and the FB enters Process.
2. Confirm the correct instruction and all its arguments are loaded, then confirm the write result before the FB enters Wait.
3. During the wait, confirm OB1 continues scanning, the cursor remains unchanged, IN stays true, and ET increases toward the T#20S preset.
4. When Q turns true, confirm the timer releases the wait and the cursor advances exactly once by the complete record length.
5. Confirm the next instruction is decoded correctly and that the final record follows the selected end-of-sequence behavior without reading beyond the DB.

The sequence is commissioned only when the monitored cursor, timer transition, write status, and next decoded record all match the intended DB layout.

FAQ