Picket fence vs ladder barcode orientation: why it matters

Two cartons carry the same EAN-13 label down the same belt, and one station reads every pass while the next never reads at all. The difference is often nothing but geometry: picket fence, with the bars running across the direction of travel, or ladder, with the bars running along it. For an area-imager fixed code reader the distinction barely exists, because the decoder works at any rotation in the frame. For a sweep-based laser scanner it decides whether the code reads at all, and the ratio of scan rate to belt speed decides how reliably. This guide gives you the geometry, the crossing-count formula, a worked speed limit you can rerun with your own numbers, and the point at which the sensible move is to stop chasing mount angles and fit an omnidirectional reader.

Picket fence and ladder, defined

The names describe what the bar pattern looks like from the scanner's side of the belt. In picket fence orientation the bars stand across the direction of travel, like fence pickets seen from the roadside; the code's full width, from leading quiet zone to trailing one, is what travels past the scanner. In ladder orientation the bars lie along the travel direction like the rungs of a ladder; the bar height is what travels, and the code's width sits across the belt.

That one difference moves the two numbers a laser scanner lives on: which sweeps cross the bars at all, and how much belt travel each pass offers.

The distinction belongs to 1D symbols only. A Data Matrix or QR code has no bars to cross; its finder patterns let a decoder lock on at any in-plane angle.

Why a laser scanner reads one orientation and fails on the other

A laser scanner decodes one scan line at a time. A line produces a decode only when it runs from the quiet zone on one side of the symbol, across every bar and space, to the quiet zone on the other. A partial traverse, or a path parallel to the bars, returns nothing.

Mount a single-line scanner with its sweep running along the belt, and the two orientations stop being similar:

• Picket fence: the sweep runs square across the bars. Every sweep that lands on the code is a full decode attempt, and the moving code serves up fresh attempts as it advances through the beam.
• Ladder: the sweep runs parallel to the bars and never crosses a single edge. That is zero decode attempts per pass, at any belt speed, from a perfectly healthy scanner.

Turn the scanner 90° so the line runs across the belt and the roles swap: ladder decodes on every sweep while the code covers the line, and picket fence goes silent. This is the trap the orientation question exists for — the hardware is fine and the mount is wrong for the labels.

Multi-line, raster and omnidirectional laser patterns soften the problem. With lines at many angles, some line crosses the bars in either orientation. What orientation still controls is how many of those lines are productive, and how long the code stays in the pattern — which is where belt speed enters the arithmetic.

The crossing count: scan rate against belt speed

Laser scanner user manuals print their decode formulas in an appendix, with the pattern's line count and geometry folded in. The short form behind all of them is a ratio between how fast the scanner sweeps and how long the code stays in the beam:

Scan rate is the rated sweeps per second. Code size along travel is W for picket fence with the line mounted along the belt, or H for ladder with the line mounted across the belt. The 5 is the design minimum: at least five full crossings per pass, with four as a floor. The margin is not decoration. Sweeps that land on a smudge, a glare streak or the edge of the label do not decode, and those misses set your first-read rate; how much to trust a decode once you have it is its own subject, covered in barcode read confidence.

The estimate cuts both ways. It ignores the sweep spot size, which adds a fraction of a millimetre of window, and it assumes every sweep in the window lands cleanly on the code.

Worked example: a 37 mm EAN-13 code on a 300 mm/s belt

Inputs, with where each comes from:

• Code: EAN-13 at nominal 100 % size, so module X = 0.33 mm. The symbol is 95 modules wide: 95 × 0.33 mm = 31.35 mm; with quiet zones, call it W = 37 mm across the bars. Typical carton label, measured off your own label in practice.
• Bar height: H = 25 mm — example input, typical for a carton label.
• Belt speed: v = 300 mm/s, which is 18 m/min — example input, a common pack-line speed.
• Scanner: a single-line industrial laser rated 500 scans/s — example input; your model's rated rate and the full formulas sit in its manual's appendix.

Picket fence, line along the belt. Window in the beam: t = W ÷ v = 37 mm ÷ 300 mm/s = 0.123 s. Crossings: 500 scans/s × 0.123 s ≈ 62 per pass — 12× the minimum of 5.

Ladder, scanner remounted across the belt. Window: t = H ÷ v = 25 mm ÷ 300 mm/s = 0.083 s. Crossings: 500 × 0.083 ≈ 42 per pass — 8× the minimum.

Ladder on the original along-the-belt mount. The sweep never crosses a bar edge: 0 crossings, no read, at any speed.

Speed caps, from v_max = rate × size ÷ 5: picket fence 500 × 37 mm ÷ 5 = 3,700 mm/s ≈ 3.7 m/s; ladder 500 × 25 mm ÷ 5 = 2,500 mm/s = 2.5 m/s.

Motion skew, the term that erodes the margin first: one sweep lasts 1 ÷ 500 s = 2 ms. At 300 mm/s the code advances 0.6 mm during a sweep — 1.6 % of W — so the crossing path stays effectively square to the bars. At the 3.7 m/s cap the same sweep sees 7.4 mm of travel, every crossing slants through the pattern, and the practical ceiling lands below the arithmetic one.

Decision. At 300 mm/s this code reads comfortably in either orientation provided the line crosses the bars: about 60 crossings picket fence, about 40 ladder. A single-line laser stays viable on this label to roughly 2.5–3.7 m/s, orientation permitting. Above that, or on a line where labels arrive both ways, sweep geometry is the wrong tool and an omnidirectional imager removes the variable entirely.

What an omnidirectional imager changes

An area imager captures the whole frame and hands the decoder a picture. The decoder finds the code at any rotation in that picture, so picket fence and ladder read identically and even tumbled labels read. The mount only has to keep the code inside the field of view and the depth of field.

Orientation hands the constraint to three optical limits:

• Pixels across the narrow module. Aim for 3 pixels across the narrowest bar; 2 is a workable floor. On the example code, 3 px on a 0.33 mm module samples every 0.11 mm of field, so an 80 mm field of view needs 80 ÷ 0.11 ≈ 730 pixels across the sensor — a mark every code reader on the shelf clears easily.
• Exposure against blur. Keep blur under a third of a module: exposure ≤ X ÷ 3 ÷ speed. For X = 0.33 mm at 300 mm/s that is 0.11 mm ÷ 300 mm/s ≈ 0.37 ms. Global-shutter readers make that routine; the light has to keep up, which is why short bright flashes beat long exposures on fast belts. The same blur mathematics governs capture from moving platforms, as worked through in barcode capture on a moving vehicle.
• Focus and field. The code must sit inside the depth of field at the mounted height, with wander on both axes inside the field of view. The pixel and focus trade-offs are the ones that bound any camera-based scan; tablet camera barcode scanning works them in detail for phone hardware.

The resolution calculator below runs the pixel arithmetic from your own field of view and module size; its button opens the reader finder filtered to sensors with enough pixels.

When the line runs faster than any sweep pattern can cover, choosing the reader at speed becomes its own decision; high speed conveyor barcode reading compares the options by rate and set-up.

Readers that make the orientation question disappear

For a carton line like the worked example, a compact reader over the belt is the common pick.

Its 12 mm lens and 1.3 MP global-shutter sensor, on Fast Ethernet with an M12 mount, suit carton codes at short range.

Shorter working distances and shiny film change the pick. A reader that focuses at 70 mm through a 4.63 mm lens with a polarizer on board handles shrink-wrapped trays read close over the belt.

Long logistics labels and lines that count reads by the second need more pixels and decode throughput.

The LS-CRD-0028 is rated 30 fps and 60 codes/s, with an 8 mm lens on a 2560 x 2048, 5 MP sensor. The MV-ID6200PM-00C-NNG goes to 20 MP on a 1-inch sensor with a C-mount for long, dense labels, and the MV-IDS006M-12C-C covers the middle with 6 MP on GigE.

For station audits and spot checks on mixed lines, a handheld from the handheld code readers shelf applies the same omnidirectional logic from your hand. The code reader finder filters the fixed shelf by pixels, interface, shutter and mount.

Checks before you commit the mount

A short list that catches most orientation failures at the bench:

• Measure the label, not the box: W across the bars including quiet zones, bar height H, module X, in millimetres.
• Time the belt at the scanner's position in mm/s, not the nameplate line speed — infeeds and accumulations run slower than the main drive.
• Laser path: compute crossings = rate × (W or H) ÷ v, design at 5 or more, and mount the line so it crosses the bars — along the belt for picket fence, across it for ladder.
• Imager path: field of view covering code plus wander, depth of field covering the height band, exposure ≤ X ÷ 3 ÷ v, photo-eye trigger just before the field, and a tight region of interest; setting an ROI for inline code reading shows why the tight region also buys reliability.
• Glare plan: film, shrink wrap and glossy labels need polarization or diffuse light, not longer exposure; the code reader accessories shelf carries light boards and polarizing covers for this.
• Test both orientations: rotate a sample label 90° on the belt before you sign off any laser mount.

If your numbers land like the worked example, the mount is settled; if not, rerun the crossing count with your own W, H and speed before touching hardware.

When orientation is not the real problem

Two situations look like orientation failures and are not:

• Reads fail in both orientations after remounting. The cause is usually the surface, not the geometry — glare from film, curvature on a can, damage or faint print. Work through improve barcode decode rate on damaged low contrast codes before blaming the mount.
• Decodes arrive but get doubted. A crossing yields a yes or a no; grading how much to trust the result is the read-confidence subject introduced earlier.

And one case where the whole question dissolves: 2D codes. A Data Matrix or QR symbol has no bars, decodes at any in-plane angle on an imager, and answers only to blur and pixels. Measure the geometry, run the crossing count for any sweep-based scanner already on the line, and let an omnidirectional imager absorb the rest. If you want help sizing W, H and belt speed for your own line, send the numbers through the contact page and we will match the reader and the light to them.