Rotation Heuristics in SMT Assembly: Why We Still Guess, and How IPC-2581 Fixes It

A polarized capacitor placed at 180 degrees from its intended orientation connects its positive terminal to the negative rail. At best, it fails open. At worst, it explodes. In SMT assembly, rotation errors on polarized components are among the most consequential defects — and they're surprisingly common, because the Component Placement List (CPL) file that tells the machine where and how to orient each component is generated by humans, exported from CAD tools with different rotation conventions, and frequently wrong.

The assembly hub's rotation validation system catches these errors before the machine ever runs. It uses a three-tier heuristic cascade — because, in 2026, there is still no universally enforced standard that makes heuristics unnecessary.

The CPL File Problem

A CPL (also called a centroid or XY file) is a CSV that lists every component on a board: its X/Y coordinate, the board side (top or bottom), and its rotation angle θ (Theta). The θ value tells the machine which way to orient the component at placement.

The problem is that different CAD tools export θ using different reference conventions. KiCad, Altium, Eagle, and OrCAD all treat 0 degrees differently. A component exported from KiCad at θ=0 may need θ=90 in the machine's program. Import that file without checking and every polarized component on the board could be 90 or 180 degrees off.

There is no embedded metadata in a CPL file that indicates which reference convention was used. You can't read the file and know. You have to infer it — from the component type, from historical data, from domain knowledge.

That inference is what the three-tier heuristic system does.

Tier 1: Database Determinism

The first and most reliable tier is a direct database lookup. The component library stores num_leads for every component. Two-lead components (resistors, capacitors, inductors, simple diodes) are the most common rotation problem children — they have a polarity or orientation that matters, but their physical symmetry makes visual inspection difficult.

If num_leads == 2 in the library, the component requires rotation validation. The system checks whether the current CPL θ value is consistent with the expected orientation for that component's family. Library entries that have been manually verified for a specific customer's CAD tool export get stored as "deterministic baselines" — direct matches that skip tiers 2 and 3.

Tier 2: Package Profile Matching

When the library doesn't have a definitive record for a specific component, the second tier applies package-based pattern matching. Standard 2-pin packages (0402, 0603, 0805, SOD-123, DO-214AC) have known rotation semantics based on their physical geometry and industry convention.

TWO_PIN_PACKAGES = {
    "0402", "0603", "0805", "1206", "0201",  # chip resistors/caps
    "SOD-123", "SOD-323", "DO-214AC",         # diodes
    "SOT-23", "SOT-323"                        # small transistors
}
 
def tier2_package_check(package: str, theta: float) -> str:
    if package.upper() in TWO_PIN_PACKAGES:
        # Normalize theta to 0-360
        normalized = theta % 360
        if normalized in (90, 270):
            return "VERIFY"  # Unusual but not definitively wrong
        if normalized == 180:
            return "FLAG"    # Likely polarity reversal
        return "OK"
    return "UNKNOWN"

Tier 3: Lexical Part Number Scanning

For components that clear tiers 1 and 2 without a definitive result, the third tier deep-scans the raw part number for embedded dimensional or polarity codes. Many manufacturer part numbers encode lead count and polarity directly: "MLCC-2-0402-100N" contains "2" indicating two leads. "ELEC-CAP-2PIN-100UF-10V" contains "2PIN".

import re
 
def tier3_lexical_scan(part_number: str) -> str:
    two_pin_patterns = [
        r'\b2[-_]?PIN\b',
        r'\bBIPOLAR\b',
        r'\bPOLARIZED\b',
    ]
    for pattern in two_pin_patterns:
        if re.search(pattern, part_number, re.IGNORECASE):
            return "POLARIZED"
    return "UNKNOWN"

The three tiers together catch approximately 94% of rotation issues in the assembly hub's test suite. The 6% that make it through are genuinely ambiguous — non-standard components with incomplete library entries and non-descriptive part numbers — and those get flagged for manual engineer review.

Bottom-Side Mirroring

One additional complication: components on the bottom side of a PCB are placed upside-down. The machine looks at the board from the top, so a bottom-side component's θ is mirrored. A bottom-side component with θ=0 in the CPL needs to be placed at θ=180 in the machine program, and vice versa.

The rotation validation system applies a mirroring transform to all bottom-side components before validation:

def mirror_bottom_side_theta(theta: float, board_side: str) -> float:
    if board_side.upper() == "B":
        return (180 - theta) % 360
    return theta

This transform is applied before any tier check. Without it, every bottom-side polarized component would incorrectly trigger a false-positive rotation violation.

Why IPC-2581 Would Eliminate All of This

The entire three-tier heuristic system exists because CPL files don't carry enough information. The IPC-2581 standard (an XML-based electronics data exchange format) includes explicit polarity indicators, standardized rotation references, and component-level metadata that makes rotation heuristics unnecessary — the data says definitively whether a component is polarized and what the correct orientation is.

The problem is adoption. As of 2026, most PCB CAD tools support IPC-2581 export, but most contract manufacturing customers still send Gerber + CSV because that's what they've always sent. The standard exists. The tooling supports it. The industry practice hasn't caught up.

Until it does, three-tier heuristics are the engineering reality. The assembly hub's validation system is built with IPC-2581 adoption in mind — when a customer sends an IPC-2581 file, the system reads polarity data directly and skips tiers 2 and 3 entirely. The heuristic cascade is a fallback for the legacy data format, not a permanent architecture.

The right long-term answer is better data. Until then, deterministic heuristics plus pattern matching plus lexical scanning does the job.