Learn PLCs free
PLC FundamentalsBeginnerImportant
5 min read
Updated
Beginner

PLC Scan Time: Measure, Calculate & Troubleshoot

Scan Time

Quick answer

PLC scan time is the measured execution duration of a controller task or cyclic program pass. It is not automatically the task period or end-to-end I/O response time; priorities, interruptions, I/O update rates, communications and jitter also affect response.

Key Takeaways

  • PLC scan time is the measured execution duration of a controller task or cyclic program pass. It is not automatically th...
  • Beginner-level topic in PLC Fundamentals
  • Commonly used in: Task watchdog and CPU-loading verification, Diagnosing missed pulses and delayed responses

Detailed Definition

Scan time is how long a particular cyclic execution takes. A simple PLC may expose one last, average and maximum scan value. A modern controller can run continuous, periodic and event tasks, each with its own execution time, period, priority and watchdog.

Do not use a generic “1–100 ms” range as a design guarantee. Measure the target controller under realistic communications, motion, messaging and worst-case branches. For a periodic task, verify both execution time and interval/jitter. End-to-end machine response also includes when the input is updated, when the task next runs and when the output module applies the result.

Evidence and scope

Measurement fields and task terminology were checked against current Rockwell Studio 5000 V38, Siemens STEP 7 V21 and CODESYS task-monitor documentation. Values are controller observations, not universal PLC timing ranges.

Technical review:

Critical behavior

  • Task execution time, configured task period and end-to-end I/O response are different measurements.
  • Maximum observed scan is more useful for deadline checks than a single last or average value.
  • Higher-priority tasks, interrupts, communications and conditional code paths can create execution-time variation and jitter.
  • Distributed I/O can update asynchronously to logic, so a fast task alone does not guarantee a fast field response.
  • A watchdog is a fault boundary, not a design target; normal worst-case execution needs deliberate margin below it.

Verification checklist

  1. 1Record controller model, firmware, task type, priority, period and watchdog with every timing result.
  2. 2Reset and observe maximum scan through startup, normal production, faults, recipes and communication bursts.
  3. 3Measure task jitter or interval variation where the platform exposes it.
  4. 4Compare input pulse width and I/O update rates with the task schedule.
  5. 5Measure the physical input-to-output path when a response-time requirement is safety- or process-critical.

IEC and vendor terminology

Similar-looking instructions do not always have identical execution, initialization or storage behavior.

PlatformCommon termWhat to verify
IEC / general control modelCycle, task execution, intervalIEC defines program execution concepts, while the runtime decides the task model and timing diagnostics.
Rockwell Studio 5000LastScanTime / MaxScanTimeProgram and Task objects expose scan values; task Rate and Watchdog are separate configuration values.
Siemens STEP 7Cycle time / OB runtimeDiagnostics depend on CPU family. S7-300/400 OB1 documents previous, minimum and maximum cycle values.
CODESYSLast/average/max cycle time and jitterThe Task Configuration monitor separates cycle measurements from periodic jitter and configured interval.

One cyclic response path

Scan time usually describes the logic-execution portion. The whole response path must be measured when timing is a machine requirement.

Interpret a 10 ms periodic-task measurement

This example separates configured scheduling values from observed execution values.

State / phaseExample valueWhat it meansEngineering use
Task interval10.0 msRequested time between task releasesControl update target
Last execution2.6 msMost recently observed task runtimeLive diagnostic only
Average execution2.3 msMean over the monitor windowTrend normal loading
Maximum execution4.4 msLargest observed runtime since resetDeadline and headroom review
Watchdog20.0 msConfigured overrun fault boundaryFault protection, not target
Illustrative values only. Capture real last, average, maximum, interval, jitter and watchdog data on the target controller.

Working LD and ST example

Capture task scan diagnostics without confusing units

Store the vendor diagnostic attributes in clearly named tags and alarm on an engineering limit below the watchdog.

Ladder Diagram

|--[ GSV Task MainTask LastScanTime    → MainTaskLast_us ]----------------|
|--[ GSV Task MainTask MaxScanTime     → MainTaskMax_us  ]----------------|
|--[ MainTaskMax_us > EngineeringLimit_us ]--------------( ScanAlarm )----|

Structured Text

(* Attribute names and units are platform-specific. *)
ScanUtilizationPct :=
    DINT_TO_REAL(MainTaskMax_us) /
    DINT_TO_REAL(MainTaskPeriod_us) * 100.0;

ScanAlarm := MainTaskMax_us > EngineeringLimit_us;

Expected result: The diagnostic distinguishes observed maximum execution from the configured period. Verify the actual attribute units before using the calculation.

Failure modes and diagnostic checks

SymptomLikely causeCheck next
Average scan looks healthy but watchdog faults occurRare worst-case branch, preemption or communications spikeReset and trend maximum scan, jitter and task overlaps during the full machine cycle.
Fast scan but slow output responseI/O update, network RPI, device or mechanical delay dominatesTimestamp or scope each stage from physical input to physical output.
Short sensor pulses disappearPulse is not sampled by the module/task pathUse latched/high-speed input hardware or a faster justified task.
Performance changed after a small editDifferent code path, online edit overhead or task interactionRepeat the same acceptance test and compare maximum, not only last scan.

Current primary and technical sources

These sources support the behavior summarized on this page. The project's controller, firmware and IDE help remain authoritative for implementation.

Continue with the practical guide

Common Questions

What is Scan Time?

PLC scan time is the measured execution duration of a controller task or cyclic program pass. It is not automatically the task period or end-to-end I/O response time; priorities, interruptions, I/O update rates, communications and jitter also affect response.

When should I use Scan Time?

Scan Time is particularly useful in scenarios such as Task watchdog and CPU-loading verification and Diagnosing missed pulses and delayed responses. Consider implementing it when you need reliable, efficient solutions for these types of applications.

What should I verify before using Scan Time?

Record controller model, firmware, task type, priority, period and watchdog with every timing result. Reset and observe maximum scan through startup, normal production, faults, recipes and communication bursts. Measure task jitter or interval variation where the platform exposes it. Compare input pulse width and I/O update rates with the task schedule. Measure the physical input-to-output path when a response-time requirement is safety- or process-critical.

What are related concepts I should learn?

To fully understand Scan Time, you should also familiarize yourself with PLC (Programmable Logic Controller), Scan Cycle, and CPU (Central Processing Unit). These concepts work together in industrial automation systems.

Was this helpful?

Let us know if this glossary term helped you understand Scan Time better.

Your feedback helps us improve our glossary and create better content for the PLC programming community.

Quick Info

Difficulty
Beginner
Tier
Important

About PLC Fundamentals

Core concepts and hardware components of programmable logic controllers

Total Terms:35
Difficulty:Beginner to Intermediate

Free PLC simulator

Stop reading, start doing

Write ladder logic in your browser, hit Run, and watch machine scenarios react. A 12-lesson curriculum across 8 PLC dialects — free account, no credit card.

Practice PLCs free →