PCB Assembly Data Package: CPL Coordinates, Polarity and Panel Fiducials

Open the PCB168 PCB assembly page and read the quotation-input row of the specification table. It says: BOM + fabrication + placement data.

Three items. Most RFQs arrive with two.

The page's engineering-review paragraph is more specific about what gets checked. It states the review confirms whether designators, footprints, polarity marks, part numbers, and placement coordinates agree across the submitted files. Notice that this is a list of things checked *against each other*. Four of those five live somewhere you already send — the BOM carries part numbers and designators, the fabrication data carries footprints and silkscreen. But the last two, coordinates and polarity, depend on conventions that no file states about itself.

A centroid file is a column of numbers. It does not say where its origin sits, which direction counts as zero rotation, or whether Y increases upward. A silkscreen polarity mark is a shape in a copper-layer stack; it does not say whether it outranks the assembly drawing when the two disagree. And the panel — the thing that actually goes through the machine — may not exist yet at all when you send your files.

Those are the three gaps this article covers. Each one has a default. Each default is somebody's assumption, and if you did not write it down, it is not yours.

Why these three and not the other missing things

Plenty of things can be missing from a PCBA RFQ. Approved-alternates policy is missing constantly, test coverage is usually vague, and material ownership is often never stated. Those are real gaps and they have their own treatment — see BOM risk and alternate-part approval, test and inspection requirement definition and quote scope boundaries.

What makes coordinates, polarity and panel definition a distinct group is who resolves them and when. A BOM question produces an email: "is this alternate acceptable?" You answer it, the answer is recorded, the project moves. A coordinate-convention question often produces no email at all, because the file *parsed successfully*. Numbers came in, numbers were accepted, a program was generated. The mismatch surfaces later, physically, on a board.

The PCB assembly page says open questions "remain RFQ items until both sides agree on the manufacturing package." That mechanism only protects you for questions somebody knew to ask. These three are the ones that most easily fail to become questions.

Gap 1: the centroid file does not describe itself

Your CAD tool exported a placement file. It probably has columns for designator, X, Y, rotation, layer, and maybe package. Every one of those columns is ambiguous without a stated convention.

Origin. Where is (0,0)? Common answers: the board outline's lower-left corner, a specific corner of the bounding box, a designer-placed origin marker somewhere inside the board, or a panel corner. All four are normal. They are not interchangeable. If the receiving side assumes board-outline lower-left and your file is referenced to an internal datum you set while routing, every coordinate is offset by the same vector — which is the most survivable version of this failure, because a single consistent offset is visible immediately during program setup. The dangerous version is when the origin *nearly* matches.

Rotation zero and direction. Rotation needs two agreements: what orientation counts as 0°, and whether positive rotation is counter-clockwise or clockwise. Library conventions differ, and the package itself matters — a two-pin chip resistor tolerates a 180° error invisibly, a polarised tantalum does not, and a SOT-23 with three pins has three plausible "zero" positions depending on whose footprint convention the library followed. This is precisely why IPC-7351 exists as a land-pattern and zero-orientation convention, and precisely why naming the convention you used is more useful than hoping it matches.

Units and layer notation. Millimetres or inches, and whether the value is recorded to a precision that survives rounding. Layer notation splits into top/bottom, T/B, 1/2, and TopLayer/BottomLayer depending on the exporter. A bottom-side part on a double-sided assembly whose layer column was misread is not a subtle defect, but it is a defect that costs a build.

Mirroring on the bottom side. For bottom-side placements, whether X is mirrored and how rotation is measured — viewed from the top through the board, or viewed from the bottom — is a genuine fork. Both conventions are in use. Neither is wrong. Only one matches your file.

What to declare, concretely: the CAD tool and version that exported the file, the origin definition, the rotation zero convention and sign, units, layer naming, and the bottom-side mirroring convention. Six lines. If you would rather not enumerate conventions, the alternative is to send a neutral intermediate format that carries them — ODB++ or IPC-2581 both encode placement with the design, which removes most of this list from your RFQ by construction. Say which one you are sending.

Gap 2: polarity has a source of truth, and you have to name it

Polarity and orientation are stated in up to three places, and those places can disagree.

Silkscreen carries cathode bars, plus marks, pin-1 dots, connector keying outlines. It is the most convenient reference because it is on the board itself. It is also the one most likely to have been drawn early, then not updated when the footprint changed — and the one most likely to be partially unreadable, because silkscreen gets covered by the component body, trimmed for clearance, or omitted under a dense BGA field.

The assembly drawing carries the orientation the designer intended, usually with an explicit view direction, pin-1 callouts and sometimes a per-package rotation table. This is where intent can be stated unambiguously. It is also the document most often absent from a first RFQ submission — which is why the PCB168 assembly page lists assembly-drawing review as a separate line item in its key features, alongside placement-data review, rather than folding it into "files received."

BOM notes and the part number itself carry orientation implicitly. A part number defines the package and therefore the pin-1 convention. BOM comment fields sometimes carry instructions like "mount reversed from silkscreen" that exist because a late-stage error was patched in text rather than in CAD.

When these three conflict, someone decides. You want that someone to be you, in writing, before the program is built.

What to declare, concretely: which document governs orientation when sources disagree (the assembly drawing is the usual and most defensible answer); an explicit note for any part whose silkscreen is known to be wrong, missing or ambiguous; a pin-1 reference for every polarised or keyed package that is not obvious from silkscreen — diodes, electrolytics, tantalums, LEDs, connectors, and any IC without a clear pin-1 feature; and whether first-article photographs are required for orientation confirmation before the balance of the build runs.

That last point is worth separating. Orientation errors are systematic, not random: if the convention was misread, every instance of that part on every board is wrong in the same direction. That is what makes orientation the single highest-value thing to confirm on a first article rather than at final inspection. The release-and-report side of that is covered separately in first-article inspection report and release terms; what belongs in *your* RFQ is simply whether you want that gate and on which parts.

Gap 3: the panel is a deliverable, and it is usually nobody's

Your design is a board. Assembly runs on a panel. Between those two facts sits a set of decisions that frequently belongs to no one.

A single small board cannot be transported and clamped reliably through paste printing, placement and reflow. So boards get arrayed into a panel, and the panel gets edge rails — tooling strips, breakaway edges, 工艺边 — that give the conveyor and the clamping system something to hold that is not your circuit. Those rails carry the global fiducials that let machine vision establish where the panel actually is, as opposed to where the program thinks it is.

None of that is in your Gerber set if you sent a single board image. The decisions are:

Who defines the panel. You supply a panelized data set, or the supplier panelizes and you approve the layout. Both are normal. Only one is happening on your project, and the difference determines whether panel geometry is your engineering task or a review item on your desk.

Array and step. How many up, in which orientation, at what spacing. Mixed-orientation arrays exist for material yield, and they interact directly with Gap 1 — if the panel rotates alternate boards, then panel-referenced coordinates are no longer a simple translation of board coordinates.

Rail width and separation method. Rails consume area, and area is what you pay for. Separation by V-score, routed tabs or perforated tabs changes edge stress on components near the board boundary, which is why component keep-outs near the break line belong in the same conversation.

Fiducials. Global fiducials on the rails locate the panel. Local fiducials adjacent to fine-pitch and BGA parts let the machine correct for local distortion. Both need to exist as copper features, exposed by soldermask, with clear surroundings. If your design has none and the panel is built from your data, there is nothing to add them to.

Board-to-panel coordinate reference. State whether your placement data is referenced to the single board or to the panel. This is the one item that spans all three gaps, and stating it wrong is what turns two individually-correct data sets into one incorrect program.

Panel size constraints. The manufacturing capabilities page publishes a maximum board size of 600mm × 1100mm and a board thickness range of 0.2mm to 6.0mm. Those are fabrication-side figures, and they bound what a panel can be, but they are not assembly-side handling limits — conveyor width, clamping range and thickness handling are confirmed separately through engineering review. Do not read the fabrication maximum as an assembly guarantee; ask.

What to declare, concretely: who panelizes, whether you approve the layout before release, array/step/orientation if you are supplying it, rail width and separation method, fiducial provision and responsibility, component keep-out from break lines, and the coordinate reference (board or panel).

What happens when you declare nothing

This is the part worth being precise about, because the failure mode is not "they refuse to quote." They quote. The PCB168 assembly page is explicit that scope is confirmed from your files during engineering review and that unresolved items stay as RFQ items — so a competent reviewer will surface what they notice. The risk is the subset that is not noticeable from the files alone.

A parsed file looks like a complete file. Coordinate and rotation conventions do not fail loudly. A centroid export with a different origin still parses, still populates every field, still produces a runnable program. There is no error state to catch; there is only a board that comes out wrong.

Assumptions get made at the level where they are cheapest to make. Someone has to pick an origin to build the program. If nobody was told, the most common local convention gets used. That convention is correct far more often than not — which is exactly why it does not get questioned, and why the cases where it is wrong arrive unannounced.

Quotes become non-comparable. If you asked three suppliers and only one assumed they were responsible for panelization and fiducial addition, that one carries engineering work and rail area the others did not price. You will read the difference as a price difference. It is a scope difference. This is the same mechanism described in quote comparison scope boundaries, applied to data rather than to services.

Detection moves downstream, where it costs more. The capabilities page lists AOI on every layer, 100% electrical testing by flying probe or fixture, and X-ray for BGA and via fill verification — but those are fabrication-side controls on the bare board. On the assembly side the page's own text says the inspection plan is agreed per project and test requirements are customer-defined. A polarity error on a two-terminal part can pass visual inspection, pass continuity, and only present as a functional failure. Which means your own test definition is what catches it. If you left both the orientation source and the test requirements unstated, you have removed both the prevention and the detection.

Schedule absorbs the difference. Every clarification cycle is a round trip. The assembly page states that open questions remain RFQ items until agreed, which is the correct behaviour and also means the clock runs while the questions are open. Declaring these three items up front removes the most predictable round trips before they happen.

The declaration block, in the form you can paste

Keep it short and put it in the RFQ body or a one-page README inside the data package. Group it by the three gaps.

Coordinate data

• CAD tool and version used for the export
• Origin definition (board outline corner / internal datum / panel corner)
• Rotation: what counts as 0°, and positive direction
• Units, and decimal precision
• Layer naming used in the file
• Bottom-side convention: mirroring and rotation reference
• Reference frame: single board or panel
• Or: neutral format supplied instead (ODB++ / IPC-2581), named explicitly

Orientation and polarity

• Governing document when sources disagree (normally the assembly drawing)
• Parts with known-wrong, missing or obscured silkscreen, listed by designator
• Pin-1 or polarity reference for every polarised and keyed package
• First-article orientation confirmation: required or not, and on which parts

Panel and fiducials

• Who panelizes; whether you approve the layout before release
• Array, step and orientation, if supplied by you
• Rail width and separation method
• Fiducial provision: global on rails, local at fine-pitch parts, and whose responsibility
• Component keep-out from break lines
• Any panel size or thickness constraint you already know applies

None of these require you to know the supplier's equipment or internal defaults. Every line is a statement about your design and your intent, which is the only thing you can declare with authority anyway. The values that depend on the supplier — handling limits, which fiducial geometry their vision system prefers, whether your proposed array is efficient on their material — come back from engineering review. That division is the point: you supply intent, they supply feasibility, and the quote request closes on the reviewed package rather than on assumptions.

Sequencing: what must be settled before release, what can wait

Not everything needs an answer at RFQ time.

Before a quote can be meaningful: who panelizes, and the coordinate reference frame. These two change the scope of work and the price. Everything else can be refined.

Before program build: the full coordinate convention set, the governing orientation document, and the designator-level polarity exceptions. These are the items that cannot be recovered by inspection after the fact.

Before the first article runs: fiducial placement confirmed, rail width and separation method agreed, keep-outs checked against the break lines.

At first article: orientation confirmation on the parts you flagged. This is where a systematic convention error gets caught while it still costs one board instead of a batch.

Not in this conversation at all: which alternates are acceptable, what test coverage applies, who owns the material, and what the acceptance records look like. Those belong to BOM and alternate approval, test requirement definition, material ownership and supplier scope respectively. Mixing them into the data-package discussion is how a data question becomes a commercial negotiation and stalls.

For the process context around all of this — where file review sits relative to printing, placement, soldering and inspection — the PCB assembly process guide covers the sequence itself.

FAQ

Is a centroid file the same thing as a pick-and-place file?

In practice the terms are used interchangeably, along with CPL, XY data and placement data. They all name the same thing: a per-designator list of position, rotation and side. The naming does not matter. What matters is that whichever name your CAD tool used, the file does not carry its own conventions, so you still have to state origin, rotation zero and mirroring.

Can the supplier just derive placement data from my Gerbers?

Positions can often be inferred from pad geometry, and some workflows do exactly that. But inference is not the same as your intent: it recovers where pads are, not which rotation convention your library used or which orientation you meant for a polarised part. Deriving data also transfers a judgement call to someone without your schematic. The PCB168 assembly page lists placement data as a distinct quotation input alongside BOM and fabrication data for this reason. Send it.

Do I need to supply the panel, or will the supplier panelize?

Either is normal, and the page's position is that scope is confirmed from your files during engineering review rather than pre-assumed. So the answer for your project is whichever one you state. What is not acceptable is leaving it unstated, because that is the version where you may pay for panelization work you also did yourself, or find nobody did it.

My design has no fiducials. Is that a problem?

It is a question rather than a defect, and the answer depends on who owns the panel. If the supplier panelizes, global fiducials can be added on the rails they create. If you supply a panelized data set with no fiducials anywhere, there is no surface to add them to without a data revision. Local fiducials near fine-pitch and BGA parts are a separate decision from global ones, and they live in your board data — so if you want them, they need to be in the design, not in the panel.

Which one of these three gaps causes the most rework?

They fail differently. Coordinate convention errors are systematic and usually visible at setup or on the first board, so they cost a build. Polarity errors are systematic but can survive visual and continuity checks, so they can cost a batch and surface as functional failure. Panel questions rarely cause defects but routinely cause schedule loss and non-comparable quotes. If you only have time to declare one thing, declare the orientation source of truth.