The runtime emits a cycle-time warning whenever one particular relay-switched digital input changes, while the other +24 V inputs run without the warning. That pattern points first to work executed for that input, not to the nominal voltage feeding the DIO. Treat the warning as a missed timing objective even if the visible function still completes.
Corrective Approach Comparison
Before anything else, confirm which software path runs when the affected input changes. The repeated association with one input gives three practical approaches, but they do not address the same cause.
| Approach | Use when | Acceptance condition | Main limitation |
|---|---|---|---|
| Optimize the input-specific path | That handler performs excessive computation, waiting, file access, communications, or repeated work | The handler and cyclic work finish inside the configured cycle-time budget | Requires timing each operation rather than guessing |
| Increase the configured cycle time | The measured execution time is bounded and the slower update rate still meets machine requirements | No warning occurs under worst-case operation, and input-response latency remains acceptable | Can hide an uncontrolled delay and slows cyclic processing |
| Offload event work | The application is confirmed to use Python with revpimodio2, and an event callback performs work that need not finish in the cyclic I/O path |
The callback returns promptly while the deferred task completes without corrupting shared state | Adds concurrency, ordering, exception-handling, and shutdown concerns |
Start by measuring and optimizing the input-specific path. Increase the cycle time only after comparing the measured worst-case duration with the required I/O response. Use a worker or thread only after confirming the software stack and proving that blocking event work causes the overrun.
Reproducible Symptom Pattern
The installation switches +24 V through relays into several DIO inputs. Only one input produces the runtime warning, and the behavior is fully reproducible. Because the inputs share the same nominal supply arrangement, the distinguishing factor is either the affected channel's physical transitions or the software associated with that channel.
A runtime cycle warning means that one iteration did not complete within the time allocated to it. It is not equivalent to a DIO voltage fault. The application may still appear correct because the late iteration eventually finishes, but a sellable device must also tolerate repeated operation, communication delays, logging activity, and simultaneous events without accumulating latency or missing transitions.
Capture the complete warning text and its origin before changing a setting. Record the module, function, callback, or line reported by the runtime. Do not move on until switching the affected input produces a matching timestamp in both the input trace and the warning log.
Cycle-Time Overrun Mechanism
A cyclic I/O application reads inputs, runs application logic, writes outputs, and performs runtime housekeeping within a configured interval. If any part blocks past the next deadline, the runtime reports a cycle-time problem. One physical input can expose the warning because its change selects a unique branch that the other inputs never execute.
Common input-specific delays include synchronous communications, file or console output, long loops, waiting for another state, repeated object creation, lock contention, and exception handling. An event callback can cause the same result if it runs in the cyclic context and does not return before the deadline.
The relay path creates a second decision branch. Contact bounce, loose termination, reference-potential problems, or electrical noise can produce several transitions from one commanded operation. If each edge launches the same expensive action, the resulting workload can exceed the cycle budget even when one handler invocation is short. Compare the raw input transition count with the commanded relay operations; one command should not appear as an unexplained burst of state changes.
Diagnostic Isolation Sequence
- Read the configured cycle time. Obtain it from the application's runtime configuration and record it without changing it. Confirm that the warning is generated by this cyclic task rather than by an unrelated scheduler or operating-system component.
- Trace the affected input. Log monotonic timestamps for entry to and exit from the input-specific handler. Also count raw state transitions. Confirm whether one relay operation produces one logical transition or several.
- Compare another input. Apply the same timing instrumentation to one unaffected channel. Confirm which function calls or branches appear only in the slow path.
- Divide the handler into operations. Time computation, communications, storage, console output, waits, and calls into other components separately. Do not move on until the operation consuming the cycle budget is identified.
- Separate electrical and software causes. Temporarily replace the affected handler body with a minimal state capture while retaining the same physical input. If transition bursts remain, inspect the relay contact, wiring, reference, and configured input filtering. If the warning disappears while transitions remain clean, restore the handler operations one at a time.
- Exercise combined conditions. Switch the affected input while normal communications, output updates, and other events are active. Record maximum cycle duration and handler duration, not only their averages.
Recommended Correction Procedure
- Remove waits from the cyclic path. Replace any wait-for-condition sequence with state-based logic that advances across cycles. Confirm that each invocation returns without waiting for external equipment or communications.
- Bound repeated work. Move invariant calculations and setup outside the input handler, and execute the action only on the intended edge rather than on every scan while the input is active. Confirm one action count per intended transition.
- Control physical retriggering. Repair unstable terminations or relay contacts when the trace shows unintended transitions. If the platform provides input filtering, select its setting from the module documentation and verify that it rejects bounce without masking the shortest valid field pulse.
-
Offload blocking event work conditionally. If the application actually uses
Pythonandrevpimodio2, let the event handler capture the input event and submit non-cyclic work to a controlled worker. Keep direct I/O ownership and shared data synchronization explicit. Confirm that multiple transitions cannot create an unbounded number of threads or queued jobs. - Recalculate the cycle setting. Increase the configured cycle time only when the optimized worst-case execution is predictably bounded and the resulting input-to-output latency meets the application requirement. Base the setting on measured maximum duration plus an engineering margin selected for the product's expected load.
Acceptance Verification
| Check | Pass condition |
|---|---|
| Single transition | The intended action runs once and no cycle warning appears |
| Repeated operation | Transition count matches commanded relay operations |
| Worst-case load | Maximum cyclic execution stays below the configured cycle-time budget with the selected margin |
| All input channels | Every channel retains its intended behavior and response order |
| Restart and recovery | No stale worker task, queued action, or incorrect input state remains after restart |
Run the acceptance test long enough to exercise the affected input repeatedly alongside normal communications and output activity. Review maximum timing and warning logs after the run; a visually correct output alone is not a pass criterion.
Frequently Asked Questions
Why does only one digital input cause a cycle-time warning?
That input can select a unique handler, blocking call, or repeated edge action. Time its software path and compare its raw transition count with an unaffected input.
Why does the application still work after the warning?
The late cycle may finish and produce the expected visible result, but it has already exceeded its timing objective. Repeated overruns can increase response latency or allow field transitions to go unprocessed.
Why can a relay input create extra software load?
Contact bounce or an unstable electrical path can create multiple edges from one operation. Count timestamped raw transitions before adding filtering or changing application logic.
How do I verify that the cycle-time correction is complete?
Repeat the affected transition under worst-case application load, then confirm one action per command, no runtime warnings, and a measured maximum cycle duration below the configured budget with the selected engineering margin.