A pick and place file should define source revision, units, origin, board side, designators, coordinates, rotation, and release authority. The IPC-2581C scope provides direct manufacturing-data context without proving that a specific export is complete or approved.
The pick and place file tells an assembly program where each component belongs, which board side receives it, and which orientation the package uses. People often call the file centroid, XY, CPL, or placement data, but the name does not make it complete. For an OEM, the practical question is whether engineers have defined the file clearly enough for another person to interpret it without guessing. A release should identify the source revision, units, coordinate origin, board side, designator, X and Y location, and rotation convention before programming begins.
This article defines the minimum release boundary. It does not judge whether a specific file is manufacturable, and it does not replace the BOM, assembly drawing, fabrication data, or an approved deviation. IPC-2581C describes a structured design-to-manufacturing data exchange that can include history, BOM, and ECAD objects. Many projects still use separate files, so the same relationships must be made explicit in the release package.
What Does a Pick and Place File Authorize?
The data supports one controlled decision: may the assembly team create or update the machine program for the stated product revision? A “yes” should mean that the input set is identifiable, internally consistent, and owned by an authorized design source. It should not mean that the first board has passed inspection, that every footprint is correct, or that a supplier has accepted responsibility for missing design information.
That distinction matters because a coordinate file can open normally while carrying the wrong revision, unit, origin, or rotation rule. A program can therefore be syntactically valid and physically wrong. Treat the file as one part of the PCBA manufacturing file set , then state which other files control part identity, polarity, population, and exceptions.
The release decision should have a named owner. The design owner supplies or authorizes the source export. Manufacturing engineering checks whether its tools and reviewers can interpret the file. Document control records the released identity. The buyer or program owner resolves commercial timing but should not approve a technical assumption outside their authority. When an ambiguity remains, the record should show the question, the affected designators, and the hold point.
Lock the Pick and Place File Revision
Start with provenance. Record the native design source or approved export process, the product or assembly number, the board revision, the assembly variant, the file name, the export date, and a checksum when the transfer method supports one. The checksum does not prove that the engineering content is correct. It proves that later reviewers received the same byte sequence as the release owner sent.
Do not rely on a folder name such as “final,” “new,” or “production.” Those labels change meaning when teams copy files. A useful release identifier connects the placement file to the same BOM and assembly drawing revision. If the design owner revised the assembly drawing after the coordinate export, the owner must decide whether the coordinates remain valid. That decision belongs in the release record rather than in an email thread that later reviewers cannot reconstruct.
Variant control deserves separate attention. One PCB may support several population options. A coordinate file can contain all locations while a variant BOM marks some parts as DNP, or the export may contain only placed parts. Either method can work, but the release must state the rule. The release should list DNP references as omitted, marked with a status field, or controlled exclusively by another file. The same rule must remain stable through program generation and first-board review.
If the source changes after release, use the established PCBA engineering change control path. Identify which designators moved, appeared, disappeared, or changed package; assess work already programmed or built; and set an effectivity point. Quietly replacing the file destroys the evidence needed to explain which input governed a given lot.
Define Units and Coordinate Origin
Every X and Y value needs an explicit unit. Millimetres and inches can both be valid, but an unstated unit forces the receiving engineer to infer scale from board dimensions. That inference may catch a gross error, yet it is not a controlled release method. Put the unit in the file header, field definition, accompanying readme, or release record, and make sure the program-import setting matches it.
The origin needs the same treatment. State whether the coordinates reference the lower-left board corner, a CAD datum, a tooling feature, an array origin, or another named point. If the data represents a panel, distinguish the panel origin from each unit origin. Identify whether the file contains step-and-repeat information, the panel document supplies it, or manufacturing engineering creates it under an approved rule.
Field
Minimum definition
Evidence to retain
Product identity
Assembly number, revision, and variant
Release record linked to BOM and drawing
File identity
File name, source export, date, and checksum where used
Controlled transmitted file and receipt record
Units
Millimetres or inches, stated without inference
Header, readme, or import-setting check
Origin
Named datum for board or panel coordinates
Drawing mark, CAD reference, or approved diagram
Board side
Top or bottom using one agreed vocabulary
Field definition and assembly-drawing cross-check
Rotation
Zero orientation, direction, range, and bottom-side rule
Convention note plus representative package checks
Designator
Unique reference matching the released BOM
Automated compare and reviewed exception list
Coordinates
X and Y placement point for each applicable reference
Import report or controlled comparison output
A small reference diagram can prevent a large argument. Mark the origin, positive X direction, positive Y direction, and board viewing side on an approved drawing or data note. For a panel, mark rails, breakaway features, and unit orientation only when those details are part of the controlled assembly package. A photograph of a panel or a machine setup is useful context, but it cannot define the CAD coordinate system.
Before release, compare the coordinate envelope with the approved board outline. Values should fall within the expected physical area after reviewers apply the stated unit and origin. This check detects some wrong-unit and wrong-origin errors. It does not confirm pad centres, component height, nozzle access, or package geometry, so record it as a limited check rather than a blanket approval.
State the board side and mirroring rule
The pick and place file should state the bottom-side transform, viewing convention, mirroring rule, and physical board interpretation.
Top and bottom placement data must use a declared viewing convention. A CAD tool may export a bottom-side location as viewed from the top through the board or directly from the bottom, while receiving software may apply its own transform. Those conventions can produce opposite X direction or rotation behaviour. A field that merely says “bottom” leaves the critical transform unstated.
Define whether the coordinates are already mirrored, whether the machine import performs mirroring, and which side the drawing shows. Use a small set of asymmetric references to prove the rule: a connector at one edge, a polarized device, or two components with visibly different positions. The objective is not to inspect every placement manually. It is to show that the transformation used by the program agrees with the released design intent.
Do not solve a bottom-side mismatch by editing coordinates in an uncontrolled spreadsheet. If the process requires a transformation, record the tool, rule, operator or automated process, source file, output file, and verification result. Keep the unmodified source available. That makes it possible to repeat the transformation or explain a later discrepancy.
Write a Rotation Convention Packages Can Use
Rotation is the field most likely to look precise while remaining ambiguous. A value of 90 degrees has no stable meaning until the release defines zero orientation and direction. State whether positive rotation runs clockwise or counter-clockwise, whether values use 0–359 degrees or signed angles, and which transform applies to bottom-side components. State which package feature establishes zero: pin 1, a polarity mark, a long axis, a CAD-library orientation, or another controlled reference.
Check local library offsets
Package libraries complicate the issue. Two libraries may model the same physical device with different zero orientations. A receiving engineer should not overwrite the design intent just to match a local library silently. Map the released package to the local package, record any rotation offset, and verify representative components before the program applies the offset across all matching references.
Choose representative checks by risk, not by convenience. Include at least one polarized device, one fine-pitch IC, one connector with an asymmetric key, one two-terminal polarized part if present, and any package that required a library offset. The exact sample depends on the design. The record should show the designator, released value, interpreted orientation, evidence used, reviewer, and disposition.
Zero-degree illustrations can help, but they must reference the same package name or library object that the data uses. A generic drawing of an SOIC does not settle the orientation of a particular footprint. Likewise, silkscreen can support a check but may be missing, clipped, or wrong. The approved assembly drawing and component documentation remain the better authority when the CAD convention is unclear.
Reconcile the File with the BOM and Drawing
Each applicable placement row needs a unique designator that reconciles with the released BOM. Compare missing, extra, and duplicate references. Then separate expected exceptions from unexplained ones. Expected exceptions may include mechanical hardware, fiducials, test points, tooling features, or DNP parts, depending on the export rule. The exception category and controlling file should be explicit.
Do not recreate part identity from coordinate data when the BOM controls that field. The placement file may carry a package or value field for review, but reviewers must resolve conflicts against the approved documents. A designator that matches while the manufacturer part number or package differs can still create the wrong program. Record the comparison rule and which file wins for each field.
The assembly drawing supplies information that coordinate rows usually cannot: polarity notes, DNP marks, hand-installed items, adhesive or special-process instructions, connector seating, hardware, and approved exceptions. The release gate should therefore confirm that the drawing and placement data describe the same assembly state. If the drawing is still changing, complete the BOM and assembly freeze checks before treating the coordinate file as stable.
Automated comparison is useful for large files, but its output needs an owner and a disposition. A report with thirty mismatches is not evidence of approval. Classify each mismatch as expected, corrected, or unresolved. For a correction, identify the new revision. For an expected mismatch, cite the rule. When an issue remains unresolved, state the hold and the person authorized to answer.
Set Holds Instead of Allowing Silent Assumptions
A controlled release uses explicit hold triggers. A hold is not a judgement that the design is bad. It prevents an ambiguous input from becoming a machine setting that is difficult to trace. The trigger should be objective enough that different engineers reach the same decision.
Use objective restart conditions
Condition
Why programming should stop
Required restart evidence
Revision cannot be tied to the BOM and drawing
The program may represent a different assembly state
Authorized release record naming the matching set
Missing or contradictory unit field
No controlled coordinate scale
Corrected file or signed unit definition
Missing origin or axis direction
Engineers cannot interpret locations consistently
Approved datum and axis reference
Bottom-side mirroring rule is unclear
Software may transform locations or rotations twice or not at all
Written viewing and transformation convention
Rotation zero or direction is unknown
Package orientation is ambiguous
Package convention and representative checks
Missing, duplicate, or unexplained designators
Reviewers cannot reconcile part identity
Comparison report with dispositions
DNP treatment conflicts across files
Population state is uncertain
Approved variant rule and corrected release set
Someone replaced the file after approval
Prior verification no longer applies
New revision, impact review, and reapproval
Record the hold at the level needed to contain work. A single unclear designator may not require every unrelated engineering task to stop, but it should block approval of that placement. A wrong revision or undefined coordinate system usually affects the full program. Define the containment scope instead of using either an unlimited stop or an informal workaround.
Restart only after the issue owner attaches evidence. “Confirmed by phone” is not enough unless someone captures, attributes, dates, and links the confirmation to the released change. The record should show who answered, who checked the updated data, and which program or work order may proceed.
Keep a release record that another engineer can reconstruct
Release the pick and place file with the controlling file, cross-file checks, open exceptions, approving role, effectivity, and receiver acknowledgement.
The release record should be compact enough to use and complete enough to reconstruct the decision. Include product and revision, variant, source file identity, checksum when used, units, origin, axis directions, side and mirroring convention, rotation convention, comparison results, open exceptions, approvals, effectivity, and receipt acknowledgement. Link the record to the actual controlled files rather than copying selected values into an unrelated worksheet.
Separate release approval from first-board acceptance. Release approval authorizes program preparation from a defined input set. First-board evidence checks the resulting interpretation on hardware. The second event may uncover library, polarity, feeder, nozzle, or process issues that were not visible in the coordinate file. Keep both records and do not use either one to erase the other.
For a new transfer, ask the receiving team to acknowledge the file identity and declared conventions. For an existing program, compare the new source against the prior released source and record the impact. The quality assurance overview can provide broader inspection context, but project-specific criteria still need an approved source and owner.
Pick and Place File FAQ
Is a centroid file the same as pick-and-place data?
Often, but the label is not a specification. Confirm the fields, units, origin, side convention, and rotation rule in the actual export. Some centroid files include only coordinates and designators; others add package, value, or variant information. Base the receiving rule on content and provenance.
Should the BOM or the coordinate file control part identity?
Use the project’s approved document hierarchy. In many release structures the BOM controls manufacturer part identity while placement data controls location and orientation, but that is not universal. Write the hierarchy into the release record and resolve any conflict before programming.
Can manufacturing engineering correct the placement data?
An engineer can propose a transformation or correction, but the record must name the authority, method, output identity, and verification. A silent edit should not replace the design source. When the change alters design intent, obtain approval from the authorized design owner.
Does complete pick-and-place data guarantee a correct first board?
No. Complete data reduces interpretation risk. It does not validate the footprint library, polarity source, component package, feeder setup, soldering process, test coverage, or every assembly instruction. Use a separate first-board review with defined acceptance evidence.
If you want a file-set review, send the product revision, BOM, assembly drawing, placement export, and the conventions already known through the GNS contact form . Ask the reviewer to return unresolved assumptions and hold points as written questions before programming.
References used for the decision framework
IPC-2581C provides the structured manufacturing-data context used here, including product history, BOM, and ECAD information. IPC’s published resources for IPC-2516 describe assembled-board product manufacturing data. NIST SP 800-128 supplies a general baseline and controlled-change concept for the firmware and file-governance portions. These sources do not certify a supplier or approve a project file.
