Barcode part number parameter lookup: PLC memory or PC database

You have a reader that delivers a part number, a machine that needs ten running parameters for that part, and a part list about 1,000 entries long. The architecture hangs on one question: where does the table of parameters live? Sizing answers it — 1,000 rows cost about 15,000 words of PLC data memory — and the answer is to keep the table on the PC side and hand the PLC the ten resolved parameters. This guide sizes the table, compares PLC, HMI and PC storage, spells out a 13-word handshake, and names hardware for each role.

How much PLC memory does a 1,000-part lookup table need?

Plan on 15,000 words — about 30 kB — of data memory for the table alone: 5,000 words of part-number keys plus 10,000 words of parameters, before any of the ladder that searches it.

A ten-character part number, packed at two ASCII characters per 16-bit word — the standard packing covered in storing ASCII barcode strings in PLC memory — takes 5 words. Ten parameters at one 16-bit word each take 10. That is 15 words a row.

Worked example: 1,000 rows × 15 words = 15,000 words. At 2 bytes a word that is 30,000 bytes, about 30 kB. If two of the ten parameters are 32-bit floats, the row grows to 17 words (5 key + 8 integer + 4 float) and the table to 17,000 words, about 34 kB.

Then come the platform limits. Compact CPUs carry anywhere from a few kwords to tens of kwords of data memory, and the part that survives a power cycle is smaller: one current compact CPU keeps only about 10 kB retentive, and one widely used built-in recipe function tops out at 256 recipes. A 30 kB table does not belong in that world. For how the same arithmetic plays out on a small controller, with a worked mapping example, see this recipe lookup table for part-number mapping; the memory math is identical.

Should the table live in the PLC, the HMI or a PC database?

For 1,000 parts, put it in a PC-side recipe database — a SQL table or a versioned file on a vision controller or SCADA PC — and move only the ten resolved parameters, about 13 words with housekeeping, into the PLC.

The boundaries: under about 200 parts the PLC is a reasonable home, at 200 × 15 = 3,000 words. Up to a few hundred parts with an operator confirming each change, HMI recipes work. At 1,000 parts, or the moment more than one line shares the table, use the database. The pattern is the same as a GTIN product lookup after a scan, with your parameter table where the product catalog sits, or routing a reader result to robot job selection, where the string picks a program instead of ten numbers.

How slow is a PLC table search, and how do you speed it up?

A linear search compares all 1,000 keys every scan — about 5,000 word-compares — while a binary search over sorted keys needs about 10 compares, or 50 word-compares, and a database index on the host side is faster still.

Count the compares. One ten-character key is 5 words, so a linear walk through 1,000 rows is 5,000 word-compares per scan plus loop branching. Sort the keys and halve the field ten times: log2(1,000) ≈ 10 steps, each comparing one 5-word key, so 50 word-compares. That 100-to-1 ratio is arithmetic; the microseconds per compare differ by CPU, the ratio does not. A ladder treatment of string comparison is in comparing barcode strings in ladder logic, and the sorted-array version is worked through in this efficient array search in a part-number table.

On the host side there is nothing to optimize. An indexed 1,000-row lookup returns well under a millisecond, and the LAN write of 13 words is the slow leg at a few milliseconds.

What should the host write back to the PLC?

Thirteen words: the ten parameters, a row index, a status word and a sequence counter. The PLC triggers on the counter change and reads status before it trusts anything.

1. The reader decodes and sends the string to the host, stripped of line endings and padding — stray CR and LF characters are the classic no-match cause.
2. The host accepts the decode only above your confidence threshold; judging that threshold is covered in barcode read confidence.
3. The host writes the ten parameters, then the row index, then the status word, and increments the sequence counter last.
4. The PLC sees the counter change, checks status 0, latches the parameters and pulses an acknowledge bit.
5. If the counter has not moved within 500 ms of the scan trigger, the PLC holds the last good recipe and alarms.

Status codes worth standardizing now: 0 match, 1 no match, 2 no decode, 3 duplicate key in the table. The 500 ms timeout is deliberately loose — the handshake runs in single-digit milliseconds, so 500 ms absorbs a retry without letting a part reach the machine unset. The host-to-PLC leg deserves the same planning as the reader link; see planning a reliable barcode reader to PLC link.

Which code reader fits a parameter lookup station?

Any Ethernet code reader that pushes the decoded string to the host on its own connection: that keeps ASCII out of the PLC and leaves the PLC with a 13-register result block to read.

Decide first where the decode happens — reader, vision system, MES or web service — because that choice sets the whole data path; the trade-offs are laid out in barcode reader module confusion: vision vs MES vs web scanner paths. For this architecture the reader decodes and the host looks up.

The MV-ID3013PM-12M-WBN is the compact Fast Ethernet type: 1.3 MP, 12 mm focal length, global shutter.

Two 1.2 MP readers cover the wiring extremes:

The LS-CRD-0052 carries the string over Ethernet with a 12 mm focal length, for the direct-to-host path. The LS-CRD-0047 is the USB 2.0 reader with a 60-120 mm reading distance — the pick when the string must land in a PLC module rather than a host, the path described in reading a barcode scanner into a PLC over serial.

Filter the fixed code reader finder by interface for the full range; more on inline reading sits under the code reading topic.

What hardware should run the recipe database?

A fanless vision controller: one box talks to the reader, runs the lookup and writes the PLC registers, with no office PC in the cabinet.

The MV-VC3301H-128G66 pairs an Intel Core i3 processor with 8 GB of memory, 5+ LAN ports and 4 built-in light channels, and it ships with a VM6200Pro license.

The MV-VC2140-128G40-1T runs an Intel N-series processor with 8 GB of memory and 4 built-in light channels.

Against a 30 kB table, that memory size is five orders of magnitude of headroom, with room for a full parameter history alongside it.

All 2 share: Memory 8 GB; Power supply 24 VDC; Certification CE, KC. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

The table itself is a SQL table or a versioned CSV with one owner. When several lines share the parameters, one database beats copies scattered across panels, and an edit reaches every line the moment it is saved. If your carrier is an RFID tag instead of a printed code, the same lookup pattern applies — see this RFID part-number database lookup and comparison.

When is storing the table in the PLC the right answer?

Under about 200 parts with 16-bit parameters: 200 rows at 15 words is 3,000 words, which a compact CPU can spare, and the machine then runs with no host and no network in the loop.

Sort the keys once, store keys and parameters as parallel arrays, and search with the binary walk from the section above — 10 compares at 1,000 rows, 8 at 200. If the scan carries more than the part number, split out lot and serial fields first, as in splitting barcode string data into fields. Keep the table in retentive memory if parameters must survive a power cycle: 3,000 words is 6 kB, inside a 10 kB retentive area, outside the older kword-scale ones.

This is also the answer for standalone machines with no Ethernet run to a host, and for cells where adding a PC would add an operator question rather than remove one.

What should you check before ordering anything?

Four numbers and one policy: row count, parameter width, free data memory on the CPU, and who edits the table — the policy is what the machine does when no row matches.

• Size the table first: rows × (key words + parameter words); at ten characters and ten parameters, 15 words a row.
• Split total data memory from retentive memory on your CPU; the table must fit the second if parameters must survive power-up.
• Count LAN ports against devices: one for the reader, one for the PLC, one for the plant network.
• Write the no-match policy now — stop and alarm, or a default recipe under operator override — and the status codes with it; the same discipline drives barcode to part verification on similar assemblies.
• Time the handshake once with a real string; single-digit milliseconds is the target, 500 ms the alarm.
• Confirm that part 1,001 can be added without a PLC download and without stopping the line.

Where does a host-based lookup fail?

When the host stops: a lookup on the PC dies with the PC, so the PLC must hold the last good recipe, and a watchdog must stop the machine when the sequence counter stops moving.

The other failures are quieter. Duplicate keys resolve to the wrong parameters — put a unique index on the part-number column and status 3 reports the attempt. A string with a trailing character never matches; set the reader's suffix handling once, at configuration. Two scans in flight overwrite each other only if you skip the sequence counter; one acknowledge per counter value closes that. An edit that lands mid-cycle is harmless as long as the write order stays parameters first, counter last.

When the numbers and the architecture are settled, configure the station or ask us to size the reader, the host and the handshake against your part list.