Tracking boxes on a conveyor: encoder or photoeyes

Encoder or photoeyes: which tracks boxes on a conveyor?

Use both, with the encoder on the conveyor drive for distance and the photoeyes at the entries for box detection and re-zero. An eye reports only the moment a box crosses one fixed point. Between eyes you are estimating. After a mid-line stop, an eye-only scheme has lost every inch a box travelled since its last fixed point. An encoder counts belt movement continuously, and roller conveyors slip under load, so the count drifts against the box until an eye corrects it. Encoder for position, eyes for detection and correction is the standard pairing on merge lines like this one.

Photoeye-only tracking stands up when the line runs without stops between eyes and the gaps stay several times the detection uncertainty. On an 18-entry merge line with mid-line stops it falls short, and the encoder earns its place.

When can readers at the robot replace the whole tracking system?

When the robot is the only consumer of the barcode, two readers mounted at the robot replace 36 entry readers, 18 remote nodes, up to 70 ft of serial cable and the whole tracking program. The hardest failure modes of the project leave with them. Get written answers before any hardware order goes out.

Ask these three. Does anything mid-line consume the ID, such as a reject gate, sequencing, merge control or an operator display between entry and robot? Can both barcodes on a box be read at the robot at line speed, which depends on label faces, box orientation, the gap between boxes and belt speed at that point? Does the operator need to see every box between entry and robot? If every answer is no, the design is two readers at the robot and one controller with two serial ports, and the 16 inputs and 16 outputs per entry disappear with the nodes.

If a mid-line consumer does exist, the readers stay at the entries but read locally: each reader sends an ASCII string over its serial port into a remote node, and the node assembles the string into one variable per read, the way serial reads become variables. The network carries finished strings upstream. Size that upstream run like any remote I/O over Ethernet link: the strings are small, but 18 nodes reporting in the same scan set the update budget the error math below depends on. The 36-reader network is the default only when the written answers force it.

How do you scale an encoder into millimetres of belt travel?

Divide the belt travel per encoder revolution by the counts per revolution: a 1,000 pulse per revolution quadrature encoder decoded at x4 on a 2.5 in roller geared 1:1 gives 199.5 mm / 4,000 = 0.05 mm per count. In general form:

mm_per_count = (roller circumference mm x gear ratio roller-to-encoder) / (pulses per rev x decode factor)
199.5 x 1 / (1,000 x 4) = 0.05 mm per count

Quadrature means two channels 90 degrees out of phase. x1 counts one edge of channel A, x2 counts both edges of A, x4 counts both edges of both channels, so x4 returns four times the x1 count and reports direction at the same time. Set the resolution target from the smallest gap between boxes: with the 610 mm gap used below, even x1 at 0.2 mm per count puts 3,050 counts across one gap, so pulses beyond 1,000 ppr buy nothing on this line.

Count the pulses in a hardware high-speed counter input, not in a PC scan. A softlogic scan is not deterministic and will drop pulses at speed. Read the running count over the network each scan, and confirm in the driver documentation which counter-capable modules it actually reads; that compatibility decides the input hardware more than the encoder choice does.

Check the scaling with a tape: jog the conveyor a measured 10 ft and read the count delta. Expected: 3,048 mm / 0.05 mm = 60,960, about 61,000 counts. A miss by a constant ratio means the gear ratio or decode factor is wrong; fix it before trusting any position.

Where do the photoeyes go when you already have an encoder?

One eye at every entry latches box present and snapshots the counter into a new row. One eye near the robot re-zeros the drift that roller slip builds up. An eye firing with no valid read raises an alarm instead of a phantom row.

Roller conveyors slip under load, so the count drifts a little at every stop and every heavy merge; when the re-zero eye fires for a row, snap that row's position to the eye's known offset. Handle the entry conditions explicitly or they write phantom rows: two barcodes that disagree take a reject flag and no pallet number; a reader timeout takes a no-read flag; a barcode the lookup has never seen gets pallet 0; a detect with no read, or a read with no detect, raises an alarm and writes no row. Two entries firing in the same scan are harmless because rows are independent; the physical check is separate, and it is that the entry pitch exceeds the box-plus-gap footprint so adjacent entries cannot collide.

Boxes on a single conveyor never pass one another, so the order of positions never changes and the next box for the robot is the active row with the largest position. Safety stays with the robot cell's own interlocked systems; the tracking table hands over pallet numbers, nothing else.

How much position error does the network link add?

Error equals belt speed times update time: at 60 ft/min (305 mm/s) with a 100 ms update, a box can sit 30 mm off its true position, 5% of a 610 mm gap; at 500 ms the error is 152 mm and detection moves to the node. The arithmetic: 305 mm/s x 0.1 s = 30.5 mm, call it 30; 305 x 0.5 = 152.5 mm, call it 152.

Hold the error under 10% of the smallest gap so a late snapshot can never assign a box to a neighbor. At this speed that budget is 61 mm, which means an update every 200 ms. Inside the budget, latching detection in the PC against the node's count is fine. Outside it, latch at the node: the node snapshots its own counter at the eye edge and sends the finished event upstream, so network delay stops mattering because the count was taken where the box was. Both errors scale with speed: double the belt speed and 30 mm and 152 mm double with it.

Why does a shift register struggle with 18 entry points?

A shift register moves data in fixed steps from one insertion end, so 18 entries writing into the middle of the word fight over the same cells. Every shift re-invalidates the positions, and box location becomes shift timing instead of measured distance. On a single-insertion line the register still works, and the single-insert pattern is written up as shift-register box tracking in a PLC.

For 18 entries, track each box as one row in an array of records and let the encoder move the positions:

Row fields, set at insert: active (bool), barcode_1, barcode_2,
  pallet_no (1-8, 0 = unknown), position_mm (real)

On entry detect: find first row with active = false, write barcodes
  and pallet_no, position_mm = entry_offset[entry], active = true

Every scan: delta = counter_now - counter_last (unsigned, wraps at 65,536)
  for each active row: position_mm = position_mm + delta x 0.05
  counter_last = counter_now

When position_mm >= line_end: hand pallet_no to the robot handshake, clear the row

The field names above are illustrative; the structure is a free-row insert into an array of records, which any controller with indexed array access can express. Insertion at entry 3 or entry 17 is the same operation, a write to a free row.

What does a worked example give for a 100 ft line with 18 entries?

The example line splits into 18 equal entries at 5.6 ft pitch, needs about 610,000 counts end to end and rolls its 16-bit counter every 10.7 ft, and a 32-row table holds every box it can carry at 24 in pitch. Assumptions, stated as example inputs: belt at 60 ft/min, boxes 24 in long with a 24 in minimum gap, 18 entries evenly spaced, the 1,000 ppr encoder from the scaling section, updates every 100 ms.

• Entry pitch: 100 ft / 18 = 5.56 ft, about 5.6 ft. Box plus gap is 48 in = 4 ft, so each entry clears its neighbor by 1.6 ft.
• Line length in counts: 100 ft = 30,480 mm; 30,480 / 0.05 = 609,600, about 610,000 counts end to end.
• 16-bit rollover: 65,536 x 0.05 mm = 3,277 mm = 10.75 ft, so the counter wraps every 10.7 ft, roughly every 11 s at this speed; the unsigned delta in the scan loop absorbs the wrap.
• Capacity: 1,200 in of line / 48 in of pitch = 25 boxes on the line at once, so a 32-row table covers the worst case with room.
• Network check: 30 mm of error against a 610 mm gap is 5%, inside the 10% budget, so the PC-side latch stands at this speed and update rate.
• Robot side: pallet_no runs 1 to 8; 0 marks a barcode the lookup has never seen, and that box needs a defined reject path before the handshake fires.

Decision for this line: encoder plus eyes plus a 32-row table, two readers per entry because each box carries two barcodes, unless the three reader answers above collapse the whole network to two readers at the robot.

Which status screen suits a line like this?

Treat the line overview as a read-only plant display that mirrors the record table, one row per active box with barcode, position and pallet color, sized so a 15 ft viewing distance needs 0.5 in capitals at the 30 ft per inch planning figure. The planning figure is 30 ft of viewing distance per inch of capital letter height, and 20 ft per inch for fast reading, so the same 15 ft board wants 0.75 in capitals if the crew reads it on the move; set line spacing at 1.7 x capital height, 0.85 in here.

Specify the screen from the read-only process display pattern: no setpoints, no control, only the table and the eight pallet colors. Where the shift team also wants a wall board of its own, our panel-mount shop-floor screens cover that as offline playback or your own Android app. The machine HMI stays on the plant's control hardware, and a signage board is a separate screen for the shift team.

What should you ask before ordering the hardware?

Get written answers to four questions before any hardware order goes out: who consumes the barcode besides the robot, whether both labels read at the robot at line speed, whether an operator must see every box between entry and robot, and where a no-read box goes. Then ask the vendors two things: which counter-capable modules the softlogic driver reads, and whether the reader strings arrive as finished variables or as raw sockets the PC must parse. Also confirm whether the node can snapshot its counter at the eye edge, because that is what makes the 500 ms case survivable.

Commission with the tape-measure jog from the scaling section, expecting about 61,000 counts over a taped 10 ft, then time 20 boxes past an entry and confirm each row lands within the error budget when the re-zero eye fires.

Recommendation: Ask first whether anything besides the robot consumes the barcode mid-line. If nothing does, mount two readers at the robot and delete the 36-reader network, the 18 remote nodes and 70 ft of serial runs. If something does, run a 1,000 ppr quadrature encoder at x4 on the drive, put a photoeye at every entry plus one re-zero eye before the robot, latch detection at the node whenever speed x update time exceeds 10% of the smallest gap, and track each box as one row in a 32-row record table.

Questions