PCB & manufacturing
PCB Assembly Drawings: The Document a Person Reads
The machine data says where every part goes. The drawing answers the dozen questions it cannot: the eight it has to cover, what belongs on it and what does not.
The machine data tells the line where every part goes. So why does anyone still draw an assembly drawing?
Because the placement file answers exactly one question — coordinates and rotation for parts a machine places — and a build involves a dozen questions it cannot answer. Which side is the component side. Where pin 1 is when the marking is ambiguous. How tall a standoff is. Which parts go in by hand, after reflow, after cleaning. What the operator should do with the heatsink that is not in the BOM because it ships with the enclosure.
The assembly drawing is the document a person reads. That is its whole job, and it is why it survives in an otherwise automated flow.
The questions it has to answer
A drawing is good when a competent assembler who has never seen your product can build one without emailing you. In practice that means answering these:
- What does the finished assembly look like? Top and bottom, oriented the
same way as the board will sit on the line.
- Where is reference designator R47? Every placed part identified, legibly.
- Which way round are the polarised parts? Explicitly, not by inference
from the silkscreen.
- Which parts are not fitted? Marked on the drawing itself, not only in the
BOM.
- What is done by hand? Connectors, transformers, anything through-hole,
anything added after reflow.
- What is the build sequence, where it matters? Wash before the relay goes
in. Programme before the conformal coat.
- What are the process requirements? Solder alloy, profile constraints,
coating areas and keep-out areas, cleanliness.
- What gets inspected, and against what? Height limits, torque values,
gaps.
If a question on this list has no answer anywhere in your package, the assembler will make an assumption. Assumptions are usually reasonable and occasionally expensive.
A workable sheet layout
Most assembly drawings fit on one or two sheets. A layout that works:
| Area | Contents |
|---|---|
| Main views | Top and bottom of the assembly, to scale, reference designators shown |
| Detail views | Enlarged areas where parts are dense or orientation is ambiguous |
| Section view | Only if height, stacking or a mechanical fit needs it |
| Notes block | Numbered process notes, referenced from the views by flag |
| Title block | Assembly part number, revision, sheet number, date, approver |
| Revision block | What changed from the previous revision of the drawing |
The title block matters more than it looks. A drawing with no revision in it is a drawing that cannot be matched to anything, and it will outlive your memory of which board it described.
Notes that earn their place
Notes are where most of the real content lives. Useful ones are specific, testable and few:
"Items marked DNP are not to be fitted. Do not substitute." "J4 is fitted after wash. Do not expose to aqueous cleaning." "Apply conformal coating to the top side only. Mask connectors J1–J4 and the programming header." "Maximum component height on the bottom side: 2.0 mm." "Torque M3 fasteners to 0.5 Nm." "Programme U7 before assembly into the enclosure. See firmware part number in the BOM."
Unhelpful ones are the ones everybody copies forward from the last project: "assemble per IPC-A-610" with no class stated, "use good workmanship practice", "see BOM for details". They occupy the space where a real instruction should be.
If a note applies to a specific location, flag it on the view. A note nobody can connect to a place on the board is a note that gets read once and forgotten.
Polarity is worth its own attention
Most assembly errors that make it past inspection are orientation errors, and the drawing is where you prevent them.
For each polarised family, show the convention once and apply it everywhere:
Electrolytics and tantalums — mark the positive pin on the drawing, and say whether the silkscreen band means positive or negative on your boards. Diodes and LEDs — show the cathode. Silkscreen bars are not universally interpreted. ICs — show pin 1 with an unambiguous marker, not only the silkscreen dot, which may be covered by the part. Connectors — show pin 1 and the mating direction, because a connector can be mounted the right way round and still face the wrong way.
Where a part's own marking contradicts the silkscreen, say so on the drawing in words. That contradiction is exactly the thing an operator will resolve wrongly.
What does not belong on it
A drawing becomes unusable when it tries to be the whole package.
Keep off it: the full bill of materials, bare-board dimensions and drill details, schematic information, test procedures. Each of these has its own document, and duplicating them means two places to update and one of them will be wrong. Reference them instead, by number.
The exception is a small parts table for hand-fitted items. A short list of the five things a human adds, beside the view showing where, is worth more than a cross-reference to a 200-line BOM.
The mistake that costs the most
The drawing is a derived document. When the layout changes, the views change — and because regenerating a drawing is manual work in most flows, this is the single most commonly skipped step in a change.
A drawing that shows Rev B placements with a Rev C title block is worse than no drawing at all, because it is believed.
Two habits prevent it. Put the drawing on the change checklist, explicitly, as its own line. And state on the face of the drawing which PCB revision and which assembly revision it applies to, so a mismatch is visible rather than silent.
Keeping a drawing matched to the layout it was generated from is a filing problem, and filing problems are solved by having somewhere the match is recorded rather than remembered.
XKEMA attaches documents to the board and the revision they belong to, so the drawing for a given revision is found rather than reconstructed.
Hardware documentation What to send to your PCB manufacturer * Pick-and-place files: why components end up rotated