PLC Timing and Fault Behavior
This page explains what a Control Seat Virtual PLC does when a task runs late, an input becomes unreliable, an output cannot be delivered, or the controller restarts. Review these choices during commissioning so the observed behavior matches the needs of your process.
How a scan runs
Control Seat uses periodic tasks. A task can run every 10 milliseconds to 60 seconds; new tasks default to 100 milliseconds. Priorities determine which task runs first when more than one is due, but one task does not interrupt another.
Each accepted scan follows the same sequence:
- Capture one consistent snapshot of the input tags.
- Run the control program against that snapshot.
- Discard the scan if it faults or exceeds its watchdog.
- Commit retained values and send outputs only after the scan succeeds.
This prevents a failed scan from publishing only part of its outputs.
Late scans and watchdogs
Every task has a period and a watchdog. You can choose what happens when a task misses its next scheduled cycle:
| Setting | Behavior |
|---|---|
| Skip and continue | Count the missed cycle, move to the next future deadline, and continue. Missed cycles are never replayed in a burst. |
| Fault | Stop the affected program and report the timing fault. |
If a scan exceeds its watchdog, that scan is rejected, its staged outputs and retained changes are discarded, and the program faults. A separate liveness monitor detects when execution stops making progress.
Input quality
Each scan sees both the value and quality of every input. A program can:
- Use the last good value, while quality-aware logic sees that the input is no longer good; or
- Fault the program when a required input has bad quality.
Using the last good value is the default. It avoids changing a process value just because communication was interrupted, but the program should check input quality anywhere stale data would be unsafe.
Output delivery failures
For standard PLC applications, each output can choose one of three actions:
| Action | Behavior after repeated delivery failures |
|---|---|
| Hold last | Keep the last commanded value and retry. This is the default. |
| Safe value | Command the configured safe value and continue retrying it. |
| Fault program | Stop the program and report which output failed. |
The default threshold is three consecutive failed writes. A successful write resets the count. The safe value is validated before deployment.
Projects that use separately scheduled PROGRAM tasks currently hold the last value and retry; configurable per-output actions for that project type are not available yet. Local GPIO outputs can also have a hardware-profile safe state that is applied after their PLC owner remains stopped or faulted briefly.
These are operational controls, not functional-safety functions. Safety-rated outputs must be handled by certified safety hardware. See the PLC Safety Boundary.
Program updates
Publishing a new version is a controlled stop-and-swap, not an online edit. The running program stops at a scan boundary, reviewed retained values are carried forward, and the new version starts. If activation fails, Control Seat keeps or restores the last known-good version.
Outputs are not actively rewritten during the swap, so connected equipment may continue to hold its last commanded state. Plan updates as maintenance events and verify the result before returning the process to normal operation.
Power loss and retained values
Retained values are stored on disk using crash-safe replacement. A normal warm restart restores them. If a stored snapshot is damaged or incompatible, the program starts from its declared initial values and reports that retained state was discarded.
An unexpected power loss can lose up to five seconds of the newest retained changes. Do not rely on this store for a counter or process step that must survive every possible power interruption without loss.
Understanding timing measurements
Control Seat reports:
- Scan time: how long the control program took to execute.
- Cycle-start delay: how late the scan began relative to its deadline.
- Overruns: how many scheduled cycles were missed.
- Tail values: p99, p99.9, and the maximum, not only an average.
Timing depends on the application, hardware, operating system, field connections, and background workload. Measure the complete system you intend to commission. The published FR202 engine results are useful comparisons, but a long-duration qualification of the shipping isolated runtime has not yet been published as a product timing bound.
Recommended pilot settings
For an initial supervised pilot:
- begin with a 100 millisecond task unless the process requires faster control;
- test the selected input- and output-fault behavior by disconnecting each device;
- test a program update and a complete power removal;
- keep safety functions in independent certified hardware; and
- record scan tails and overruns with normal communications and logging active.
See Supported PLC I/O for current protocol and hardware coverage.