Barcode-Based Tightening Program Selection: How to Map Product Codes to Programs

A barcode scanner may read a product label correctly while the workstation still calls the wrong tightening task. On a mixed-model assembly line, barcode-based tightening program selection needs a clear relationship between the product code, the required assembly task, and the tool programs used at each fastening point.

This guide explains how to identify the barcode fields used for selection, build an unambiguous product-code-to-program map, and check that the selected program matches the request. You will also learn what to specify for unknown codes, repeated scans and mid-cycle changes, and how to validate the mapping before production and after configuration changes.

What Should the Barcode Select: a Product Recipe or a Tool Program?

Start by defining what “program” means in your workstation. A product-level assembly task and a tool’s tightening program can represent different layers of the process. Their names and relationships depend on the equipment and software.

Separate the Product Recipe from the Tool Program

In this guide, a product recipe means the configured assembly task for a product or variant. It can identify the required fastening points, their sequence, and the tool program assigned to each operation.

A tool program means the approved tightening settings executed by the tightening equipment for an operation. Use your equipment’s documentation to identify which object contains those settings and which object organizes operations or sequences. Record the exact object type and identifier in the mapping.

A useful relationship to document is:

Product code → product recipe → fastening point or step → tool program

One product recipe may therefore require several tool programs. Conversely, products with the same approved fastening requirements may share a tool program while retaining different point layouts or task sequences.

For example, the KURAN KR002-H01 supervisory controller supports product-specific program management and point-specific Pset assignment for compatible tightening equipment. The actual program interaction depends on the connected equipment and configured interface.

Distinguish Selection from Permission to Operate

Selecting a recipe does not establish that every condition for tightening has been satisfied. Your process may also require confirmation of the fixture, accessory, tool position and active tool program.

Before defining barcode rules, list what a scan should change, what must be confirmed afterward, and what permits the operation to start. Specify automatic starting separately if your application requires it.

Which Barcode Fields Identify the Required Tightening Process?

Build the selection key from the information that determines the approved assembly process. A label may contain a product number, variant, revision, batch and serial number, but those fields do not necessarily serve the same purpose.

Separate Process Selection from Product Traceability

Start with your approved process instructions. Identify which product differences change the required recipe, fastening points, sequence or tool programs. Use those differences to define the selection fields.

A serial number can identify an individual unit without directly describing its required process. If selection uses a serial number alone, the system needs a defined lookup that connects that unit to the applicable product configuration.

For GS1-structured labels, GS1’s explanation of Application Identifiers distinguishes identification keys from attributes such as serial and batch numbers. This distinction applies to GS1 data; your internal labels may follow a different structure.

Consider this illustrative internal code, not a GS1 format or a confirmed KURAN input format:

PN=AX20|VAR=L|REV=B|SN=000184

If the approved process differs by product number, variant and revision, those three fields could form the selection key. The serial number could remain associated with the individual unit’s records. Whether the revision belongs in the key depends on whether it changes the applicable process.

Inspect What the Receiving System Actually Gets

Compare the printed label with the string received through the intended scanner connection. The visible label alone does not define the transmitted message.

The SICK IDM programming manual, Chapter 7 documents configurable prefixes, suffixes, record terminators and code identifiers for its covered scanners. These settings illustrate why the receiving application’s input should be checked; other scanner models require their own documentation.

Capture representative inputs and check:

• Whether leading zeros, letter case and separators arrive as expected.
• Whether prefixes or terminators are added.
• Whether field lengths are fixed or variable.
• Whether different label versions use the same field order.

Define an Explicit Extraction Rule

Document how the receiving application extracts and validates the selection fields. Fixed character positions require a stable layout; delimiter-based extraction requires defined separators and field boundaries. Structured formats require a compatible parser.

Avoid removing characters simply to make a failed match succeed. A revision letter or leading zero may distinguish valid configurations. Test the proposed rule against similar codes and malformed inputs, and confirm where it can be implemented before treating it as an available controller function.

How Do You Build an Unambiguous Product-Code-to-Program Map?

Turn the selection fields into a controlled mapping register before configuring the system. The register should show which approved assembly task applies to each recognized product configuration and how its operations relate to tool programs.

A spreadsheet can support this planning work. Whether the finished mapping is entered manually, imported or maintained elsewhere depends on the selected system’s capabilities.

Define the Scope of Each Mapping

Specify the workstation and process stage covered by the register. The same product may require different operations at different stations, so a product code alone may not provide enough context.

For each mapping, record:

• Selection conditions: the product fields and any station or process context used to identify the task.
• Product recipe and revision: the assembly task to load and the approved version to use.
• Operations and tool programs: the point or step IDs and their assigned program numbers.
• Equipment context: the tool and controller to which those program numbers belong.
• Release information: the approval reference, responsible owner and whether the mapping is available for production.

Keep product revision and recipe revision in separate fields. A product’s drawing revision and a workstation configuration revision serve different purposes; document their approved relationship rather than assuming their identifiers match.

Build the Map Around Approved Operations

Use the point IDs from your fastening-point map so drawings, work instructions and program assignments refer to the same operations.

The following is an illustrative planning table for station ST01 and one designated tool controller. All codes, recipe names and program numbers are invented examples. The table is neither a controller import file nor an industry-standard format.

For the earlier sample, PN=AX20|VAR=L|REV=B|SN=000184, the proposed rule extracts one PN, one VAR and one REV field and uses AX20 / L / B as the exact-match key at ST01. The first row should select AX20-L, recipe revision 03, with tool program 11 at P01 and program 12 at P02. Keep SN=000184 as the unit identifier rather than part of this selection key. If a required selection field is missing or duplicated, leave the selection unresolved for review. These are example rules to verify against the chosen implementation.

The third row exposes a missing association. Resolve it against the approved process before making that product configuration available for normal production.

Check for Conflicting and Missing Matches

Within the defined station and process context, each accepted selection key should lead to one applicable recipe.

Review the mapping in both directions. First, check that every product configuration intended for the station has an approved association. Then check that each association points to an existing, intended recipe and the correct equipment’s programs.

If the implementation uses prefixes, partial strings or wildcard rules, test whether one input satisfies several rules. Do not rely on whichever entry happens to be processed first. Define explicit exclusions or a documented priority where the system supports it, or narrow the conditions until the result is unambiguous.

Also check retired codes, leading-zero differences and label revisions. Keep serial identifiers outside the selection key when they do not determine the process, while retaining the required unit association separately.

Release the Mapping with Its Dependencies

Record the approved mapping version together with the recipe revision, tool-program references and supporting process instruction. Check those dependencies whenever an entry changes.

Before configuration, the process owner should verify the required operations, while the integration team verifies that the planned matching method and program references can be implemented. This provides a reviewable basis for the selection and exception tests that follow.

Where Should the Mapping Run, and How Is the Selected Program Confirmed?

Assign responsibility for the mapping before deciding where to connect the scanner. The device receiving a barcode is not necessarily the device that identifies the product configuration, maintains the recipe or selects the tool program.

Choose the Mapping Location Around Existing Responsibilities

Review these implementation routes against the documented capabilities of your equipment:

• Tool-controller mapping: consider this where the controller supports the required barcode association and the task can be managed within its available functions. Confirm matching rules, program references and configuration access.
• Workstation or supervisory software: consider this when product selection must coordinate point layouts, operation sequences and tool-program assignments. Confirm how the selected task reaches each connected device.
• PLC or production-system mapping: consider this when an existing system already determines the product configuration or work order. Define which information it sends and which layer converts that information into a workstation task.

These are planning options, not functions available on every controller.

The KURAN KR002-H01 supervisory controller provides barcode-based program calling through configured associations. Its product documentation also identifies tool interfaces and program interaction as configuration requirements. Confirm the proposed allocation of responsibilities against the actual scanner, software and tightening equipment.

Whichever arrangement you choose, identify who approves the mapping and who deploys it. If several devices hold copies, define how their versions are checked together.

Separate Receipt, Selection and Confirmation

Document the following stages as distinct events:

1. Barcode received: the receiving application has captured the intended message.
2. Mapping resolved: the selection fields identify one applicable, approved recipe.
3. Selection requested: the required recipe or tool-program command has been issued.
4. Selection confirmed: available equipment feedback or another agreed verification method establishes what has actually been selected.

A scanner beep confirms only what the scanner documentation defines. Likewise, receipt of a communication message should not be treated as proof that the requested tool program is active unless the interface documentation establishes that meaning.

For automatic comparison, specify the requested and reported values, the relevant tool or controller, and the conditions under which confirmation remains valid. Program identity also needs the correct equipment context; its number alone does not verify the approved settings behind it.

Define the Permission to Proceed

Use the confirmed selection as one condition within the workstation’s agreed operating logic. Other required conditions may include the correct fixture state, accessory and tool position.

Decide what happens while selection is pending and when confirmation is missing or inconsistent. Set any response-time requirement from the actual workstation needs and verify it during commissioning.

If the interface cannot report the information needed for automatic verification, record that limitation. Agree on a supported verification method and its acceptance criteria before production release. Keep program selection, permission to operate and the start command separately defined.

What Should Happen When a Scan Is Unknown, Repeated or Received Mid-Cycle?

Define the response to each scan event before production, including what happens to the current task. An unreadable label, an unknown product and a repeated scan require different decisions. Treating them as one generic “barcode error” can leave operators unsure whether to rescan, change the product or request assistance.

Distinguish Missing Input from an Unresolved Selection

Specify separate responses for these conditions:

• No usable input: establish whether the scanner decoded the label, whether it transmitted a message, and whether the receiving application accepted that message. Investigate the failed stage before changing the label or program association.
• Unknown code: a complete input arrives, but its selection fields have no approved mapping. Check the product identity, label version and mapping release status.
• Conflicting matches: the input satisfies more than one selection rule. Resolve the conflicting rules rather than allowing an arbitrary selection.
• Unavailable target: the mapping identifies a recipe or tool program that is missing or unavailable on the intended equipment. Check the deployed configuration and program references.

For unresolved selection, specify a condition that prevents the next product task from starting under an unverified association. Make the operator message identify the problem and the permitted next action. Handling an already-running operation requires its own agreed process.

Decide What a Repeated Scan Means

The same scanned value does not always mean the same production event. A model-level code may legitimately appear on many consecutive units. A second scan during one unit’s task may instead be an accidental repeat.

Evaluate the input against the current task and the identifier’s meaning. Document whether a repeat should leave the task unchanged, request confirmation or initiate a new task after the previous one has been completed and the next unit identified.

Avoid a rule that simply ignores every repeated value: it could prevent the next valid unit from being processed. Equally, repeated input should not silently reset completed points or erase an unresolved task.

Control Scans Received During an Active Task

Specify when a new product selection is permitted. For an unfinished task, a proposed rule is to reject or defer the new selection until the current task is completed or an authorized interruption procedure is followed.

If interruption is permitted, retain the previous product identity, completed operations and outstanding work. A new scan must not relabel records belonging to the previous product. Define the conditions for returning to that unfinished task.

Finally, include incorrect-label scenarios in the review. A readable, recognized code does not independently establish that its label belongs to the workpiece in the fixture. Identify any additional product or fixture checks required by your process, and verify the configured responses during commissioning.

How Do You Validate the Mapping and Keep It Correct After Changes?

Validate the complete path from the received code to the selected task and its assigned tool programs. A successful scan or correct product name on the screen is only one observation. Acceptance should demonstrate the relationships defined in the approved mapping and operating rules.

Set Expected Results Before Testing

Prepare a test list from the mapping register. Include every product configuration intended for the workstation, together with representative inputs that challenge the selection rules.

For each test, specify the input, starting task state, expected selection, permitted operation and evidence required. Establish these expectations before running the test so an unexpected response does not become the acceptance criterion.

Use the intended scanner connection, deployed software, tool controller and approved program configuration. Record their identities and versions where available.

The following is a proposed test framework, to be adapted to your approved process and supported equipment functions:

Keep Evidence That Explains the Result

For each test, retain enough information to reconstruct the selection:

• Original input received by the application.
• Extracted fields and mapping version.
• Expected and requested recipe or program.
• Observed selection and the source of confirmation.
• Relevant tool/controller identity and starting task state.
• Pass/fail decision, unresolved issue and retest reference.

Where automatic feedback is available, compare the request with the reported selection. Where another verification method is used, identify exactly what was checked and its limitations. A communication acknowledgment should be interpreted according to its documented meaning.

Also follow a representative task through its required operations. Check that the point or step references lead to the intended tool programs and that any required product association remains correct in the available records. Keep the approved tightening requirements linked to those program references.

Recheck the Mapping After Relevant Changes

Treat a change as affecting the relationships around it, not just the edited entry. Review the consequences of a new product variant, label format, recipe revision, tool-program change, equipment replacement or software update.

For a scanner replacement, capture the transmitted input again. The SICK IDM programming manual, Chapter 7 documents output options including prefixes, suffixes and terminators for its covered models; compare the replacement scanner’s documented settings with the receiving application’s requirements.

If a shared tool program changes, identify every recipe that references it. If a matching rule changes, retest both its intended inputs and nearby codes that could now overlap.

Record the approved baseline and the changes deployed to each relevant device. Select retests according to the affected relationships, including recovery or exception tests where their behavior may have changed. Release the revised mapping after the responsible reviewers have resolved the findings.

FAQs About Barcode-Based Tightening Program Selection

Can Different Product Codes Use the Same Tightening Program?

Yes, when their approved fastening requirements justify using the same tool settings. Separate product recipes may reference that shared program while specifying different point layouts or sequences.

Check the complete operation requirements before sharing a program. Matching torque targets alone do not establish that the other settings and acceptance limits are appropriate.

Does Every Product Need a Unique Serial Barcode?

Not necessarily for program selection. A model or variant code may provide enough information to select the required recipe.

Individual-unit traceability requires a way to distinguish units. If your process requires that traceability, define how a unique identifier is captured and associated with the task and its results. A shared model code cannot provide that distinction by itself.

Can a QR Code Be Used Instead of a Linear Barcode?

Yes, provided the scanner supports the code and the receiving application can interpret its transmitted content. Check the documentation for your actual scanner model. For a model-specific example, the SICK IDM programming manual lists QR-code settings on page 82 and output settings in Chapter 7. Test representative labels through the intended connection.

A scanner reading the QR code successfully does not establish that its contents match the program-selection rules. Confirm the format against the proposed KURAN configuration before specifying it.

Is an MES Required for Barcode-Based Program Selection?

Not necessarily. First establish whether the chosen controller or workstation software can maintain the required mapping and select the intended programs through supported interfaces.

An MES may be relevant when work orders, product configurations or release decisions are managed centrally. Define those responsibilities before deciding which system should own the mapping.

Reliable barcode-based tightening program selection starts with a clear relationship between product identity and the approved assembly process. Define the selection fields, maintain an unambiguous mapping, and verify the selected recipe and tool programs. Include exception handling and configuration changes in that verification.

To discuss a KURAN configuration, prepare sample decoded barcode strings, the intended product-to-program relationships, scanner and tool-controller details, and the required changeover behavior. Include interface documentation and any unresolved confirmation requirements. Send your requirements to KURAN to discuss available program-selection configurations and the connection or software requirements for your workstation.