From Onshape drawing to production BOM in Carbon

A drawing change does not become a production change just because someone saved a new CAD version. There may be material on the shelf, orders in purchasing and operators working from the previous instruction. Carbon’s connection to Onshape is interesting precisely at that handoff: it links design information to the manufacturing records that people use to buy, plan and build. The useful question is not whether a model can be imported. It is whether the shop can tell which revision a particular job is supposed to follow.

Onshape holds engineering models and assembly structure. Carbon describes itself as a manufacturing system bringing planning, execution and quality records together. Its Onshape integration pulls part identities, revisions and structure into the production environment. That connection can remove a manual export step, but it cannot remove the need to decide how an engineering change should affect existing work.

A drawing’s parts list is not a shop’s bill of materials

An engineering bill of materials describes the designed assembly. The manufacturing bill of materials describes what must be purchased or made to deliver it. The two should correspond, but they need not have identical rows. A shop may add packaging or consumables not modeled in CAD, buy an assembly as one item, or combine several modeled bodies into a single fabricated item. Forcing the manufacturing list to match the CAD tree exactly can make planning worse, not better.

Part identity is the first practical hurdle. Names and descriptions change. Two variants may share a casual name, while the ERP needs distinct item numbers because their lead times or costs differ. A reliable connection maps a stable Onshape identity to a known Carbon item. That mapping has to survive a rename and remain inspectable when somebody discovers the wrong item was assigned. Otherwise a new design release may quietly create another stock item for a part the shop already carries.

Quantity deserves its own check. An assembly may call for individual fasteners while the buyer orders packs; a length defined in CAD may not be the unit used by stores. Routings, supplier choice and inspection requirements also belong to manufacturing decisions, not simply to the shape of the CAD assembly. The integration should bring an engineering change into view without erasing the shop’s intentional differences.

The revision problem begins with an open order

Imagine a workshop making sheet metal enclosures. Engineering changes a hinge hole pattern and releases a new Onshape revision. Some doors have already been cut to the old pattern, old hinges remain in stock, and an assembly job is scheduled for tomorrow. A perfectly transferred CAD revision could still cause a costly mistake if the open work order silently begins displaying the new hole pattern.

A planner and engineer need to decide which orders should use the new revision. A job that has not started might move to it. A job in progress might finish under the earlier drawing, or require rework after review. The old hinges might be consumed on existing orders but not ordered again. None of those choices follows automatically from the fact that a new model exists.

Carbon’s own description of its Onshape workflow discusses mapping parts and checking revision changes against active orders, with engineering change approval as a possible gate. Treat this as a workflow to verify in the actual installation, not a promise that every open order is protected under every configuration. In a pilot, record exactly what happens to a released revision before and after approval and what an operator can see during that interval.

A 3D view needs a trustworthy label

Carbon also describes a model viewer alongside production items and shop instructions. Having the model near the work order is helpful, particularly when an operator would otherwise hunt through file shares. But easy access is only an improvement if the image corresponds to the revision assigned to that job. A prominently displayed model from the wrong revision is more dangerous than a drawing that is visibly missing.

The same applies to inspection. A dimensional check marked “pass” says little unless it identifies the part and revision used for the test. If a hole diameter changed, an inspection against the earlier tolerance does not prove that the new design was built correctly. The connection becomes more useful when item code, design revision, manufacturing BOM and quality record can be followed as one traceable chain.

There is also an architectural distinction worth keeping. Carbon’s internal data model brings its own manufacturing functions together. Onshape is still a separate system. Someone has to define when a release is eligible for import, what counts as an approved change, and how a bad mapping gets repaired. Shared production records do not make the boundary with an external CAD system disappear.

A pilot with three meaningful tests

Start with a small assembly whose parts already have known Carbon item codes. Map each part to its Onshape identity and compare the initial CAD structure with the manufacturing BOM. Write down the rows that differ on purpose, such as packaging or bulk fasteners. Then rename a CAD part without changing its identity. If the correspondence breaks, the pilot has found a problem before it can spread to hundreds of items.

Next, release a controlled revision. Check the item revision, the displayed model and the BOM in Carbon. Do not stop at the integration’s success message: inspect an existing work order and a new one separately. Does either change without review? What does purchasing see if an order for the previous part remains open? Note the record identifiers and the release time so the result can be reproduced. The expected behavior should be agreed before testing, not inferred from whatever the software happens to do.

Finally, try a deliberate mapping mistake in a safe test environment. If an Onshape part is linked to the wrong Carbon item, can the team detect the error, identify affected jobs and restore the correct mapping? A connection that transfers every update immediately but has no visible correction path can turn a small identification error into an operational one. A review step between receipt of a change and its application to production may be worthwhile even when the technical sync works well.

The earlier article on Carbon’s API and MCP boundary separated reading a record from changing one. The Onshape handoff poses a similar question in a different form. Seeing that engineering released a new revision is not the same as authorizing it for every job on the floor. A sound integration makes that distinction visible to the people who have to act on it.

Sources: Carbon’s Onshape to BOM guide, Carbon’s project repository, and Luke van Enkhuizen’s overview of open source manufacturing tools. The workshop scenario is illustrative; check actual integration behavior in a test deployment.