This is a discrete-event, sequential control loop — not a continuous PID feedback loop. A photoelectric sensor at position xs reports the instant td a part crosses it. The controller schedules the pneumatic diverter, sitting a fixed distance d ahead, to fire once that part reaches it:
t_arrive = t_d + d / v_belt
t_fire = t_arrive + delay (controller + valve latency)
window = [t_arrive, t_arrive + w] (part physically at the diverter, width w = part length / v_belt)
The part is sorted correctly only if the pusher's open interval [t_fire, t_fire + dwell] overlaps the part's transit window. If delay + reaction time pushes t_fire past the window, the part sails by unsorted — the same failure mode as a real line running too fast for its actuator's cycle time. The strip chart below the belt view plots exactly these two intervals per part, live, so you can watch the timing budget succeed or fail.
- Belt speed — sets both part transit time and how tight the timing window gets.
- Actuator response delay — the controller-to-valve latency; too large and fast parts are missed.
- Pusher dwell time — how long the diverter stays extended; too short narrows the catch window, too long risks fouling the next part.
- Spawn rate — part arrival rate; pushing it up stresses the same timing budget a real production-rate increase would.
- Sim speed — slows or speeds the whole clock (belt, sensor, controller together) so you can study a single fire event frame-by-frame without changing the physical setup.
Real-world relevance: this is the same sense→schedule→actuate sequencing used by photoelectric-sensor sorters, pick-reject stations and pneumatic diverters on real packaging and fulfillment lines — accuracy is a timing-budget problem, not a force-control one.