I want to make two variants of PCB for same schematics. These variants are 90% the same, but last 10% is different in footprints: SMD vs THT for some (10%) components.
I don’t want to have one PCB with both variants, I want two different (but very similar) PCBs
Is here any ways to achieve this?
I don’t want to have two separate projects, as it will be very difficult and error-prone to synchronize them, especially common PCB parts.
I would argue the best option here is to start with one variant, let it be produced, test it, correct what needs to be corrected and then copy the project and modify it for your 10% parts that differ. Then order both in the number you need.
You can do the copying at the first iteration but that will result in more boards to throw away if you are not first time right.
I would abstain from linking stuff between the projects as it does not really work with the current way KiCad implements projects.
If the project will be static after the builds I’d suggest keeping gerbers in two different directories.
1 Like
No doubt I’ll get criticized for this - I do things my way and often that means needing to do something similar to what others doing real work do.
Thus, IMO “Yes” it is “… possible to have several varients of PCB in one project” with considerations.
I’ve done this several times and, the short time I’ve been working with Kicad, it’s become so repeatable, like the ticking of clock…
Here’s how I do it:
- Create the schematic, add the parts and assign a default footprint (if not already done for the part).
- Do the usual: Annotate, Net it.
- Create a PCB, load the Net and Add the part/default footprint. Of course, do the other necessary work on the PCB…
- In your File Directory, Copy the PCB and save the copy to the Same Project.
- Click the Refresh Icon and the copied PCB will show in the Tree.
- Open the copied PCB and double click the Pads on the footprint you want to change for ‘this’ PCB
Bingo, you’re done. For clarity of Exporting Gerbers, Right-Click the Project in the Tree add Two directories (I call them ‘Out_THT and Out_SMD’)
Now, have One Schematic, Two PCB’s with different footprint pads. Export Gerbers to desired folder…
Example shows simple Barrel Jack with Default THT on one PCB and SMD on the other PCB.
I don’t know of a cleaner way to do it - this works for me. The ‘considerations’ I mentioned include what and when to Update the PCB…
3 Likes
This is viable way if first PCB is completely frozen before «forking».
I dream about built-in version control system, which works like git, but at level of business objects (elements, footprints, nets, etc) and not lines of text / bytes. Which will allow to branch PCB (or schematic), and later merge changes of «parent» back, where «child» has not been changed, for example. Yo have all this modern version control system features, but with deep understanding of meaning of data.
@Seth_h mentioned in a fosdem talk that such a version control support is a long term plan for kicad but I would assume this is at least two versions in the future. (> 4years)
If action plugin interface would be extended to project manager, problems like this (project archiving, variants switching, project renaming, output files (bom, gerber, pnp) generation, …) would be much easier to implement with community effort.
I highly doubt that the requested version control stuff can be added without massive rework of kicads data model. Normal versioning where only the BOM is affected is more likely. But it will get tricky as soon as you want to be able to exchange footprints but still propagate other changes between the versions.
Especially as this will likely mean that at least some traces would also need to be different between these versions and possibly also the position of other nearby footprints. -> this escalates quickly to a point where hacking it might do more harm than good. At some point we might really need to acknowledge that other tools might be better suited. ( KiCad is already quite good but some complex workflows are worth the investment into one of the expensive options. )
I would guess we would at least need full support of design blocks in pcbnew for this to be properly implemented. Even with this there would be still some restrictions to what can differ between versions. And it does not yet solve the git like version control request at all. That one would really need a KiCad internal version control (in the sense of history not different versions of the same pcb) implementation.
History effectively means diffs, and it could be extended to branches. Even CVS, born in 1990, supports branches!
Pure history works perfectly with external tools — git, for example — as all formats are text-based (huge thanks for that!), it is merging that constitutes a problem. Without smart merging internal version control is not much better than external one, IMHO. Visual diff is nice, of course, but not essential.
For me, for day to day work, visual diffs would be essential. They are of course a basic and easy feature while merging would be high end.
This triggered a memory of:
On that page there is a tool for doing visual diffs of schematics and some special git sauce for filtering out data that is not relevant for git, such as dates in the schematic, which would otherwise add clutter to git.
(I would prefer though if the KiCad files themselves were more git friendly).
There is also this project which does visual layout diffs.
https://github.com/Gasman2014/KiCad-Diff
And there has also been some recent work on this promising tool.
And there is an oCaml project somewhere plotkicadschematic which does schematic diffs.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.