My two cents on a workflow that I currently use with KiCAD 6: KiKit/multiboard.md at master · yaqwsx/KiKit · GitHub
Hi @yaqwsx !
This is simple, but has some drawbacks that can be a show-stopper for various projects.
Here are the problems I identified:
- You have only one stack-up because both circuits comes from the same KiCad PCB file.
- Both circuits gets the same worksheet information (title, revision, etc.). Can be work around playing with text variables, but not simple.
- You must avoid using global power components. No GND or +5V for global use. This makes schematics look quite naive.
- You need an external tool to separate the PCBs. Not a big deal, but goes against simplicity.
- You can’t check electrical rules for connections between the boards. This is something currently quite complex, no simple solution.
I’m looking for alternatives, here is what I currently have
What’s your opinion?
I can’t think of a case where a connector is not present between boards, even if it’s just soldered wires. Maybe just adding an attribute that allows associated connectors (multiple, to allow stackers) to delineate the separation between PCBs. Might also use a special component (Board flag like a power flag) to identify a board/PCB on a schematic branch in the hierarchy.
If you stick to the one PCB per schematic (and branch set) an inter-board connector could automatically generate a grouped set of hierarchical connections for that sheet. You would also want to be able to do separate schemtics/BoM per board from the master in an automated way. Manufacturing documentation has to be per board.
I suspect there is significant value in “subnetting” nets that allows nets to be differentiated by board, but grouped for ERC checking and the like as well.
The ability to specify and lock relative position of connectors to some reference datum on different boards would helpful.
Tangentially related to this is the need to have assembly variations using a common board with different BoMs. This is now a manual management issue with KiCAD.
Different PCBs need to have independent PCB files. One of the major motivations for different boards is different stack ups to save cost.
My major use case/motivation for wanting KiCAD to handle multi-board systems is automation and error checking.
Another factor is that some schematics will be wire harnesses and not boards at all. (no PCB file, but a BoM and set of nets.)
Rich
Personally, I don’t really see the advantage.
Personally, I would be far more excited about a panelization tool, and stronger features in the drawing tools for the edge layer (and in general). For example to easily draw multiple outlines, connect them with tabs, etc…
That would be helpful for the “one schematic, one stackup, multiple boards” use case.
The “one schematic, multiple stackups, multiple boards” use-case, I don’t really get it. What’s the advantage over just having multiple KiCad projects in the same folder? Assuming future KiCad versions improve the multiple document handling, so you can actually open multiple projects at the same time (which I believe is in the pipeline), doesn’t that solve it from the convenience point of view?
And what would be gained by actually making this “one schematic, multiple stackups, multiple boards” possible?
I think the cost in complexity would be significant - in the schematic I would have an additional level of assignment, where I have to define for every element which PCB it goes on.
The BOM and assembly export handling would be complex - do I really want a combined BOM for the different boards? Given they have different stackups, its quite unlikely they’ll be assembled together…
Semantics of operations like “copy and paste”, when taking elements from one project with one set of PCBs to another project with a different PCB assignment - how to handle things like this? Sounds like a nightmare.
And for what gain? The only thing I see is that you’d have a combined ERC over the whole schematic for the multiple PCBs, which you wouldn’t have in the multiple project approach… for me personally, this is definately not worth the implied complexity.
You have good questions, and these are what I try to find out. Personally I don’t have much involved in this, I have got along just fine as KiCad is now.
Let’s clear up some things.
It’s officially out of scope for the KiCad project, see Pcbnew: Create panelization tool (lp:#1782927) (#2180) · Issues · KiCad / KiCad Source Code / kicad · GitLab. But I don’t see it impossible to have continuing conversation about requirements which could make panelization easier, especially if those same features would help in other use cases, too.
It’s important to know the difference of this possible future enhancement and what KiCad can already do. if you open a new instance of KiCad (from for example Windows Start menu) you can already have multiple projects open at the same time, you can navigate between them, and even cut & paste works pretty well between projects. MDI UI wouldn’t help much with that IMO.
If I have understood correctly, the real benefit coming from cross-project binding or “one schematic, several PCB files” would be to formally define the connections between parts of a system. It would be much like KiCad can now check that the connections between sheets are correct, and the symbol pins/footprint pads correspond correctly and footprints on a board are connected to each other correctly. So, if there would be two different boards in one project or metaprojects, it would be possible to ERC/DRC check for their connections. Otherwise, if e.g. connector pin order is changed in one board but not another, it may go unnoticed. At least that’s my understanding now. Those who have explained their own needs can comment on this, am I correct or not.
Certainly not. What I proposed (just throwing it in as a quick idea) was that each sheet instance could have a board. If the property is not set, it’s inherited from the upper level sheet instance, and the main sheet of the project would automatically have the main board of the project, just like now. You definitely would not need to attach each “element” (whatever this word means to you) to some board one by one.
Oh what a shame 
because I really do think panelisation is something that many users need, and it isn’t (as far as I am aware, pointers welcome), well solved in terms of free gui tools.
KiKit is a an awesome plugin, but its harder to work this way than if it were built in.
I’m glad to hear that. I think for one type of panelisation use case - the one most closely related to this “multi PCB” question, drawing tools is all you need. This is when the PCBs in the panel are different parts of a system, being produced together in the same process - e.g. a MCU board and its breakaway programmer daughterboard, things like this.
But for the other, perhaps more common use case of just wanting to produce a bunch of copies of the same PCB in a panel it isn’t the best solution to have to layout each of them 
in this case KiKit is currently a good way to go.
I really don’t see the value of that within the context of the PCB design problem. Checking the connections within the PCB is obvious, because it is produced and assembled as a unit, and any errors in connection should originate either from the schematic (design error) or manufacturing process (fab made the error) - but never because you misconnected things in PCBNew. The software can verify it for you based on the net-lists and DRC rules.
But for unconnected boards, there is no guarantee that the connections made in assembly are actually those that were designed. Its not part of the process. It can go wrong in many ways, from using the wrong cable types to mounting the board rotated wrongly. There’s no way the “DRC” check for the interconnects drawn in the schematic actually guarantees any kind of correctness in reality.
To help at this level there is more specialised software - things that give you a 3D view of the whole system to be able to verify the PCBs and their interconnects fit in terms of space, are oriented correctly, etc. Software packages like Fusion360 help in terms of product design, and even more specialised software packages for telecom and power grid engineers help them connect up their systems within the wiring cabinets in the correct way. Hey - that could actually be a good use of augmented reality 
But to me this is well beyond the scope of what I expect KiCad to do for me…
Ok, well that kind of makes sense, but its still a -1 from me on this functionality… lots of complexity and little payback…
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.