| Scenario | Sensor (ms) | Compute (ms) | Comms (ms) | Actuator (ms) | Safety (ms) | PMT (ms) |
|---|---|---|---|---|---|---|
| Servo axis, local IO | 10.0 | 3.0 | 1.5 | 12.0 | 4.0 | 30.5 |
| Robot cell, fieldbus | 12.0 | 6.0 | 4.0 | 18.0 | 6.0 | 46.0 |
| Conveyor start, safety heavy | 20.0 | 5.0 | 3.0 | 25.0 | 12.0 | 65.0 |
| Manual confirm included | 10.0 | 3.0 | 2.0 | 12.0 | 5.0 | 900.0 |
The final row illustrates how a manual step can dominate totals.
Component sum:
T_sum = Σ(T_sensor, T_filter, T_compute, T_comm, T_actuator, T_safety, T_human, T_buffer)
Overlap adjustment (parallel steps):
T_effective = max(0, T_sum − T_overlap)
Overhead factor (jitter, scheduling, queues):
T_adjusted = T_effective × (1 + overhead% / 100)
Uncertainty band:
T_low = T_adjusted × (1 − u%/100), T_high = T_adjusted × (1 + u%/100)
- Choose sensor mode: sampling rate or direct sensor delay.
- Enter each delay component using consistent units.
- Add overlap only when tasks truly run in parallel.
- Set overhead to capture jitter and queueing behavior.
- Optional: set a target to see margin and status.
- Export CSV or PDF for reviews and documentation.
Where pre movement time appears in real systems
Pre movement time (PMT) is the elapsed time between a start command and the first measurable motion. In automated machines it includes acquisition, filtering, logic execution, message transport, drive enable, and mechanical dead time. For many servo axes, practical PMT targets fall between 20–60 ms, while heavy conveyors and safety‑gated cells can exceed 100 ms when permissives and energization sequences are strict.
Building a timing budget from measurable blocks
This calculator treats PMT as a budget of independent delay blocks. Typical sampling windows are driven by sensor update rates: 100 Hz implies 10 ms per sample, and a 1.2 worst‑case factor yields 12 ms capture time. Controller execution often follows scan or task cycles; PLC tasks of 2–10 ms and motion tasks of 0.5–2 ms are common. Fieldbus latency can range from sub‑millisecond cyclic links to 5–20 ms on shared Ethernet or wireless paths.
Using overlap, overhead, and uncertainty correctly
Not every block is strictly serial. If filtering runs in parallel with communication, you can subtract a justified overlap. The overhead factor models jitter, queueing, and scheduling contention; teams often start with 5–15% and refine after profiling. Uncertainty expands the adjusted PMT into a low/high band, which is useful when datasheets provide ranges and when temperature or load changes affect actuator response.
Interpreting the breakdown to guide design changes
Once you see contribution percentages, focus on the largest drivers. Actuator dead time is frequently dominant because it includes torque build, brake release, and enable handshakes; reducing it may require drive parameter tuning or pre‑energization. Communication spikes point to buffering, QoS, or segmentation issues. Large sensor shares suggest raising update rates, reducing averaging windows, or moving detection closer to the controller.
Validation workflow and reporting for reviews
For validation, measure PMT with a synchronized timestamp source, such as controller trace logs plus an external encoder or high‑speed input capture. Run at least 30 trials to observe variability, then set overhead and uncertainty to cover the 95th percentile. Export CSV for design reviews and attach the PDF snapshot to change requests so PMT assumptions remain traceable across commissioning and maintenance cycles and audits routinely.
What does this calculator estimate?
It estimates pre movement time as the summed delay from sensing through actuation, with optional overlap subtraction, overhead for jitter, and an uncertainty band for low and high estimates.
When should I use sampling rate mode for the sensor?
Use sampling rate mode when detection depends on periodic updates, such as encoders, vision triggers, or cyclic IO. The tool converts rate into a worst‑case acquisition window using your factor.
How do I choose an overlap value?
Only enter overlap when two delays truly run in parallel and share a common start. Base it on traces or timing diagrams. If you are unsure, leave overlap at zero to avoid understating PMT.
What overhead percentage is reasonable?
Start with 5–15% for well‑controlled real‑time tasks, and 15–30% for shared networks or non‑real‑time OS scheduling. Then tune it using measured trial data from commissioning logs.
Why is my actuator delay so large?
Actuator delay can include drive enable handshakes, brake release, current ramp, mechanical backlash take‑up, and safety gates. Check drive parameters, pre‑enable strategies, and whether permissives are delaying the enable path.
How should I validate the final PMT result?
Record timestamps for command issuance and first motion, ideally with the same clock domain. Run multiple trials, compute percentiles, and set overhead and uncertainty to cover worst‑case behavior. Export CSV and PDF to document the assumptions.