RFC - KiCad Blueprints

Community Feature Request Chat
1

Overview & TLDR

The current situation regarding templates is confusing.
ATM they are getting used sparsely and often a differentiation to footprints is really hard or not defined.

I want to present my idea of how I would change and extend the template system, ask for input and see how we could implement it.

References and previous discussions

KiCad Internal

Demonstration/Capablities of other EDA tools

TBD

Current Limitations

Templates are currently basically a imported KiCad project, meaning a lot of unwanted/unneeded information like configurations are saved and distributed in them.

The main usage of templates atm is to provide the basic outline for module daughterboards (e.g. a Arduino or RaspPi HAT).
If we want to design a motherboard (meaning that the module gets placed onto the PCB), the approach is to use the modules footprint.
For modules with multiple components (e.g. pinheaders), the BoM generation is not working as it only shows as one element.

Besides the current use for modules or standardized shapes where the basically the most important informtion is the edge.cuts layer and mounting holes, a logical similar use is for general and often used circuitry (e.g. buck converters, BGA fanouts, minimal uC circuitry).

It is not possible to import data in an exisiting project with templates, or save a existing project as a blueprint for future use in the main project.

The current workaround for repeated circuits is to use a schematic and import it multiple times in hierarchical sheets.
For PCB data there is no workaround, except using a action plugin like MitjaNemec’s Replicate Layout.

Proposition

Overview

My idea is to combine the current use of templates and the idea of circuit-blueprints into one concept, as they are quite similar.

I think it would be better to decouple the blueprints from a general .pro, .kicad_pcb and .sch file.
A single file, compiling only the necessary data for the schematic and the PCB would be a better.
I will call it .kicad_blueprint for this discussion.

As already said, I can think of two kind of seperate parts for a blueprint:

  1. Module
  2. Circuitry

When the blueprint gets imported into an exisiting project, the configurations (text sizes, drill sizes, dates, you name it) are unchanged and only the necessary information gets included.

It can be necessary to modify the PCB design data of the blueprint, according to the desired usage.
If the blueprint is a module, the user has to define in what configuration the module has to be used and should be asked during import.
The options are:
a) HAT: meaning the module is the motherboard and the PCB to be designed functions as the HAT. Here the outline of the board will be on the edge.cuts layer.
b) ELEMENT: meaning the module is only a element of the board, similar to a footprint.
The outline would not be interpreted as the edge.cuts layer but as e.g. a silk outline.

Some outlines/edge.cuts elements are independend of the useage and have to be included in every case (e.g. for too big components like the RJ45 connectors of the Raspi).

During import the user gets to decide how the blueprint will get used, and the data from the blueprint file will be parsed into the kicad_pcb data accordingly.

The workflow could be similar to this:

grafik
grafik668×831 48 KB

Problems

  1. I am not sure ho we sould add the PCB-elements into PCBnew.
    Ideally this would be similar to when footprints get added.
    After the placing the symbol and the update of PCBnew all new elements are selected.
    In our case all elements (footprints, vias, tracks, …) are in the saved configuration together and can be placed.

  2. TBD

Discussion

This post is meant to be used for a discussion to think about:

  • Is the proposition sensible and the function necessary
  • Additional ideas, missing features
  • Feasability (idealy from the core development team)
  • Better ideas?
  • are some people interested to work together to implement a blueprint functionality. I am willing to put time and money into this iff we get a solid and thought out concept.
2

I think there are some interesting ideas there. The major missing piece is how do the blueprints get created?

The advantage of templates is they are basically kicad projects with a little extra metadata, so they are easy to create.

1 Like
3

Good point!
I would think that using EESchema and PCBnew with very few additions are sufficient for this.

One idea I thought of was that if we open the blueprint file directly, KiCad parses it into a normal Project, where we can modify it accordingly.

I think it would be ideal that we can export a KiCad project into a blueprint, which basically strips everthing not needed of and prepares the data to save it into the blueprint file.

This should solve both “importing” (so opening) and also exporting (saving).

Of course there will be a lot of stuff to think about in the implementation. But I think we should not add additional tools if not absolutely neccessary.

4

Why would these modules / Blueprints be a separate thing?

About a month a go I toyed a bit with “hierarchical projects”
A bit like “hierarchical schematics”, but then on the project level.
If was just an experiment to see if I would encounter mayor problems, but it just all seemed to work as I expected.

https://forum.kicad.info/t/multi-pcb-project-idea/17657

Including a whole project as a sub project in a bigger project is a very flexible way of doing things with minimal changes on the development side.

5

I’ve been thinking about this, and I think the different use cases are not similar enough. For example, it is not trivial to convert from a module to a pcb (or vice versa). There is an additional use case, which is if the template is to be used to create a motherboard.

I think it is too complex to handle all the use cases in one blueprint file. For modules that are elements, I think this is already catered for by symbol/footprint libraries (I don’t agree with the official librarians view that modules should be templates, especially when the reasons given are patently wrong).

I think I would take the separate use cases and look at how they could be handled, and then identify common areas.

6

The problem I wanted to solve with this are:

  • ignore settings ins the blueprint. Things like DRC settings, paths and a lot of other stuff that is unimportant for a blueprint are included into a project, kicad_pcb and sch file
  • easy modification during deployement. as stated in my first post some elements have different importance/functions in different settings.

But your idea is not bad, tbh I did not really think about this a lot.
If we could make a “minimal project” meaning only the absolutely necessary stuff is saved and the settings are inherited from the main project.

This would be a lot easier to implement on first thought.
Thank you very much for this idea!

7

IIRC we previously discussed the template footprint thematic some time ago in another thread or at github.
I disagree with the usage. A single footprint for a module is not optimal as the BOM, the component placement coordinates and other informatins are wrong.

Also I do not understand what the difference between a blueprint and a module would be.
A module is just a number of components placed in a specific dimensions.
It could be that I missunderstand you because we define the things differently.

Where do you see the difference between say a Arduino module and a buck converter circuit?
In both cases the blueprint/template consists of multiple components placed in specific location according to the specification.

8

The terminology is confusing, partly because KiCad historically uses the term module to mean footprint. You have also defined two types of module, element modules and hat modules. I would describe a module as a PCB mountable subassembly, e.g.

I would call a number of components placed in particular positions a template, block or sub-circuit.

That depends, does the buck converter circuit have traces? Or vias, copper pours, other PCB features. In a footprint, a mounting hole can just be an NPTH pad, but on a PCB a mounting hole has to be a footprint (usually anyway).

I think there will be problems there, because the context might be important. For example, symbols need to be in a library, which the circuit must refer to.

Anyway, I’ve made my suggestions. I’ve spent quite a bit of time writing code to process KiCad data files, I just finished writing a conversion tool to convert pre-v4 projects to v5. I would encourage you to spend some time looking at the KiCad data files, because I think the proposal as it stands is not really workable.

9

I’ve reviewed past threads about this both here and on github, and its one of those things that has been going in circles for years.

There is confusion about templates vs modules, but to me it is clear. It’s is a false dichotomy, it is not either/or, because for different use cases both are needed. Modules and project templates work quite well if used in the right way.

There are some underlying issues like the fact that a KiCad component is associated with a single BOM entry. That is the same problem for DIP ICs, battery holders, fuse holders as well as pluggable modules.

I think it is best to concentrate on what people really want, which is circuit blocks which can be added once or several times to a project (I’ll call them design modules because that is what Autodesk calls them), and how to add that functionality.

I think probably templates can be adapted to implement design modules, without requiring new file formats.

As it happens I am currently working on a board with 10 copies of the same circuits, so I would quite like to use a reusable design block. I also have a DC-DC converter module I would like to re-use.

I will use these two as test cases and think about what implementation is needed.

10

This is already in the works [1] and has a technical spec[2]. Will arrive in v6.

[1] https://bugs.launchpad.net/kicad/+bug/1521062
[2] https://docs.google.com/document/d/1y7AL9M4350vifdX3lmcU77sLQ8YWy-fBtMmfsXEObqg/edit?usp=sharing

1 Like
11

Thanks, I missed both of those! Look forward to it :slight_smile:

12

I missed those, too.
Awesome thank you Seth.

13

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.