Pick-and-place data validation should prove that the export matches the intended assembly, coordinate convention, BOM, drawing, program preview, and first-board evidence.
Pick-and-place data can look complete because every row contains a designator, an X value, a Y value, and an angle. That appearance is not enough. Engineers still need to prove that the export belongs to the intended assembly, uses the declared coordinate convention, agrees with the released BOM and drawing, and produces a sensible machine-program preview. Verification turns a file from an unexamined input into evidence that supports a controlled programming decision.
This guide explains how engineers should verify pick-and-place data before release. It focuses on checks that can expose a wrong revision, origin, unit, side transform, rotation rule, or population set. It does not certify a machine program, approve a component library, or promise a first-pass build. Those decisions require the actual product files, equipment settings, approved component information, and first-board results.
Set the Pick-and-Place Data Validation Objective
Start by naming the decision. The verification should answer whether the stated placement-data export is consistent enough for manufacturing engineering to create or update a program for one identified product revision and variant. A reviewer should not use the same check to approve fabrication data, component substitutions, test coverage, or process capability. A narrow objective keeps the evidence understandable and prevents a green mark from being interpreted as approval of the entire build.
Write the product number, assembly revision, variant, data-file name, source application or export method, and review date at the top of the record. Name the design owner who released the data and the manufacturing engineer who reviewed it. If either person cannot identify the controlling release, stop the review. A technically plausible file with uncertain provenance creates more risk than a clearly incomplete file because it can enter a program without attracting attention.
Define the release boundary as well. Some teams accept the data after cross-file checks and then verify the interpretation in an offline program preview. Others require a first-board placement inspection before the program becomes a production baseline. Either workflow can be controlled when the record states the hold point, required evidence, decision owner, and effectivity. Without those fields, “verified” can mean something different to design, purchasing, and manufacturing.
Confirm Source Revision for Pick-and-Place Data Validation
Verify the source before you verify coordinates. Ask the design owner to identify the native CAD revision or the approved export package that produced the file. Record the assembly number, PCB revision, assembly revision, variant, export time, file size, and checksum when the transfer process supports one. A checksum only confirms file identity; it does not confirm engineering correctness. Still, it prevents later reviewers from comparing a different file under the same name.
Compare the placement file with the released PCBA manufacturing file set . The BOM, assembly drawing, fabrication data, and placement export should describe the same product state. Check their revision fields, dates, variant names, and documented exceptions. If the drawing changed after the placement export, request a disposition from the design owner instead of assuming that the coordinates remain valid.
Avoid folder labels such as “final,” “latest,” or “use this.” They do not create traceability. Preserve the received file, record where it came from, and keep the review output separate from the source. If an engineer converts delimiters, column names, or angle formats for a local tool, retain the untouched input and record the transformation. Another engineer should be able to repeat the conversion and obtain the same result.
Prove Units, Origin, and Coordinate Envelope
Read the declared unit and origin rather than inferring them from the numbers. Confirm whether X and Y use millimetres or inches. Then identify the datum: a board corner, CAD origin, tooling feature, panel origin, or another named point. Mark positive X and positive Y directions on an approved drawing or review sketch. When the file represents a panel, distinguish unit coordinates from panel coordinates and document any step-and-repeat rule.
Run an envelope check against the approved board or panel outline. Find the minimum and maximum X and Y values and compare them with the expected physical dimensions after applying the stated unit. Outlying values can expose a wrong unit, origin, decimal shift, or stray reference. The envelope check cannot prove pad centres or package geometry, so record it as a limited result. It narrows the risk without replacing detailed interpretation.
Select several known components near different board edges and compare their coordinate direction with the drawing. Include an asymmetric connector, a polarized device, and a reference close to the origin when the design contains them. This sample helps reveal an axis swap or unexpected mirror that a simple boundary check can miss. Record the designator, expected location, observed location, source used, and result.
Verification step
Evidence to inspect
Acceptable result
Hold trigger
File identity
Product, revision, variant, file name, checksum
All fields map to one approved release
Unidentified or conflicting source
Unit check
Header, readme, CAD export setting
One explicit unit matches the import setting
Unit inferred only from dimensions
Origin check
Drawing datum and coordinate directions
Named datum and axes agree
Unnamed or inconsistent origin
Envelope check
Min/max X and Y versus board outline
Applicable rows fall in the expected area
Outlier, scale error, or axis swap
Side transform
Top/bottom sample and mirror convention
Import shows the intended board view
Ambiguous bottom-side transform
Rotation sample
Zero rule, direction, library offset
Representative packages match design intent
Unresolved angle convention
Population match
BOM, drawing, placement designators
Differences have approved explanations
Unexplained missing, extra, or duplicate row
Verify board side and mirroring with asymmetric references
Pick-and-place data validation should use asymmetric references and known package orientations to expose an incorrect side transform or rotation rule.
Top and bottom rows require more than a side label. Determine whether the export shows both sides from a top view, shows each side directly, or expects the receiving system to mirror bottom data. Then confirm which transform the import tool applies. A file and a machine can each apply a reasonable convention and still produce the wrong combined result.
Use asymmetric reference points to prove the transform. A connector near the left edge, an IC with a clear pin-one corner, or two unlike components at different locations gives a stronger check than a centred resistor. Compare the source drawing, raw coordinate row, and imported preview. If X direction or rotation changes, document why the change occurs and which controlled rule authorizes it.
Do not correct a mirror mismatch by silently editing spreadsheet coordinates. First decide whether the source export, the import setting, or an approved transformation owns the correction. Then record the source, tool, setting, output identity, reviewer, and result. An undocumented manual edit can solve one preview while making the next export impossible to reproduce.
Test Rotation Against Real Package Intent
Rotation values only become meaningful after the release defines zero orientation, positive direction, angle range, and bottom-side treatment. Read that definition and compare it with the import configuration. If the design team uses counter-clockwise positive angles while the programming tool uses clockwise values, the conversion must be explicit. The same rule must produce the expected result across package types.
Choose samples by consequence. Include a fine-pitch IC, a polarized capacitor or diode, an asymmetric connector, and any package that uses a local library offset. Compare pin one, polarity, keying, or the controlled zero feature with the assembly drawing and component documentation. Silkscreen can support the check, but it should not overrule an approved drawing or datasheet when marks conflict.
Record library offsets instead of hiding them. A local footprint may define zero differently from the ECAD library even when both represent the same physical package. The program can compensate for that difference when engineering documents the mapping and verifies a representative part. If the same package name maps to multiple offsets, stop and resolve the library identity before applying a broad rule.
Reconcile Pick-and-Place Data Validation with the BOM and Drawing
Build three sets of designators: those in the placement file, those in the released BOM, and those shown or governed by the assembly drawing. Compare missing, extra, and duplicate references. Separate expected categories, such as fiducials, tooling features, test points, mechanical items, and DNP components, from unexplained differences. The review record should state which file controls each exception.
Variant logic often creates legitimate differences. The placement file may list every possible location while the variant BOM marks unpopulated references, or the export may contain only fitted parts. Verify which method the release uses and test it against several variant-specific references. When a DNP status conflicts with a coordinate row, follow the approved BOM and assembly freeze check rather than choosing the more convenient file.
Part identity also matters. Confirm that each designator maps to the expected manufacturer part, package, and placement status through the BOM or approved mapping. Placement data does not need to duplicate every procurement field, but it must not create an unexplained package or reference mismatch. Route commercial substitutions and alternate-part decisions through their own approval path.
Review an Offline Program Preview Before Release
Import the verified file into the intended programming environment or a controlled offline review tool. Record the software version, import profile, unit, origin, mirror setting, and rotation mapping. Capture the warnings and row count. A clean import only proves that the tool accepted the syntax; the engineering review must still judge the transformed data.
Overlay the imported placements on the board outline or approved reference when the tool supports it. Inspect the edge samples, bottom-side transform, polarized parts, connectors, fine-pitch devices, and any documented library offset. Look for references outside the outline, unexpected clustering at the origin, swapped axes, or a consistent angle shift. Keep screenshots or an export report that another engineer can associate with the exact input file.
Do not let the preview become an uncontrolled new source. If the engineer changes placement values, rotations, or packages inside the programming tool, record those differences and obtain the required authority. Use PCBA engineering change control when the source design must change. A manufacturing adjustment can remain local only when the approved process defines its scope and verification.
Mismatch
Immediate disposition
Decision owner
Evidence required to restart
Revision or variant conflict
Hold program release
Design or document owner
Identified controlling release and supersession record
Unit or origin ambiguity
Stop import interpretation
Design owner with manufacturing engineering
Approved datum and unit statement
Bottom-side mirror conflict
Block affected side
Manufacturing engineering
Controlled transform plus representative comparison
Rotation mismatch
Quarantine affected packages
Design and library owners
Zero convention, offset mapping, and sample verification
Missing or extra designator
Classify the difference
BOM or assembly owner
Approved population rule or corrected export
Import warning
Assess affected rows
Program owner
Documented cause, correction, and clean recheck
First-board discrepancy
Stop expansion beyond the hold point
Named release authority
Containment, corrected baseline, and reinspection
Use first-board evidence to close interpretation risk
Close pick-and-place data validation with first-board observations, corrected exceptions, approving role, active file identity, and effectivity.
The offline preview reduces risk, but a first-board check tests the interpretation against a physical result. Define the inspection scope before placement begins. The scope should cover orientation-sensitive devices, connectors, fine-pitch packages, bottom-side transforms, and locations affected by an offset or previous mismatch. Add design-specific samples where a wrong placement would damage the board or hide under another part.
Record the board or lot identity, program version, placement-data checksum, library release, machine or line identifier where relevant, reviewer, inspection method, and result. A photograph can support the record, but it cannot replace an identified board, designator list, and disposition. AOI, X-ray, visual inspection, or another method may contribute evidence according to the design; no single image proves every placement.
If the first board reveals a discrepancy, contain the affected work and trace the cause to source data, transformation, library mapping, program edit, feeder setup, or another process input. Do not simply correct the visible part and continue. Update the controlled baseline, repeat the applicable verification steps, and record who authorized release. The quality assurance overview can frame broader controls, while the project record must retain the specific evidence.
Keep Pick-and-Place Data Validation Reproducible
A useful record lets another engineer reconstruct the review without relying on memory. Retain the exact input identity, related BOM and drawing revisions, tools and settings, comparison outputs, screenshots, exception list, approvals, and release decision. Connect each exception to an owner and a closed disposition. If a question remains open, show the hold point and affected scope.
Use objective status words. “Checked” should name what was compared. “Accepted” should identify the authority and condition. “Pending” should identify the missing evidence. Avoid comments such as “looks fine” or “same as last time.” They do not show whether the reviewer checked units, origin, side, rotation, designators, or variant logic.
Set effectivity for the verified baseline. State which program, build, work order, or future release uses it. When a new placement export arrives, treat it as a new input and run the applicable checks again. A previous PASS cannot approve changed coordinates or a changed BOM. It can only provide a comparison point and a known review method.
Before final release, run a short independent readback. Ask a second reviewer to identify the product, revision, unit, origin, side rule, rotation rule, and unresolved exceptions from the saved record alone. If that person needs an unwritten explanation, the record is not complete. Also compare the saved checksum and program identifier with the values shown at the work station. This readback catches transcription errors that a technically sound review can still leave behind. Record the second reviewer, date, fields checked, and any correction. Then lock the evidence with the same retention and access controls used for the project release. This extra check does not transfer design responsibility; it confirms that the decision can survive a handoff.
Frequently asked questions
Can engineers verify pick-and-place data without native CAD?
They can perform many cross-file and import checks on an approved export, but they should record the limitation. Native CAD or design-owner evidence may still be needed to resolve origin, rotation, package, or variant ambiguity.
Does a successful machine import prove the data is correct?
No. It proves that the software accepted the format. Engineers still need to verify revision, units, origin, side transform, rotation, population, and representative placements.
How many components should a rotation check sample?
Use a risk-based sample rather than a fixed universal count. Cover each relevant package convention, polarized or keyed parts, bottom-side transforms, and every documented library offset.
Who should approve a corrected placement file?
The approved responsibility matrix should decide. Manufacturing engineering may control a documented tool conversion, while changes to design intent normally require the design or document owner.
References used for this verification method
The data relationships in this guide align with the exchange purpose described by IPC-2581 . The document-control logic also follows configuration-management principles in NIST SP 800-128 . These sources support the method; they do not prove any GNSEMS certification, equipment capability, or project result.
If you want a file-specific review, send the product revision, variant, BOM, assembly drawing, placement export, and known exceptions through the GNS contact form . The response should identify missing evidence and the next decision gate rather than assume the file is ready.
