Conveyor Timing Simulator
Model reject timing from camera trigger to actuator — belt travel with overlapping vision, PLC, and cylinder latency.
Automation workflowStep 2 of 5
- Scale analog
- 2Reject timing
- Takt
- Throughput
- OEE
Next workflow step
Continue to Takt Time Calculator — Continue the guided sequence with your current context.
Try an example
Related tools
Learn about this tool
What it is, when to use it, formulas, and common questions
What is this?
This simulator models product travel from a vision camera (or trigger sensor) to a reject actuator on a conveyor. It combines belt travel time with vision processing delay, PLC/scan latency, and cylinder or air-blast response so you can see whether the reject fires at the product — or too early / too late.
The live animation is intentional: timing bugs are hard to feel from a spreadsheet row. Watching the part move while you tweak milliseconds makes latency stack-ups obvious before you tune timers on the line.
When do engineers use it?
Use it when designing or debugging a reject station: “How long after the camera trigger should the PLC fire the solenoid?” Also useful when changing belt speed, moving the reject downstream, or adding a slower vision inspection that eats into the available travel window.
If travel time is shorter than the sum of delays, no timer value can save you — you need more distance, a faster decision path, or a slower belt. This tool surfaces that constraint early.
Formula
Travel time = distance ÷ belt speed (Convert units consistently — e.g. meters and m/s, or mm and mm/s.) Control latency = camera/vision delay + PLC/network delay + actuator delay These delays overlap belt travel. PLC fire delay ≈ travel time − control latency. If travel time < control latency, the reject cannot hit the same product without moving hardware or reducing latency.
Example
Example: reject is 800 mm downstream of the camera. Belt speed is 600 mm/s.
Travel time = 800 ÷ 600 ≈ 1.333 s. Suppose vision decision takes 80 ms, PLC and I/O add 20 ms, and the cylinder needs 100 ms to reach the product path — total control latency ≈ 200 ms.
You still have roughly 1.133 s of programmable delay after the trigger before actuation should start (exact PLC timer strategy depends on whether delays are modeled before or after the motion). If you raise belt speed to 1200 mm/s, travel time halves to ~0.667 s and the same 200 ms latency consumes a much larger fraction of the window — animation makes that risk visible.
FAQ
- Why include delays beyond belt travel?
- The reject must act while the product is at the actuator. Vision processing, PLC scan/network time, and valve or cylinder response all shift when the mechanism actually moves relative to the trigger instant.
- What if my vision job time varies?
- Use a conservative (worst-case) processing delay. Average latency that occasionally spikes will cause intermittent miss-rejects. If worst-case latency exceeds travel time, fix the vision budget or increase distance before tuning the happy-path timer.
- Does this model multi-lane or tracking queues?
- It focuses on single-product trigger-to-reject timing along a conveyor path. Multi-lane tracking, encoder following, or FIFO reject queues need additional logic — use this to validate the base travel and latency budget first.
- How should I convert belt speed units?
- Keep distance and speed in consistent units. For example, 24 m/min = 0.4 m/s. Mixing mm distance with m/min speed without conversion is a common commissioning mistake — double-check the units panel before trusting the result.