Recap of strategies for multiple PCB projects

[Heath_Raftery]

We’re busy creating some standards for Kicad work in our team, and I’ve come to how we manage multiple PCBs. There are many threads discussing various strategies for various purposes, so I’m hoping to collate the summaries in one thread here.

AFAIK, there are three major reasons you’d want to have multiple PCBs per project:

1. There are physical variations on the same schematic (eg. prototype and production, or form factor variants).
2. Your schematic needs to be split into multiple PCBs.
3. You have a project with independent schematics that have independent PCBs (eg. display board and CPU board), that should be combined somehow, perhaps to be panelised.

And from my survey of the many threads on these topics, these are the conclusions I came up with:

1. Work within the one project and just generate new PCBs with different names. Kicad will automatically create Project files named for the PCB. You can either use that (only a few settings are kept within the project, including the project name, the rest is kept in the SCH file); or just stick with the master project and remember to update the name when importing the netlist etc. Kicad is clearly not designed to work this way, but it all works fairly well anyway.
2. If you can, just do one big PCB with mouse bites between the sections. Otherwise it’s very hard to designate parts of the schematic for one PCB and parts for another.
3. Create separate Projects and handle any commonalities manually. At panelisation time, either use gerbmerge or use “Append Board” within pcbnew.

Do reasons (1), (2) and (3) cover the motivations? Do strategies (1), (2) and (3) represent the best Kicad has to offer today?

References:

• Can you break a schematic into more than one board?
• Multiple PCBs from single schematic
• Multiple PCBs in one (master) project
• Two PCB for one Schematic?
• Hierarchical or not - bringing multiple PCBs into a single project
• Create multiple PCB in one project
• Making multiple PCB designs with breakoff

[Rene_Poschl]

@Heath_Raftery

There are physical variations on the same schematic (eg. prototype and production, or form factor variants).

I would still give them a different project to be honest. No need to complicate things.
(After all you are likely changing even some small things on the schematic side when going from last prototype to first production model.)

My typical setup on the file system looks like this:

• The project directory [project_name]
  • First version that was produced [project_name]_v0
    • All project files [project_name].pro, [project_name]-cache.lib, [project_name].sch, … (note that the file names do not include the version info here. This allows easy copy to a new folder for the next version.)
  • Second version [project_name]_v1
    • [project_name].pro, [project_name]-cache.lib, [project_name].sch, …
  • …

This way you have an archive for every pcb you ever produced. If you make a second run with minor modifications of one of them then copy that original project directory, give it a new name, do your changes and order.

(And yes i am aware that this will lead to a lot of duplicated data. But i really want an easy way to start from any version if i have to. And i want an easy way to debug any version. Well and a project i already produced has a very low likelihood to spontaneously change. So i want these files there forever unchanged.)

---

@Heath_Raftery

Your schematic needs to be split into multiple PCBs.

At the moment i notice that the project needs to be split i will duplicate the full project for every split necessary and make the same file structure for every project as i described above already.

@Heath_Raftery

You have a project with independent schematics that have independent PCBs (eg. display board and CPU board), that should be combined somehow, perhaps to be panelised.

I would have 3 projects in that case. The two projects for creating the pcbs. And the third only takes care of panelizing.
This allows to independendly order the pcbs in any compination in the future.
Or lets say you find an error in pcb1 but pcb2 is ok. I want the option to only change pcb1. (If both are in the same kicad project then i would need to give both of them a new version number even if only one of them changed.)

[eelik]

I have used options 2 and 3.

Option 2: One schematic with completely different sections and the board divided by routed slots. This is good enough for small, simple boards where one is the main board and the other is an optional add-on, size max couple of cm.

Options 3: Two boards with the same schematic, orientation of one connector is reversed physically. By chance this is the same project as in option 2. I have two projects, each one having identical schematic and two physical boards in one board file. Keeping up with schematic changes is tedious, I really would like a way to have several boards for one schematic. But the same instant when you need even a small change in schematic between the boards this need becomes much more complicated. For example if there would be a different connector. Although it’s possible to make the schematic more generic by using more generic symbols, for example, or leaving some optional things unused even though they are in the boards.

One more option is to use a version control system and create branches for small variations. However, it doesn’t actually help much with EDA designs (whatever the used program is) because merging changes to another branch isn’t practically possible. But at least for now I prefer git over explicit copies for consecutive versioning. Older versions are reachable all the time but there’s no need for several folders.

[Piotr]

@Rene_Poschl

note that the file names do not include the version info here.

I didn’t checked it yet.
Do KiCad has anything against if I copy and rename project files (from v0 to v1)? Is the name written also in the file and if not agree then don’t work.

I think gerber files are named from pcb file name. PCB manufacturer don’t likes to get from the same customer the next order with the same name of gerber files - it makes them a mess in their archives. If after few years you order the same PCB you will be not sure which one you will get.
If I had to rename all gerber files I would prefer to rename project files.

[Rene_Poschl]

Nearly all files of a project must have the same name. This name is by default the same as the directory they are placed in. I however rename the directory in such a way that it contains the version number.
But i keep the files in that directory unchanged as i would otherwise need to do additional work for renaming the project. (The cache lib is one example that makes it difficult to rename the files belonging to the project.)

[Piotr]

@Rene_Poschl

This name is by default the same as the directory they are placed in.

I have done my one project half year ago, but I see that in directory MS01 I have MS01_A files. I don’t remember I have done anything special to brak KiCad default.
My (not KiCad) practic is to name the directory according to device name. Then all files with that name but with version letter added. When I will need to do MS01_B I will make subdirectory named A, copy there all _A files and rename working files to _B and work with them.
Having old versions in subdirectories makes me less directories I see in the product family directory. Now I have in main products family 36 directories and in prototype 24 directories. If I had separate directory at that level for each version I would have about 3 times more - it is more then screen height - I don’t like if directory is too long for screen.

@Rene_Poschl

The cache lib is one example that makes it difficult to rename the files

I can rename cache.lib also if really needed.
I have one project from 4.0.7 (using only my libs).
Before moving to 5.0.2 I (under 4.0.7) prepared my libs to be V5 compatible so that project could be opened with 5.0.2 without any problems.
Now I am doing a mess in my libs so opening that project resulted with generating -rescue.lib. I am not able to make tests with clear situation I don’t have now.
I think cache.lib is no problem in “lib stable” situation - can be even deleted.
Should I expect any problem if I rename all files in project?
I just didn’t expected any problem with it so didn’t checked it.
I plan to start second project, but all the time something disturbes me in my way to reach “mylib stable” situation which is my necessity.

[ppelleti]

@Piotr

Should I expect any problem if I rename all files in project?

I rename projects a lot, and I’ve never had any problems. I use this Perl script:

#!/usr/bin/perl -w

if ($#ARGV != 1) {
    die "Usage: rename-kicad.pl old-basename new-basename\n";
}

my ($old, $new) = @ARGV;

my @extensions = qw(-cache.lib .kicad_pcb .net .pro .sch);

sub mysystem {
    my @cmd = @_;
    print join(" ", @cmd), "\n";
    system (@cmd);
}

foreach my $ext (@extensions) {
    mysystem ("mv", "-i", "$old$ext", "$new$ext");
}

[9V1MI]

This comes under the realm of “Configuration Management” and how to use the tools and systems you have to accomplish same. The following figure is from ANSI/ASME Y14.44:
scan0013.pdf (514.8 KB)
This is an example of a “set” at the top level. The schematic diagram at this level does not have to show the detail of every assembly and subassembly, but it could. What it shows is the interconnect. I did a full up schematic of a project that had a Front Panel, a Rear Panel, and a printed board assembly (PBA).

Note in the figure that only basic reference designations are shown because each assembly/subassembly has a ref des prefix. The delineation of the assembly/subassembly is done with what is called mechanical-boundary lines. In mechanical drawing this is called a phantom line. A center line consists of a long-short-long (repeated) line and a phantom line consists of a long-short-short-long (repeated) line. The problem is that modern day electronic computer-aided design (ECAD) software, including KiCad, is not set up to handle this. Thus for each assembly/subassembly, that makes up a UNIT, the basic ref des will have a ref des prefix to segregate the parts. Every project/product should have a System Subdivision diagram as shown in ASME Y14.44 as follows:
scan0015.pdf (601.2 KB)
in order to assign the ref des prefixes. This type of diagram is often referred to as a product structure diagram or product tree. Actually it is an upside down tree or root system, like what your PC OS works on.

The following is my System Subdivision diagram for the project that I mentioned earlier:
Me_10027.odg (15.8 KB)
I assigned ref des prefixes as follows:
A1–Front Panel
A2–Rear Panel
A3–Printed Board ASSY (PBA)
On the top level schematic all parts on the Front Panel had a complete ref des such as A1R1, on the Rear Panel the complete ref des would be A2R1, and for the PBA the complete ref des would be A3R1. The schematic for the PBA was done by copying the top level schematic over to another .sch file, deleting all parts with A1 and A2 ref des prefixes, and then deleting all the A3 prefixes, leaving basic reference designations for the PBA.

For a discussion of reference designations see the series of articles at https://techexplorations.com/reference-designations-for-electrical-and-electronics-parts-and-equipment/ that I authored.

If you want multiple boards from the same schematic then you will have to stick with the ref des prefix on each component/part. For separate boards you can do as I have explained that I did for my project. For multiple boards with basic reference designators on each board it looks like what you could do is panelize the separate boards.
–Larry