I would like to revisit multi-pcb designs with a few differences from previous conversations.
To give an idea of where we are coming from, my company is developing a complex high voltage power converter. Our first product design consists of half a dozen boards that are directly connected together using various interconnect mechanisms. Due to the voltage involved, creepage and clearance is a non-trivial problem effectively requiring DRC between boards. Traces on one board have such high clearance requirements that they affect the layout of neighboring boards. With current Kicad, this is not supported, and there are no really satisfactory ways to accomplish this. This leaves us trying to implement workarounds using some custom Kicad plugins and exporting things to Solidworks. This solution is A) fragile, B) error prone, C) ugly as hell. We have a second product that consists of dozens of layers of stacked PCBs where each PCB is stacked to the ones below it by direct solder pads connection on the mating sides of the boards. Some of the inside layers have SMT components which end up completely buried under layers of PCB (which is why we can’t use a single multi-layer PCB layout). We currently use the same hacks as above to fit this within a Kicad and Solidworks flow with all of the same problems.
I am working to convince my partners to put some real resources into upgrading Kicad to fully support this kind of multi-pcb project. To that end, I am looking for two things: First, an idea of how we could structure the end-user workflow so that it would be acceptable for the Kicad maintainers to adopt upstream, and second, I want to get some idea of how much effort this kind of project would involve (once we have an idea of what to build) so that I can sell it to the stakeholders. I have the opinion from our internal devs, but that is a lot different from the opinions of people who have done more than minor tinkering in the codebase.
To set some expectations.
I am not looking for someone to actually modify Kicad for us, although volunteers wouldn’t be turned away.
We are fully aware that this is likely a multi-year, multi-developer effort.
We would prefer to fit this effort within a larger vision for Kicad so that we can get some kind of guidance on how to make the new feature-set fit within the “look and feel” of Kicad.
Making something that does not have buy-in from Kicad maintainers and eventual inclusion into Kicad is probably a non-starter.
I do not have the green light on this yet. I have a lift ahead of me to sell this, but the clearer the vision is, the easier it will be to sell.
Based on your description, I would be surprised if anyone were able to offer you an informed opinion.
It sounds like you are describing a way to design multiple boards in a single project and then orient them spatially in 3 dimensions relative to each other and then run some DRC checks on that.
Then, you will likely need a way of designating board-to-board connections. Somewhere we had a request for a way of building pinouts into KiCad.
Then, you will need a way of manipulating 3d models. Ideally, this would include some form of 3d constraints and/or measurement.
Finally, you get to the easy part, which is the 3d DRC check. This is relatively easy because it doesn’t require much in the way of new UI, just updating existing code from 2d to 3d and avoiding the slowdown pitfalls.
I would suggest that you propose smaller steps to your bosses that are not multi-year efforts. I suspect that your workflow could be improved by any of smaller steps.
We’re pretty open to definite plans by external companies if they have resources that they are willing to dedicate to learning the KiCad codebase and implementing ideas. However, it is usually faster and cheaper for companies to contract with us to build out features.
I definitely agree that separating it into smaller deliverable steps would be more ideal.
My thinking ( so far ) is along the lines of:
Update schematics to allow multi board. From a few suggestions I have seen, I think this might be possible with relatively minimal changes to the schematic tool. First, make the schematic editor able to handle multiple PCB layouts by changing the layout ↔ schematic to have a hierarchical sheet associated with the interaction (or root page for single board designs). Next, create a special symbol type that is both a sheet pin and a regular symbol (with footprint). This way, the schematic can render everything almost normally, but the sheet pins for the PCB top level sheet (not necessarily the schematic top level) would have a footprint that is included in the layout. Unless I missed my guess, this is actually a fairly limited change to the schematic editor.
The next part is a little trickier. Having the PCB layout understand that the connector component is a little more than just a footprint could be challenging, but my thought was that we upgrade footprints so that the 3D element of the footprint could use the existing step file mechanism to represent the “other” board in the connection. We could then leverage the ability to output step files from one PCB design to be imported into the other PCB via the connector footprint. I think it would be acceptable to just render the boards together in the 3d viewer as a good first step. Probably for cleanliness we would only render a section of the connected board (maybe to a certain radius from the connector, maybe dimmed). This way its clear which is the current board and which is the connected board. The existing 3d model code can handle 6 axes of freedom between the footprint and the model, so this would allow the connected boards to be at any arbitrary relative position.
The last step would be to leverage the 3D view code to help with the 3D DRC. This part wouldn’t necessarily need to have a nice visualization as you indicated since it just needs to show errors. We could add better visualizations later as the feature becomes more sophisticated.
We’re pretty open to definite plans by external companies if they have resources that they are willing to dedicate to learning the KiCad codebase and implementing ideas. However, it is usually faster and cheaper for companies to contract with us to build out features.
Contracting for the work might be one option. For this project, I suspect that the primary funding would be through Grants so I would have to see how that would affect this option.
The first step is probably the same whether we directly contribute code, or contract with your team(s): Figure out what we’re building and how much effort and cost will be associated.