Line speed and camera read time calculator
Enter the line speed (m/min or items/min), product and gap length, code size and the camera. See the time per product, blur in pixels, how long the code stays in the field of view, how many frames you get and the highest speed the camera can handle.
Line and product
Code
Camera
The calculation runs in your browser; the values you enter are not sent anywhere.
Highest line speed with this camera
90 m/min
600 items/min
Limited by: frames in the read window (Limit from frame count: 90 m/min · Limit from blur: 93.75 m/min)
With the chosen values blur, resolution and frame count are within the rules of thumb.
Line
- Conveyor speed
- 60 m/min
- Production rate
- 400 items/min
- Product pitch (length + gap)
- 150 mm
- Time per product
- 150 ms
- Products in the field of view
- 0.4
Image
- Pixel size
- 0.0313 mm/pixel
- Code size in pixels
- 320 pixels
- Pixels per module
- 16 pixels/module
- Motion blur
- 0.02 mm = 0.64 pixels = 0.04 module
- Longest exposure that keeps blur at 1 pixel
- 31.25 µs
Read window
- Time the whole code stays visible
- 50 ms
- Effective frame rate
- 60 fps
- Frames in the window
- 3
- Guaranteed frames
- 3
- Distance the product moves between two frames
- 16.67 mm
- Lowest frame rate for the required frames
- 40 fps
blur = speed × exposure · window = (field of view − code size) / speed · frames = window × effective frame rate · highest speed = (field of view − code size) × frame rate / required frames
Results come from a simple geometric model; it does not include lens distortion, rolling shutter skew, lighting, code quality or decoding reliability. The thresholds are rules of thumb, not standards. Test on the real line; this tool is for preliminary sizing.
Let's size the camera, optics and lighting for your line from the line speed and code size.
Request a conversation01
How to use it
A
Enter the line speed, product and gap length, code size and camera values.
B
Read the warnings: check blur, pixels per module and the guaranteed frame count.
C
Look at the highest line speed and the limiting factor, then change the exposure, frame rate or field of view.
02
How line speed limits camera reading
A code moving on a conveyor crosses the camera's field of view in a certain time. The time the whole code stays in the field of view (the read window) is the difference between the field of view and the code size divided by the speed. In that time the camera must take enough frames; otherwise the code leaves the field of view between frames and is never fully visible in any of them.
The frame count is the window time times the effective frame rate. The effective frame rate is the smaller of the camera's frame rate and the limit that comes from the time needed to process one frame. For the guaranteed frame count the fraction is dropped, because the code's position in the window is not synchronised with the frames.
03
Motion blur and exposure time
The code moves during exposure; the pixel equivalent of that distance is blur: speed × exposure time ÷ pixel size. As blur approaches the module size, neighbouring modules merge. As a rule of thumb keep blur to at most 1 pixel, and in any case below half a module.
Ways to reduce blur are a shorter exposure, strobed lighting and a larger pixel size. A shorter exposure needs more light, which is why on fast lines the light source matters as much as the camera.
04
Assumptions and limits
The model assumes the code travels through the middle of the field of view along the direction of motion, that the lens is distortion-free and that the camera has a global shutter. With rolling shutter sensors the image skews because of the motion; this effect is not included here.
The pixels-per-module and blur thresholds are rules of thumb. Your reader's documentation, the print quality of the code and the background contrast can change the required values. Verify the results by testing on the real line.
FAQ
- How many pixels per code module are needed?
- As a rule of thumb at least 3 pixels; 4–5 pixels are safer. The required value depends on the reader, the print quality and the lighting; check your reader's documentation.
- How short must the exposure be?
- Short enough that motion blur is at most 1 pixel: time ≤ pixel size / speed. The tool calculates this limit and shows it as the longest exposure that keeps blur at 1 pixel.
- What can I do if the frame rate is not enough?
- Options are widening the field of view in the direction of travel (the window gets longer), using a faster camera or a shorter processing time, lowering the speed, or reading the code with two cameras. A triggered camera relies on one good frame, a free-running camera on several.
- Does a rolling shutter camera spoil this calculation?
- Yes. With rolling shutter sensors the rows are read at different moments, so a moving code skews. On fast lines a global shutter sensor is preferred; this tool does not include the skew.
- Why must the whole code fit in the field of view?
- The reader has to see the entire code. Frames containing only part of the code cannot be decoded; that is why the window is calculated from the field of view minus the code size.
Let's size the camera and lighting for your line
We choose the camera, optics and lighting from line speed, code size and product spacing, and test the read rate on site.