I think a mechanism to join them will be helpful
The association between sheet and PCB looks ok.
I agree. Each physical GND should have a different name and global connections crossing PCBs should be reported as errors.
But allowing to make explicit connections between boards could enable system level ERC checks.
One current problem is with the PWR_FLAG. If you have GND1 in board 1 and GND2 in board 2, and you connect them using hierarchical ports the ERC fails.
I hope that this topic is not consuming too much bandwidth.
A couple of things:
Not so important: The mailing list has decided that it does not like me; I had a managed pseudorandom password, etc., but had to use the Google SSO because I’ve been lost. If anyone stumbles across a “daemonburrito” post (could be lost somewhere during moves), that’s me, and may soon be me again.
On topic:
- I had forgotten that I had heard of the “nested part” solution that works currently, but it is difficult to document and not part of a documented UI flow. It does have the advantage of working.
- As the first message hints at, my primary interest is in having ERC/DRC and simulation all be possible with separate PCBs (maybe that distinction is important, with the modular design of Kicad,
eeschema, andpcbnew.) - It’s not particularly important if this feature is not immediately discoverable at this time, however, so major chrome work is not top of mind for me (though it would be nice someday, as mentioned.)
- The design of KiCad’s netlists presents some room for experimentation now that I might pursue, all plumbing for the most part.
- The “global flag problem” doesn’t seem insurmountable, but it does seem troublesome to work through without disturbing a UI that’s working great for its purpose now (using nightly builds.)
- One more implementation possibility is a
systemnew(or whatever we want to call the executable module) that would takepcbnewproducts as parts. It would be in keeping with the design strengths of KiCad overall. - I did follow the scripting API, and while it’s extremely useful for some things, I can’t see it bent for this purpose.
And I do, of course, realize that this is just kibitzing unless someone or something steps up to the plate. It’s possible to do in a do-no-harm methodology with a new systemnew and the existing text products that already exist for nets.
I don’t mind formalizing “nested” approaches, btw. It’s just that it may require intrusive work for UI. The new module (calling it systemnew for now) has the advantage of being invisible until desired.
tldr; plumbing and discrete, non-intrusive work is possible now without stepping on toes. “Nested part” approach already works, but lacks UI and would require surgery; it does however, work right now (and could be documented, hint hint). KiCad nightly is in a pretty beautiful right state now; a modular approach is appealing to me, at least.
Circuit simulation and PCB design don’t work well together in KiCad. Usually it’s recommended to have separate schematic for simulation, and it’s not connected to a PCB.
What exacty would you want from ERC and DRC, or what they should do with a “several PCBs” project?
That is also true in a more general sense.
For a simulation, it does not make much sense to add things like connectors and footprints, while for a PCB, the voltage sources ans spice directives do not make sense.
But that does not mean that one would exclude the other.
I think the biggest limitation would be that spice simulations are quite often done on a small sub section of a schematic, such as a filter or an SMPS (for those there are specialized simulators and design software). If KiCad were able to limit a spice simulation to a single hierarchical sheet this would be a lot easier.
Obviously, schematic capture/circuit design and PCB design are different concerns in my workflow. I am not proposing ERC in the PCB stage, after the network is completed in eeschema, or DRC in schematic capture. I think I’ve been misunderstood, or I was not clear, sorry. It’s obvious to me that I meant that rules no longer apply once we go from eeschema to pcbnew, where routes that would be connections between PCBs in a system are errors/warnings in DRC.
@paulvdh understands my thoughts, I think. I didn’t want to get too mired in something that’s really, really greenfield; my first message was just a request for clarification that we were discussing a wish for system-level view. We’re all working around it, in at least three different ways:
I ignore some DRC warnings and errors, if the ERC is fine, but I lose some advantage of an EDA when I’m using my imagination in the last stage and trusting that my connections are correct. I send separate boards off to fabrication after I’ve worked things out, but obviously, this doesn’t scale with many connections (say, dozens of connections on a ribbon connector.) So far, it’s not a huge problem, and wasn’t in earlier versions where I used similar workarounds. But the fact that there are so many “workarounds” and misunderstandings show that there is a need, eventually. Trivial example: Phoenix connectors with validated electrical connections in the netlist.
I must disagree on semantics, though: there is one huge connection between eeschema and pcbnew, between circuit design and PCB design: the network. Sorry to state the obvious. And there are even features in pcbnew that affect cicruits, like track tuning, layers, etc.
Again, @eelik I don’t want to get too bogged down at this spitballing stage. But if it helps to directly answer questions as asked, I want something similar to what everyone wants but is approaching with different workarounds (I think?):
Exactly what I want from ERC and DRC
I’d like the network designed in the circuit design stage (eeschema) to span any number of PCBs in the PCB editor (pcbnew)
or what they should do with a “several PCBs” project?
The “or” is inclusive, yeah? Complex designs can naturally span multiple PCBs for the purpose of validation in KiCad, and then sending fabrication outputs with confidence of electrical correctness provided by such. Obviously I could create the designs on paper or in an art program, and create text files by hand to send to fabrication, but we’re using an EDA for a reason. I’d like the final outputs of pcbnew to have been verified.
Cases where multiple boards are needed are clear:
- Power supply separation, for EMI or safety purposes, or even a power supply as a part.
- Stacking and modular features like expansion boards, and their buses, for customers and repair (this is a really common desire.)
- Electrical separation for avoidance of parasitic effects.
I probably don’t need to enumerate those, but I wanted to directly answer your questions as asked, in case it seemed like I was avoiding them. I think those are direct answers, and I don’t want to pollute the thread with repetition of thoughts and desires already stated; I’m already worried that I’ve said too much. Of course, if you want further description of what I wish from ERC/DRC and simulation, I will happily oblige. I just want to be a good forum member and not approach spamming levels of discourse.
I hope this has seemed friendly, as it is meant. I actually half-suspect that the features that we want are going to appear by surprise sooner than we think.
[EDIT] To quote the 6.0 docs and @set :
I think we all wish for this not to be the case:
KiCad currently supports one board file per project / schematic.
And all or nearly all features of KiCad to still apply.
1 Like
I’m violating the “not spamming” idea here, but I realize now that I may have misunderstood your last question, “what they should do with a “several PCBs” project?”; I understood it as “why would you want separate boards”, and maybe you meant “what should KiCad do with separate boards.”
I think that is the question itself. I think the simplest and least intrusive solution is one more tool, the systemnew which takes any number of pcbnew outputs and the netlist, with valid connections between connectors (maybe a new kind of wire or “route”, or just call it a “connector wire” in the UI.)
pcbnew fabrication outputs could still work as they exist.
Others here have proposed other solutions, like added functionality to the existing tools in the KiCad toolbox, making hierarchical sheets more powerful, nested parts, etc.
I have a sense of déjà lu over this but I think it’s a low-cost approach which is worth exploring as it will give experience for what’s useful. If nothing else this will allow system builders to document a set of interconnected boards. Or even things that are not boards, like power supplies, display modules, some of which might be off-the-shelf and not designed by the systemnew user.
2 Likes
would this really help tho? as far as I read it in the past most people who wants to have a “one schematic multiple boards” solution explicitly want to have multiple PCBs in one layout file for multiple reasons. the most often seen is probably production but also cross checking etc.
What more then is wanted from KiCad than what is there now? That’s the heart of the matter, what would you (they) want KiCad to do what it doesn’t do now?
@daemonburrito doesn’t have to be afraid of spamming or anything else. I blame myself for not being able to form the questions so that I would get the right kind of answer. All the time I just see that people try to do something with KiCad it’s not enough for (as far as we are talking about this “several PCBs under one project” question). I would like to know where are the limits of KiCad and what exactly it should be capable do to fulfill the need. And there seem to be different kinds of needs which go under the same name. Adding functionality for one use case wouldn’t necessarily help with another case.
Thank you, @eelik . The discussion, while it’s appeared frequently over the years, is just fine. And that reminds me, @Tojan , that I think we have the same goals. My main concerns, while I can’t rank them, definitely include cross checking; I hope semantics aren’t throwing anyone, I’m absolutely sure that we all want the same thing.
My spitball just comes from my “do no harm” experiences in programming with large codebases. KiCad already has, as a strength, a modular design which allows process utilities to be managed, while being separate entities as far as the OS is concerned (e.g., using the KiCad UI to start the project, do schematic capture with eeschema, click on the button that takes you to pcbnew when you’re satisfied which the ERC and any simulation you needed to do, then plugging in your fab’s limits and grabbing the outputs.)
The “do no harm” approach just takes the netlist along to one more process utility, which I’m referring to as systemnew for no particular reason than to have a name to discuss. It’ll have everything you’ve done in the previous steps, and its job will be to present a system-level view, maybe with special connections that don’t cause problems (the network is fine, pcbnew just rightly, with the “one board” limitation, lets you know when you have what it sees as connection problems.)
A new executable just seems like the safest path for experimentation, as it’s completely optional, and only becomes an official part of the process when/if it’s mature and useful to enough people to deserve a button on the toolbar in pcbnew and the KiCad manager.
It might make more “sense” to tear into pcbnew, but it’s an open-source project and there isn’t even a quorum on the feature. So systemnew is just my suggestion. Worst case, I learn a lot about KiCad internals. The wonderful thing about this project is its flexibility, modularity, and the ultimate parseability of the network description, which remains independent of this affordance that we want (features across multiple boards and components.) If it’s terrible, it’s terrible, and that will be okay because it won’t even be in the KiCad repository until our core maintainers believe its worth it. If it is liked, it will be an easy integration.
After that long spiel, and the previous messages, I think I’ve said everything I set out to say, unless there’s a question. It’s going to be in the oven for a long time, however it works out.
to be clarified, thats not my position I am completely fine with how KiCad does things now and manage my multi-board projects in a different way. I just saw that the discussion here did not picked up the imo most requested part of the multi-pcb design.
Many of these requests wanted to have an one schematic, multiple boards approach which is not currently working. Because if you use global labels or power symbols, you will end up having a number of unconnects between the boards which will irritate on routing because of the ratsnet as well as on checks because you have to check each unconnect manually. I can see why no one wants to do that for designs where you have dozens of shared signals between multiple boards.
Another point I saw often mentioned panalization in how they want it is not that great at this moment but I don’t remember the actual points they criticized there.
I think one idea to get rid of the ratsnets between boards would be to give a hierarchical sheet the option “do not connect interior signals to external ones” and the netlist calculator to check this option and well do exactly what the option says. But I don’t know how much bending of code this would need in regards on how global labels and power symbols are handled by the calculator creator right now.
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.