Barcode verification for pallet to trailer confirmation on vehicles

A pallet loaded into the wrong trailer is discovered at the receiving dock, hours later and hundreds of kilometers away. The fix is procedural, not exotic: one scan at the pick, one scan at the trailer door, and a controller that confirms the two IDs match before the forks lift or the load rolls. What follows is that workflow for an electric forklift with a PLC and a wireless link: where each read point goes, how to size the optics from the label you actually print, which data path avoids the HMI focus trap, and the interlock logic that turns a mismatch into a stopped load. The worked example uses a 0.495 mm GS1-128 pallet label and a 5 MP Ethernet reader, so you can substitute your own numbers and re-run the same three lines of arithmetic.

How the two-scan match gates a move

The controller runs the move; the driver executes it. The warehouse system hands the PLC a move list: door D-12 takes the pallets whose SSCC labels end 4319 and 4320, door D-14 takes 4402. The SSCC is the 18-digit serial shipping code on the pallet label, so each pallet and each door carries a unique, machine-readable identity. Two reads then gate every move, one at the pick and one at the door, and each read is a single event: decode, compare, accept or reject. The physical commit only follows a pass.

This is the same discipline as barcode verification before picking with multiple robots, moved from the robot cell to the dock: check the ID before the actuator moves. Ethernet code readers decode in tens of milliseconds, so the checks add no waiting of their own.

Take the scans into the PLC, not the HMI

Where the decode lands decides whether the workflow survives its first shift. The common trap is a panel that ingests barcodes through a text-entry object: that object must hold focus, so a scan fired while any other screen element is active is dropped without a trace. A driver should not touch the screen between two scans, which makes focus management a design flaw here rather than an operator habit. That is why the barcode scanner input methods to a PLC: serial, USB and Ethernet question comes before any hardware choice.

Three paths put the decode straight into the controller:

• TCP over the truck's wireless client adapter. The reader holds a socket to the host, and the TCP client or listener decision decides which side re-connects after a roaming drop.
• EtherNet/IP implicit I/O. The reader-to-PLC implicit I/O assembly map turns each decode into input bits the scan cycle already watches.
• Serial. An RS-232 link into a PLC serial card: reading a barcode reader into a PLC over Modbus RTU covers the serial route, and prefix and suffix framing keeps a partial frame out of the match logic.

USB into a panel as an HID keyboard is the wedge path, and the focus catch returns with it. If a legacy panel forces that route, barcode scanner to a PLC tag: keyboard wedge scripting shows how to drive focus programmatically, and barcode scanner to an HMI serial port: framing data without headers shows the serial alternative that sidesteps focus entirely. Take TCP or EtherNet/IP on the truck, serial where the network is unreliable, and treat the HMI as a display only.

Where the two read points go

The door read is a fixed geometry, so build it as one. Print one label per door, SSCC-style code plus door ID at roughly 150 x 100 mm, centered about 2 m above the floor where nothing stacks against it. Mount the reader on the cage front at eye height, aimed square at the label, and paint a stop mark on the dock so the truck halts with the label about 600 mm from the lens. Fixed industrial code readers carry their own LED illumination, so the read does not depend on dock lighting.

For that job a compact fixed reader with a 12 mm focal length, 1.3 MP resolution, Fast Ethernet and an M12 mount puts a narrow field over one label:

The pick point has two workable shapes. A short-range reader bracketed to the carriage guard reads the pallet label as the forks slide in, with no operator action at all:

Mount it so the label passes 80-100 mm from the window, mid-band of the range with margin on both sides, on a bracket that shrugs off fork-entry shock. If labels sit inconsistently or shrink wrap hides them, the fallback is a handheld scan at the pick face, spending 3-4 s of operator time only where the fixed geometry cannot reach.

Worked example: a 0.495 mm pallet label at 600 mm with an 8 mm, 5 MP reader

Three inputs set the whole calculation:

• Label: GS1-128 SSCC at the 0.495 mm (19.5 mil) X-dimension GS1 recommends as the floor for general-distribution scanning. Pallet labels print at or above it, so this is the small end of the real range.
• Reader: a 5 MP fixed code reader, 2560 pixels wide, 8 mm lens, 1/1.7-inch sensor.
• Working distance: 600 mm from lens to label, the stop gap set by the cage mount above.

The reader carrying those numbers decodes at 60 codes/s over Fast Ethernet, with a 2560 x 2048 sensor and an 8 mm lens:

Field of view at the label scales linearly with distance. A 1/1.7-inch format sensor has an active width of about 7.4 mm, the standard size for the format, which puts every number on the table:

At the 600 mm stop:

• FOV = 600 mm x 7.4 mm / 8 mm = 555 mm
• scale = 555 mm / 2560 px = 0.217 mm per pixel
• pixels per module = 0.495 mm / 0.217 mm = 2.3 px per module

The rule the decision hangs on: a module needs at least 2 pixels for a reliable decode, and 3 or more before worn prints still read. At 600 mm this label sits at 2.3 px per module, above the decode floor but short of the comfort floor. The margin lives or dies with the stop, so move it. At a 400 mm stop the same reader delivers a 370 mm FOV, 0.145 mm per pixel and 3.4 px per module; at 300 mm it reaches 4.6. Fix the stop mark at 400 mm and the workflow keeps print-wear margin for the life of the label stock. Where the dock truly cannot give 400 mm, this same arithmetic tells you the pixel count to shop for instead of hoping.

These reads happen with the truck stopped, which keeps exposure out of the problem. If you also want decodes while creeping toward the door, motion sets the exposure budget instead, and high speed barcode verification: size the strobe pulse works that arithmetic for moving targets.

The match logic and the commit interlock

The PLC needs six registers and one rule. It holds REQ_PALLET (the SSCC assigned to this move), REQ_DOOR (the door that pallet is assigned to), GOT_PALLET and GOT_DOOR from the two readers; comparisons set PICK_OK and DOOR_OK. The commit bit, the one that allows the lift at the pick and the put-down at the door, is PICK_OK AND DOOR_OK, with two more terms in the AND: comms healthy, and the match not expired. Expire a match after 60-90 s, so a scan at door D-12 cannot authorize a put-down at D-14 minutes later.

Gate every accepted decode on the reader's confidence score. Barcode read confidence: how to judge whether a decode is trustworthy explains what the score reflects. Set the floor in bench testing so a smudged label cannot inject a wrong SSCC into a comparison, and treat a below-floor read as a no-read rather than a mismatch, so the operator rescans instead of raising an exception.

If the PLC commands each capture, prove the handshake before go-live: a capture command that dies silently looks identical to a missing label, and barcode scanner serial trigger: fix silent host commands walks that diagnosis. The compare-and-commit pattern is the one used to check a scanned ID against an expected part in barcode to part verification for similar assemblies, scaled from a component to a pallet. When the pick runs on a lift table rather than the forks, the same interlock applies, and PLC pallet lift design: position sensing and barcode integration walks a barcode read into a lift's position logic.

Which reader goes at which point

Both read points are solved problems; the choice is interface and range. The fixed code readers and handheld code readers pages sort by exactly the filters that matter here, and the fit per point looks like this:

Handhelds earn their slot on exception duty: the re-scan after a no-read, a pallet the wrap ate, a yard trailer without a door label. Two formats cover it, wireless over the site network and wired USB at a fixed terminal:

A two-reader truck, fixed at the door and short-range or fixed at the carriage, keeps every routine scan hands-free. The handheld is the third input, not a replacement for either.

Checks before you order

1. Re-run the arithmetic with your own label. Read the X-dimension off a live pallet label, measure your real stop distance, and compute pixels per module. The 2 px floor and the 3 px comfort line settle the mount before anything is bought.
2. Bench-read a worn label at the planned distance. Fresh print passes at 2.3 px per module; a scuffed one may not. One afternoon of bench testing settles it.
3. Grade incoming labels. Supplier print quality varies more than reader sensitivity does; barcode reader verification for label inspection covers judging a label before blaming the reader.
4. Fire 100 triggered scans and count decodes. A silent drop in the handshake shows up as missing decodes, not as error messages.
5. Roam-test the wireless path. Drive a loaded truck past every dock door and watch the 2 s comms watchdog clear the commit bits; the match must fail safe, never go stale.
6. Audit label placement across suppliers. The carriage window reads what passes it, so a supplier that labels the wrong face breaks the geometry, not the code.

When two scans per move is the wrong shape

Conveyor-fed docks do not need a forklift stop at all: a fixed reader at each door threshold scans every label that crosses it, and the same PLC logic matches without a driver in the loop. Sites where shrink wrap swallows labels or orientation is chaos sometimes pair RFID with the barcode reads, so the pallet announces itself hands-off and the barcode stays as confirmation. The two-scan workflow survives both; only the pick read changes how it arrives.

And if the operation is one door, one pallet type and a handful of moves a day, a prompted single scan is enough. Build the interlock when a misload costs more than the hardware, which at receiving-dock volumes it almost always does.

Spec it from your dock layout

Measure the stop distance, read the X-dimension off a live label, and re-run the three lines above; the mount decision falls out in a minute. Then send the dock layout, a sample label and the target scan points through the quote request and we will match a reader to each point and confirm the interface your PLC speaks. The camera finder filters fixed readers by interface, resolution and mount if you want to shortlist first.

The code-reading topic page collects the rest of the integration guides, from serial framing to confidence scoring.