A SLAM line is seven steps, and one of them decides whether the other six are straightforward or impossible: knowing what the parcel is. When it carries a license plate your own system printed, that is a lookup. When it arrives wearing somebody else's label, or nothing useful at all, it is a reading problem. We build lines that handle both, and we own the part that decides whether the reading actually works.
Schematic, not a spec. Every parcel above arrives unlabeled and leaves identified, dimensioned, labeled, verified and sorted.
Scan, label, apply, manifest is the short name for a longer sequence. Here is the whole thing, each step named, including the one piece of it we buy.
One machine in that sequence we buy, and we have just named it. The rest is conveyor, controls, vision and commissioning, which is the work this company came up through.
Most SLAM equipment assumes the first one. It is the only case a lot of lines can handle, and it is precisely the case that does not apply to forwarders, consolidators, 3PLs, returns operations, or anyone handling product they did not pack themselves.
That third mode is the one worth noticing. It takes your IT department and your software vendor off the critical path of the project. Integration becomes something you add later, not a prerequisite that stalls an install for six months.
A decoded barcode is effectively certain. Check digits and error correction make a misread vanishingly rare, which is why we read barcodes first, from every face, on every parcel. OCR always carries a confidence score. Any vendor who tells you otherwise is selling you a demo rather than a line.
So OCR is not a replacement for scanning. It is what handles the three things scanning cannot:
Used that way, OCR does not compete with your scanner. It takes parcels out of your exception lane, which is a number you already track and already dislike.
Four parcels off a normal inbound mix, none of them carrying a barcode we printed. Watch what happens to the second one, where the barcode does not decode at all. The fourth is the case most demos leave out.
Anyone can call an OCR model, and the model is the commodity now. What actually decides whether a recipient name comes off a flat poly bag moving on a belt is none of it. Parcel identification is its own discipline, and it is the one we went and learned properly.
Read rate is set by how many pixels land on the smallest text you need. That is mount height, lens choice and sensor, and it is arithmetic you do before buying anything. Lowering a camera two feet is routinely worth more than any change to the software behind it.
Depth of field falls with the square of distance, and a mixed parcel population moves the target on every trigger. A fixed focus that works on cartons will not hold on envelopes and totes, so the height is measured per parcel and the focus is commanded rather than assumed.
Strobed illumination sized to belt speed, and a trigger fired from the PLC rather than off a leading-edge photo-eye, so the parcel lands centered in the frame instead of clipped at the bottom. The PLC also mints the transaction ID, so every image maps to a parcel exactly rather than by timing.
We work a read the same way every time, and the order matters: baseline capture first, then aperture, then illumination, then exposure, one variable at a time. Character height is measured in pixels at the sensor rather than judged by eye off a screen, because that is the number that predicts the read. A recipient name landing 17 pixels tall will not read dependably; the same name at 24 pixels reads consistently, and closing that gap is a mounting and optics decision every time. Lower the camera, and now you owe the design commanded focus and a height measurement to drive it. Exposure sits in the low hundreds of microseconds so a parcel moving down the belt does not smear across the characters, which then sets how much light you need and where it has to come from. Shipper templates are built once per carrier and tuned on your own traffic, because your label mix is not anybody else's.
None of that is software, which is exactly why a software vendor cannot sell it to you. When a read rate drops, the cause is a camera that drifted, an illuminator segment that died, a belt running faster than it did in June, or a batch of labels printed light. Finding out which is our job, not yours, and the system reports its own health to a screen in the building and to us remotely: camera, lighting, read rate, exception rate, host round trips. A drift is noticed in minutes rather than at the end of a shift.
This is the argument the company was built on, pointed at cameras instead of steel. When a line will not hold rate and three vendors each own one piece of it, every conversation becomes a jurisdiction problem. We do all of it.
Which means we will put an identification rate in the contract. Because we specify and own the optics, the lighting, the mounting geometry, the trigger and the parcel presentation, the read rate is ours to be accountable for. Acceptance is a defined run of consecutive parcels at a measured automatic identification rate, proven before you rely on it. A software vendor cannot structurally make that commitment. A device manufacturer will not make it for OCR.
Receiving and shipping run the same seven steps, with the same devices, in the same order. What reverses is where identity comes from and which way the data flows. Outbound, your system tells the line what the parcel is. Inbound, the line tells your system what just arrived.
Inbound is the harder version, and not by a little. Outbound parcels are yours: your cartons, your labels, in a known place, oriented by your own packing process. Inbound is whatever showed up: poly bags, crushed corners, labels rotated flat against the face, handwritten freight labels, and the ones facing away from the camera entirely. Exception handling stops being an edge case and becomes a section of the proposal, because how a flagged parcel gets resolved on the floor changes the footprint of the whole station.
We build both, and the identification platform behind them was built for the inbound case first. That makes the outbound line the easier application of a system that already has to work under worse conditions.
Not every parcel crosses a belt, either. Oversize items, freight, pallets and anything received at a door away from the line need the same identification and the same record. The same shipper templates and confidence logic run against a handheld or phone camera, posting through the same interface to the same place. One set of templates, one confidence model, one destination for the data, whether the parcel came down the line or through a dock door.
Identification software is sold by the scan often enough that it is worth saying plainly how ours works.
A SLAM line's ceiling is not the camera and it is not the conveyor. It is the print-and-apply head. Print the label, tamp it, retract, reset. That is a mechanical cycle, and most heads settle around 30 cartons a minute regardless of how fast you feed them. Anyone quoting you a SLAM line well above that number on a single applicator is quoting you something else.
So running faster is a parallel problem, not a faster-machine problem. You split the stream, apply on two or more heads at once, and merge back, all while tracking every parcel's identity across the split so the right label reaches the right box and the sorter downstream still knows what it is holding. None of that is vision work. It is gapping, divert timing, product tracking and merge logic, which is the work this company came up through.
This is a zipper merge we commissioned, running in production: two lanes combined into one continuous stream, with dynamic gapping logic in the PLC setting each release so cartons arrive singulated with exactly the separation the downstream scanner and sorter need, without stopping the line to meter and without an operator babysitting a jam. Getting a SLAM line past one applicator's rate is that same problem, run in reverse.
Straight about where we are. The conveyor, induction, gapping, controls, integration and sortation above are work we have delivered and commissioned, and the merge behind those numbers is in production today. The identification side (in-motion barcode and OCR capture, dimensioning, print and apply) is a system we are building and commissioning now, with a measured accuracy benchmark in progress. We would rather tell you that here than have you discover it together with us during startup.
SLAM stands for scan, label, apply, manifest, and it is the short name for the last hundred feet of a shipping operation. In practice it is seven steps: induct and gap the parcels, identify each one, dimension and weigh it, manifest it to whatever system owns the carrier relationship, print and apply the label, verify the right label landed on the right parcel, and sort by carrier or destination.
Yes, and that is the case we built for first. There are three ways to know what a parcel is: look it up from a license plate your own system printed, read the label and post a new record to your system, or read the label and resolve it against a consignee list held on the line with no host integration at all. Most SLAM equipment only handles the first. Forwarders, consolidators, 3PLs and returns operations need the other two.
No, and you should be careful with anyone who tells you it is. A decoded barcode is effectively certain because of check digits and error correction, while OCR always carries a confidence score. That is why we read barcodes first from every face. OCR handles what scanning cannot: the fields no barcode carries, the parcels where the barcode is damaged or facing away, and verifying that the printed text matches the record.
The constraint is almost always the print-and-apply head rather than the conveyor or the camera. Print, tamp, retract and reset is a mechanical cycle, and most applicators settle around 30 cartons per minute regardless of how fast product arrives. Running meaningfully faster means parallel applicators: split the stream, apply on two or more heads, merge back, and track every parcel's identity across the split. That is conveyor and controls work, which is the part we do in house.
Usually you already have what is needed. If your WMS or host system rate shops and generates labels today, the line requests the label, applies it, verifies it, and posts the dimensions, weight and confirmation back. If parcels reach the line already labeled, it verifies and sorts them. If there is no shipping execution layer at all, we scope one with you. The line gets built around whichever of those you actually have, rather than requiring you to buy something first.
No. A line can read the label, resolve the consignee against a list held locally, print, apply, verify and sort with no host integration whatsoever. That keeps your IT department and your software vendor off the critical path of the project. Integration to your WMS or host is an upgrade you add later rather than a prerequisite that stalls the install.
Yes. Because we specify and own the optics, the lighting, the mounting geometry, the trigger and the parcel presentation, the identification rate is ours to be accountable for. We define acceptance as a run of consecutive parcels at a measured automatic identification rate, proven before you rely on the system.
Yes. Receiving and shipping run the same seven steps with the same devices in the same order. What reverses is where identity comes from and which way the data flows: outbound your system tells the line what the parcel is, inbound the line tells your system what arrived. Inbound is the harder version because the parcels and the labels are not yours, which is the case our identification platform was built for first.
Outbound, inbound, or a camera tunnel somebody stopped supporting. Send us your parcel mix, your rate, and what your labels actually look like, and we will come back with a real scope.