How do you verify PCB revisions? (I built a tool to diff 8 file types)

[kontr-owl]

Hi everyone,

Long-time lurker, first-time poster. I wanted to share a problem I kept running into and a tool I built to solve it, but more importantly, I want to hear how you all handle this.

The problem: When a single component gets swapped or a footprint is nudged, that change can silently ripple across the netlist, BOM, Gerber layers, drill files, and pick-and-place coordinates. Manually comparing PDFs and spreadsheets under time pressure is a recipe for missing something, and the failure mode is expensive: you find the error after the boards are fabricated and assembled.

What I built: Kontr-Owl is a local Windows tool that diffs eight categories of PCB files—netlist, BOM, ODB++/IPC-2581, Gerber, drill, pick-and-place, PDF, and mechanical—in one workflow. Files never leave your machine, and it generates audit-ready PDF/HTML/CSV reports.

Why I'm posting: I'm not here to just drop a link and leave. I want to understand how other engineers actually handle revision verification in practice. So I have a few questions for the community:

• Do you rely on visual inspection alone, or do you have a checklist?
• What checks do you never skip before signing off on a revision?
• What would make you trust a diff tool enough to use it for final sign-off?

Disclosure: I built Kontr-Owl. There's a 14-day free trial: full features, no license key required. But my main goal here is to learn from your workflows and see if I'm solving a real problem or a niche one. You can read more and access it here: https://kontr-owl.com/

I'm happy to answer any technical questions about how the diffing works under the hood. Thanks for reading.

[Zucca]

The idea is not new, there were already (abandoned?) solution for it, KiRi and KiDiff.

A quick research pointed me to

https://kihub.dev/
some demos here:
https://app.kihub.dev/demos

which looks an interesting approach to deal with revisions.

Anyway, is there any integration with git in kontr-owl?

[kontr-owl]

Thanks for the links. True, this idea has showed up before.

KiRI/KiDiff are KiCad+Git, KiHub is more of a GitHub review platform. Kontr-Owl's idea is an "eCAD-agnostic" local diff tool for exported files that generates a report and doesn’t upload anything, to intentionally keep the design files in your PC.

No Git integration right now. I didn't go for VCS yet because some teams I talked to use shared folders or PLM, not Git. But I’m open to it.

In your use case (or the ones you're aware of), what would actually be useful: just resolve two refs to files, or a proper Git plugin/CLI hook?

[tooki]

Long-time lurker, first-time poster. I wanted to share a problem I kept running into and a tool I built to solve it, but more importantly, I want to hear how you all handle this.

The problem: When a single component gets swapped or a footprint is nudged, that change can silently ripple across the netlist, BOM, Gerber layers, drill files, and pick-and-place coordinates. Manually comparing PDFs and spreadsheets under time pressure is a recipe for missing something, and the failure mode is expensive: you find the error after the boards are fabricated and assembled.

I guess to me the question is why anyone would use a workflow other than to empty the output folder and then re-generate all the files freshly before upload? (In Altium, the EDA program I use, you define “output jobs” that produce specific sets of output files, with particular settings, to particular locations. So then it’s basically a single click to generate all the files anew.)

What is a workflow where you would end up with out-of-sync output files? Since you “keep running into” this problem, perhaps you can elucidate it.

[kontr-owl]

Yup, with an Altium ".OutJob" everything gets overwritten automatically, no need to empty the folder first.

But here are two cases I've seen in the last year alone which can give an insight of how human-errors are prone to perpetrate into an automated workflow.

#1: production failure on a mature project. A team of several engineers works on one Altium project. Years into production, the project has accumulated a few layout changes and several assembly variant changes. Now you're at PCB rev 3 and assembly variant 5, because components went obsolete and had to be swapped. A new batch of boards fails production test. First question: what changed since the last batch?

In most companies I've seen, exports live in separate folders: one set for the PCB fab, another for assembly; usually two different companies, each getting only the files they need. When something like this happens, there's a serious effort to reconstruct everything that changed, because it has financial implications. And if the issue isn't on the design side, the next conversation is with the other companies involved.

#2: version drift at the fab. A high-end board (COGS around $10k/unit) goes out for fab and assembly. A month before design review and tapeout, exports were generated and shared with the fab and assembly house for quoting. While answering EQs from the board house, you ask for the working Gerbers and spot something odd on one layer — they were working from the earlier files.

I don't want to overstate "keep running into" — it's not every other month (thankfully). But over 15 years of HW design across different companies, countries, and industry segments, it's happened more often than I'd like.

[nctnico]

I've solved that with strict version numbering and dating production files sets. Every new revision / change bumps the version and / or revision number up. File sets carry the creation date in their filename. Also, the schematic AND PCB revision are on the silkscreen of the board so the board is always traceable to the source design files. Keeping every version is also important. Storing design files in version control can be extremely helpful. Some projects I've worked on went through 10+ revisions over their lifetime.

Bottom line: it is not about creating clean outputs but it is all about versioning & dating files properly so there is no ambiguity over which files are supposed to be used for production.

[kontr-owl]

Those are indeed valuable inputs on how to guarantee that all exchanged files with the fab and assembly houses are traceable and accessible.

In the real case #2 I wrote earlier, the financial issue would likely have been addressed (especially if the error wasn't on the electronic design side). The bigger headache that comparing Gerbers avoided was the months lost in the project schedule, plus all the escalations it would have involved.

Do you have a way of comparing design files between revisions?

[PlainName]

Do you have a way of comparing design files between revisions?

When I've needed to see which files have change, and how, I've used Beyond Compare. It's a generic comparison tool, not PCB design specific, but shows what's different. If necessary it's then possible to find how they got to be different using whatever backup or source control scheme maintains them.

But, typically, I would be a one-man band doing this even when in a team - it would only be necessary when something has gone tits-up (sorry! 'chest elevated') so not really a team job to resolve. Preventing things getting to that stage would be good, of course.

[nctnico]

Those are indeed valuable inputs on how to guarantee that all exchanged files with the fab and assembly houses are traceable and accessible.

In the real case #2 I wrote earlier, the financial issue would likely have been addressed (especially if the error wasn't on the electronic design side). The bigger headache that comparing Gerbers avoided was the months lost in the project schedule, plus all the escalations it would have involved.

Do you have a way of comparing design files between revisions?

Orcad has a design compare function built in. But for that you need to know where to look for and this is why I have all versions (including a changelog). If you need resort to comparing Gerbers, then your design version management process is fundamentally wrong. Fix the source of the problem, not the symptoms. I know this can be hard but it has to be done. In the past I have worked with a software engineer who flat out refused to use any form of version control or even keep old versions. At some point we had to force him to use version control as it was crippling the business.

[kontr-owl]

Do you have a way of comparing design files between revisions?

When I've needed to see which files have change, and how, I've used Beyond Compare. It's a generic comparison tool, not PCB design specific, but shows what's different. If necessary it's then possible to find how they got to be different using whatever backup or source control scheme maintains them.

But, typically, I would be a one-man band doing this even when in a team - it would only be necessary when something has gone tits-up (sorry! 'chest elevated') so not really a team job to resolve. Preventing things getting to that stage would be good, of course.

Nice! Beyond Compare is a solid tool, I've used at some point for general file comparison. The limitation I found is that it tells you a Gerber file changed, but not that a specific pad moved or a net got renamed, so I missed the visual part of the gerber/SCH diff. I built the tool to understand the formats automatically, so it can show a component swap in the BOM, a netlist change, or a drill hit shift in a way that's meaningful for PCB review.

You're right that this is usually reactive. Something goes wrong, then you dig. My idea with Kontr-Owl is to make it cheap enough in time and effort that it can be a quick sanity check before files go out, not just a "post-mortem tool". Not saying it replaces version control or good naming discipline, just adds a layer of confidence.

Have you ever wished Beyond Compare understood PCB formats, or is the generic diff enough for your needs?

[PlainName]

I can't recall ever needing to see the actual difference between gerbers, possibly because any faults have been higher-level design screwups

I think where I suspect a layout problem I would refer to the PCB design tool. Maybe in a rare case comparing gerbers might show something, but I can't recall wanting to do that so far. Of course, that may be because I haven't had to the tool to easily do so...

[nctnico]

I can't recall ever needing to see the actual difference between gerbers, possibly because any faults have been higher-level design screwups

I think where I suspect a layout problem I would refer to the PCB design tool. Maybe in a rare case comparing gerbers might show something, but I can't recall wanting to do that so far. Of course, that may be because I haven't had to the tool to easily do so...

If I would be confronted with such a situation nowadays, I'd fire up Claude and let it look for the differences and have Claude figure our how and when they got there. And if versioning like git is involved, it can also attribute changes to team members. And a big plus is that Claude runs on Linux as well.

[kontr-owl]

Those are indeed valuable inputs on how to guarantee that all exchanged files with the fab and assembly houses are traceable and accessible.

In the real case #2 I wrote earlier, the financial issue would likely have been addressed (especially if the error wasn't on the electronic design side). The bigger headache that comparing Gerbers avoided was the months lost in the project schedule, plus all the escalations it would have involved.

Do you have a way of comparing design files between revisions?

Orcad has a design compare function built in. But for that you need to know where to look for and this is why I have all versions (including a changelog). If you need resort to comparing Gerbers, then your design version management process is fundamentally wrong. Fix the source of the problem, not the symptoms. I know this can be hard but it has to be done. In the past I have worked with a software engineer who flat out refused to use any form of version control or even keep old versions. At some point we had to force him to use version control as it was crippling the business.

Cool! I used OrCAD for years (from good old version 9 up to the rebranded 16) and never got around to using its diff tool. Good to know it's there.

I fully agree on the strict process and traceability. My own workflow is pretty close to what you described.

That said, I haven't seen a one-size-fits-all solution. What you outlined is solid advice for many teams, but in other scenarios it doesn't quite fit. A disciplined process and the ability to compare fabrication outputs aren't mutually exclusive. A solid process doesn't remove the value of being able to diff files, and having a diff tool doesn't excuse a sloppy process. Some of my peers work in PCB design houses, handling files from multiple eCAD tools and juggling several revisions of the same project. That's a different reality.

Interesting anecdote about the software engineer, by the way. I'd have expected that kind of resistance more from the hardware side.

[kontr-owl]

I can't recall ever needing to see the actual difference between gerbers, possibly because any faults have been higher-level design screwups

I think where I suspect a layout problem I would refer to the PCB design tool. Maybe in a rare case comparing gerbers might show something, but I can't recall wanting to do that so far. Of course, that may be because I haven't had to the tool to easily do so...

If I would be confronted with such a situation nowadays, I'd fire up Claude and let it look for the differences and have Claude figure our how and when they got there. And if versioning like git is involved, it can also attribute changes to team members. And a big plus is that Claude runs on Linux as well.

I think this combination would work well. I'm using git mainly for SW and at some point will integrate it in my HW workflow too. I did try Claude for comparing/diffing HW design exports: it did the job (despite burning a lot of tokens + the usual gibberish).

[PlainName]

If I would be confronted with such a situation nowadays, I'd fire up Claude and let it look for the differences and have Claude figure our how and when they got there.

Maybe. Certainly, it should be quite doable, but there are mitigations: cost, non-local data, having to confirm it's found what it claims to have found, etc.

[nctnico]

I can't recall ever needing to see the actual difference between gerbers, possibly because any faults have been higher-level design screwups

I think where I suspect a layout problem I would refer to the PCB design tool. Maybe in a rare case comparing gerbers might show something, but I can't recall wanting to do that so far. Of course, that may be because I haven't had to the tool to easily do so...

If I would be confronted with such a situation nowadays, I'd fire up Claude and let it look for the differences and have Claude figure our how and when they got there. And if versioning like git is involved, it can also attribute changes to team members. And a big plus is that Claude runs on Linux as well.

I think this combination would work well. I'm using git mainly for SW and at some point will integrate it in my HW workflow too. I did try Claude for comparing/diffing HW design exports: it did the job (despite burning a lot of tokens + the usual gibberish).

In my case it worked really well. Based on a database and netlist extract (which Claude can run by itself entirely using Orcad's tools) it can detect changes in components, placement and connectivity. I'm 100% it can also highlight changes in the copper as I used copper extraction for power analysis purposes.