Control de revisiones de placas de circuito impreso: evita que los cambios del prototipo se incorporen a una tirada de producción equivocada

The difficult part of a second prototype is often knowing exactly what changed after the first one. A trace repair, a component substitution and a firmware workaround may all exist in different places. A simple release process helps turn those discoveries into an unambiguous next build.

Give each build a clear identity

Choose a readable board revision and use it consistently in the design records and release-package name. Keep the hardware revision separate from the firmware version and assembly variant. One bare board can support several population options, so a board label alone may not describe everything fitted to it.

Separate observations from approved changes

Keep a change list with the observed issue, proposed correction and the evidence used to accept it. “Connector problem” is hard to act on. “Connector orientation conflicts with the enclosure opening” gives the next reviewer something specific to check. Record unresolved questions as unresolved rather than hiding them in an apparently final archive.

Release the file set together

Once changes are approved, generate the fabrication and assembly outputs from the intended revision. Keep a copy of the exact package sent for quotation or production. Avoid repeatedly replacing the contents of an archive called “final.zip” while keeping its name unchanged.

• Board revision and assembly variant.
• Fabrication and assembly file names.
• A short list of changes from the previous build.
• Any retained exceptions or unpopulated components.
• The associated firmware and test-document versions.

Use a concrete change note

For example, a release note might say: “Revision B moves connector J2 to match the enclosure; the assembly variant remains unchanged; use the new board and placement exports together.” That is more useful than “latest files attached.” It tells the recipient which earlier information has been superseded and which decisions still apply.

Treat an order change as a separate request

A new design release does not automatically replace the files for an order already being processed. Contact DIYIPCB with the order number, old revision and proposed replacement. Ask for confirmation before assuming the new package can be used. Keep that response with the release record.

Close the loop after the next build

Link test observations to the revision and assembly variant actually tested. If a board is modified by hand, note the modification before comparing it with an untouched sample. This makes the next design review more productive and helps avoid reintroducing a problem that was previously fixed only on the bench.

This is an original DIYIPCB workflow guide. Release identifiers and example change notes are illustrative; confirm any change to an active order with the support team.