Modified PCB text file (outside of KiCAD's realm) — how to reliably check that resulting board is functionally identical?

[cal-linux]

So, I wrote this little program in C++ that reads through a KiCAD PCB file to create “stubless vias”. Quoting from a previous message I posted here:

I’m trying to achieve stubless vias (vias that do not produce a stub in inner layers due to KiCAD’s inability to have pads of different diameters for different layers). Using notation ( d , h ) to denote a via with pad’s diameter d and hole’s diameter h , I am writing a program that scans the .kicad_pcb file and replaces every via ( d , h ) with a via ( h + 0.002mm, h ) + pads (of diameter d ) on outer layers + pads on any layer where a track connects to the via.

For the pads, I noticed that KiCAD accepts tracks of length 0, so it seems like the most effective way to put a round pad: just create a track of width d (the diameter of the original via) and length 0 (i.e., the track goes from the position of the via, to the position of the via).

One obvious issue with this: how can I tell that my program did not introduce any defects when modifying the board file?

One obvious “candidate answer” to the above is: run the DRC on the resulting board. But I think that does not provide a strong guarantee. For example, one defect I can think of is that the program could fail to detect a trace that connects to a via in an inner layer, and then leaving the h + 0.002mm pad where the trace connects. This is definitely a defect (which maybe the manufacturer might detect and flag), but certainly the DRC in 5.1.10 does not flag it as an error (I just tested, manually crafting such situation).

The other even-more-obvious candidate answer is: just visually inspect it and ensure that the resulting board is correct. I don’t think I have to go too much into how this is a very very weak answer to the above question.

I guess my question for the forum (or more of an invitation to share any thoughts/insights that may come to mind) has two parts:

• Can you think of defects that such a program could be likely to introduce, and how could I watch for / avoid those defects? (say, if I’m inspecting the resulting PCB or the Gerbers visually)
• Are there any automated tools that I could use? (e.g., to analyze Gerbers, perhaps compare Gerbers?)

[John_Pateman]

As far as your second question goes, you can import two Gerber layers in ‘Gerbv’ (part of the gEDA suite) and XOR them. This is a very fast method of comparison.

You can also compare two *.kicad_pcb revisions in Git/Fossil/SVN using the KiCad-Diff tool. If you commit your layout to a suitable scm (Git/Fossil and SVN supported), run your tool and then commit the revised version, you can compare results before and after the run.

Gasman2014/KiCad-Diff

[cal-linux]

Thanks @John_Pateman,

Incidentally, I was inspecting visually with gEDA’s Gerber viewer, but just flipping the layers’ order, to alternate which one is at the top (I did know about the XOR view, but for some reason, it had not come to mind).

Still, one difficulty (in the case where I was interested in running my program, yet worried, because it is an actual, real-life project, and not some silly hobby board) is that there were many differences, and then it was hard to carefully look into each of them to see if there were any weird details revealing some bug in my program.

Thanks again!

[gkeeth]

This is not relevant for the topic at hand (diffing pcb files), but just wanted to note that in 5.99 you can achieve stubless vias without external tools, so you have that to look forward to!

[eelik]

Footprint pads, but not vias.

[gkeeth]

You can do both (Tools -> Remove Unused Pads):

Footprint pads can also be pre-defined in the footprint editor to have pads removed on unused layers, whereas vias can only have unused pads removed as a post-processing step.

[cal-linux]

I actually knew about that! (well, I had heard that that was one of the planned features; did not have any detailed information with respect to it)

And yea, as I was thinking about this whole thing, you know, whether I want to keep testing and working on this external program, I was wondering whether by the time that I would be confident enough that my program is bug-free as to use it in practice, that maybe by then KiCAD 6 will already be released!!!