吃瓜tv

Multiple boards belong to one product release, not one KiCad board file

If you are searching for KiCad multiple PCBs in one project, the useful distinction is between a KiCad project and the product that contains several boards. Use a separate project for each independently manufactured board, then collect their approved revisions in a product-level release manifest. Keep each project's project file, root schematic and board file together under a consistent base name. This makes it easier to identify which schematic drives which board and which fabrication package belongs to a purchase order.

Putting two disconnected outlines into one layout is a different operation. It may represent a deliberately designed manufacturing panel, but it does not give you independently managed schematics, revisions and assemblies. Likewise, a hierarchical schematic describes circuit organization; a sheet boundary is not automatically a physical board boundary. Decide what will be manufactured and assembled separately before choosing the folder structure.

This page owns project organization and release coordination. For the actual forward-annotation operation, use the schematic-to-PCB workflow. For a single approved board's manufacturing package, use the KiCad Gerber export guide. Keeping those tasks separate prevents a folder-management answer from becoming another incomplete CAD tutorial.

A practical structure for a controller and two sensor boards

Consider a product containing one controller and two identical sensors. Create controller/controller.kicad_pro and sensor/sensor.kicad_pro as separate projects. The matching schematic and PCB files sit beside each project file. Store a small product manifest above those folders. The manifest records the required board revision and the number of each board in one finished product. Ten products require ten controllers and twenty sensors before any explicitly agreed spares or assembly allowance.

The two sensors do not require two cloned projects merely because the product uses two physical copies. They share one board design and one controlled revision. Conversely, left and right sensor boards with different connector positions or different copper are separate physical designs, even if their circuit functions are similar. Give them separate identities rather than relying on an informal file suffix that purchasing or assembly might overlook.

Use relative paths for project-local libraries where practical. A colleague should not need your personal desktop directory to resolve a custom symbol or footprint. Include the necessary custom library files in the controlled project archive, document their origin, and respect any applicable licenses. A working board file alone is not a complete reproducible design environment.

Separate electrical identity from physical compatibility

A connector can be wired correctly in both schematics and still be incompatible after assembly. A top-view pin drawing, a mating-face drawing and a cable view describe different viewpoints. Record the reference viewpoint, pin numbering, connector part number, keying and cable mapping. State which board supplies power, the permitted range, expected current and any sequencing assumptions. These interface requirements deserve their own review rather than being hidden inside a project file name.

For example, controller revision A may be approved with sensor revision B but not sensor revision C because the latter changes a supply rail. The product manifest should therefore identify an approved revision combination, not simply the latest file found in each directory. Revision freshness and system compatibility are different properties. A local edit to one board must not silently update a product-level release that has already been approved.

Mechanical compatibility also crosses project boundaries. Compare connector locations, mounting datums, keepouts, enclosure clearance and mating tolerances in a shared mechanical reference. A pair of attractive 3D previews does not establish interference clearance or tolerance compliance. Where the installation includes a cable or flexible circuit, document the assembled path and its constraints separately from the flat board geometry.

Build a product-level board manifest

The worksheet below takes a small CSV list containing Board, Revision, Project and Quantity. Quantity means boards of that design in one product, not the number of products on the order. Enter the product build quantity separately. It calculates the resulting individual board quantities and produces a text manifest that you can attach to an enquiry. It rejects duplicate identities, reused project paths, non-integer quantities and parent-directory traversal.

The example is intentionally small: one controller and two sensors per product. It is not a suggested panel design or a production allowance. Start your own project to clear the example, and record the interface evidence that still needs review. Downloading the manifest does not generate KiCad projects, export Gerbers or transfer anything into the 吃瓜tv contact form. You can also enquire directly without completing the worksheet.

Open, edit and export each board through its own project

Open the relevant project in KiCad Manager before launching its schematic and PCB editors. Check the displayed project name before an update or export. Avoid leaving two similarly named projects open while making a release unless your team has a clear method of distinguishing them. The cost of a wrong-board export is usually much greater than the few seconds spent checking the active identity.

After a design change, save the source files and review the schematic-to-board update inside that project. Check electrical rules, board rules and the actual intended change. Do not copy a finished board file into a different project and assume its symbol associations and settings now belong to the new root schematic. Preserve a known source revision before attempting a reuse or conversion, and compare the resulting identities explicitly.

Export into a new, clearly named release directory for that board and revision. Keep fabrication outputs separate from assembly outputs because their consumers and acceptance questions differ. Review copper, mask, outline and drill outputs together in a CAM viewer. Then reconcile the component list and placement data for the chosen assembly variant. A single ZIP that mixes two boards' equally named layers creates avoidable ambiguity.

The PCB file-format guide explains which deliverables belong to fabrication, assembly and design exchange. Consult the official for version-specific project behavior. Keep your tested application version in the release notes so another engineer can reproduce the same operation.

Freeze releases while allowing the next iteration to continue

Working directories are allowed to change; released manufacturing packages should remain identifiable and reproducible. Record the source revision, application version, export settings and output checksum manifest alongside each released package. If an engineering change is needed after quoting, issue a new revision and state whether the old package is superseded. Do not replace selected files in an already approved ZIP without telling the receiving team.

Source control helps with history, but a commit identifier alone does not explain the manufacturing intent. Purchasing needs a part number, revision, quantity and scope. Assembly needs population rules, approved component identities and orientation information. Test engineering needs the compatible firmware and test specification. Connect those records through a release manifest rather than asking every department to interpret a repository independently.

For a repeated product build, decide whether the order is for individual boards, assembled board sets or a complete integrated unit. One product may contain three boards but only two unique PCB designs. This distinction affects quotation quantities, spare management, traceability and packaging. The contract manufacturing page covers broader program coordination; the PCB Assembly service covers the assembled-board requirement.

Multi-board organization is not panelization

Panelization arranges units for fabrication or assembly handling. A product manifest arranges design identities for a product build. Mixing those concepts can lead to a board quantity being confused with a panel quantity or to an assembly machine receiving the wrong coordinate reference. State whether the requested quantity refers to individual circuits, customer panels or assembled products.

A customer-supplied panel needs its own controlled outline, unit orientation, tooling, fiducials, separation method and placement data. Combining boards with different thicknesses, finishes or material systems in one proposed panel may be unsuitable even when they physically fit. Ask for a manufacturing review before treating a visual arrangement as a production-ready panel.

Use the panelization guidelines for assembly when the question is about rails, breakaway features and assembly handling. Retain separate unit-board releases so the panel can be reviewed without losing the identity of the circuits inside it. A panel change should not accidentally change the electrical design revision of an unchanged unit board.

Make a quotation package easy to interpret

Send one clearly labeled archive per board revision, or a parent archive containing unambiguous subfolders and a manifest. Include quantities, material and construction requirements, finish, thickness and any controlled-impedance notes. For assembly, add the matching BOM, positions, assembly drawing and population instructions. Identify unresolved requirements explicitly instead of relying on a filename to communicate them.

The required PCBA files guide is the next step when populated boards are required. If you need bare boards only, the PCB Manufacturing service is the appropriate commercial route. Describe whether different boards must arrive together or whether an early prototype of one board is useful before the complete system is ready.

Before sending the package, open it from its final location as a reviewer would. Confirm that no obsolete output folder was included, that all board identities agree with the manifest, and that custom library references are documented where source files are requested. This simple receiving-side exercise often reveals ambiguity that is invisible while working inside your own design folder.

Questions about multiple boards in KiCad