I’d like to see the introduction of ‘PCB design blocks’ and integration with the schematic ‘design blocks’.
1 Like
Multiboard support would be great, indeed!
For me a project would be the complete product that I want to build.
Having a main schematic that allows to define sections for separate PCBs that are connected by nets.
This would break down in several PCBs with individual Layer Stack (CPU 6layer, General 2layer, Power LED on IMS).
With a 3D reference point in the PCB setup dialog the 3D viewer could eventually show all PCBs as they would later be assembled in the final project. Allowing for collision checking and easy exporting of the complete electronic package.
11 Likes
Recently I sent 12 of my boards off to a company for PCB assembly. Note that I use mostly or entirely my own footprints. The assembly company noticed that many of my footprint pads (in the gerbers) were missing the paste layer. I think they needed that to make a solder paste stencil. The pcb itself was OK.
When I went back to fix that, the only way I could do that within KiCad was to add the layer, one pad at a time. I was unable to add the paste layer to all pads in a footprint in one operation, at least not within KiCad.
After I was mostly done, I realized I could do find>replace with a text editor to add the paste layer to all pads of a footprint. All I had to do was look at the text for a pad which HAD the paste layer to see what I needed. I then sent out new gerbers to the assembler. But…that was a hack. Why doesn’t the footprint editor allow for that?
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Also…I seem to remember that in pcb editor I cannot drag (several pads + tracks) at once. Is this some sort of computational limitation?
1 Like
For me it works relatively simple.
- change on/off F.Paste for one pad.
- context menu - Copy Pad properties to Default.
- select pads I want to get this settings.
- context menu - Paste Default Pad Properties to Selected.
‘Push Pad properties to Other Pads’ could be faster but if pads at rectangular footprint don’t have different orientation but only different dimensions they all get replaced dimensions.
I prefer to have better control of what I am doing and if I work on made by me selection I know what will be done.
If I remember correctly, we started working on the specification for the current DRC engine (the underlying logic of the DRC, checkers, DSL scripting aka the rule expressions) in late 2019. I am not surprised your colleague’s email about a user interface for the DRC rules might have been missed in 2017 as it was rather difficult to discuss the UI for something that hadn’t existed yet 
We would like to have a comprehensive UI for DRC rules at some point, but:
- it needs to be easily maintainable (we support 3 major operating systems with their own UI/UX quirks)
- it must not cause conflicts with the user’s provided textual rules
- someone must find the time and motivation to design, code and test it. And then - maintain (as every new DRC check would require a new rule editor).
Tom
1 Like
Thanks! 
Ahh OK this seems like it may work OK. I wish that someone was able to steer me that way when I was doing this…
One area of confusion is that “pad properties” includes the “pad position”. So:
- If all of the pad properties are copied, then the pads will all overlay each other as they will have the same position.
- If the position is not included among the copied properties, then…OK…which parameters are copied? This is not clear… I think adding one more step…to select which properties are to be copied…might be helpful.
I had tried that but as you indicated, my pads are not all the same. So this action caused more problems than it solved. It would have been great if I could de-select “pad dimensions” and also know that it would not select “location.”
For me forward compatibility would be high on the list.
At the moment, once a project is saved in a new KiCad version, it can no longer be opened in an older version, i.e. the old version is not compatible with a KiCad version from the future.
I am guessing a lot of people are putting off trying out newer versions (or the development version), because there is no (easy) way back.
KiCad’s developers are apparently not very interested in this. It is of course a distraction from the main development, but I am guessing / hoping that if this is implemented, more people will be willing to try out newer versions, and with the (optimistic) result that a new version is quite stable when it’s released, instead of the mayor bug hunt / report / repair cycle that now takes up the first few months of each new mayor KiCad version.
It all also depends on how much effort it takes to implement this. KiCad’s file formats have been stabilizing over the last few years, and for that I guess it’s not much work for the KiCad developers. For me, the function also does not have to be perfect. If the old KiCad can read the parts it does understand, and give some overview of the parts from the newer file format that it does not understand, then that would be great.
8 Likes
Multiple PCBs per ‘Project’
Able to print across multiple pages (eg banner printing of sorts)
MagnetIc connections in schematIc
Developers producing help files/information of feature they develop
Nominal one off payment for obvious business use eg collaboration or Database usage.
Consolidation of GUI and menus
Gate swapping
Integrated update/upgrade of KiCAD
Wizard / graphical based PCB stack up including track, via etc configurations
True transparent two way updating of schematic & PCB
4 Likes
It’s interesting for me to read other people’s wishlists but it’s not useful to reply to twl with your wishlist. Most of the wishes are already in the issue database or even implemented. The official way to make your opinion known to the developers is to give thumb up for an existing issue or to create new one if there’s not an issue for a certain wish already.
2 Likes
Are you saying you want us to somehow start charging money for use of KiCad?
FYI, there are actually good reasons for us to not do this. We have some great developers and documentation writers, but they are often not the same person. Not only is it true that some people are more interested in one than the other, but also it is a useful “check” to have someone who didn’t develop the feature try to develop the documentation for it, because it’s an opportunity to discuss when workflows could be more clear, etc.
4 Likes
As a concrete example, as we refine 9.0.0-rc1, the development team have been actively iterating the UI and behaviour for some new features following feedback from the documentation team who are working hard to get the docs up-to-date for the new version. It’s made the UIs better, and the features more usable. Win-win!
1 Like
Indeed, Gitlab is a much better place for wishes - and after a brief read of this thread I think most of them are there already. As for why we don’t always implement features in the order of requests (and also why features that seem simple sometimes really aren’t), I recommend the story by John: A brief(ish) history of inconsistencies
1 Like
In addition: The ability to add a secondary footprint to symbols so one can make both a THT and SMD board in the same project.
3 Likes
Addition:
For everybody: Click the hart to “Like this post” for any feature you like. (I see very few of these as of yet).
Use it as a voting system to see how much interest there is in various features.
Note:
I’ll mark this post as “the solution” so it gets attached to the first post to give it some more visibility.
2 Likes
Thank you, @Schweigstill for the reminder. Shame on me for the omission. If it wasn’t for KiPro, not only would the functions available be fewer, but the Kicad revenue stream be smaller.
Of course. My comment was that I am very happy to still able to work with a quality product that suits my retirement budget.
PCB stackup into regions for flexi-rigid
PCB stackup with odd number of layers for metal cored and backed PCBs
8 Likes
LTCC (Low Temperature Co-fired Ceramic) is another PCB manufacturing technology in which the layer count can be odd.
1 Like
- unpacked symbol library: this will work better with git than the current packed one
- pcb design blocks
- monorepo support: that is putting many pcb projects in one git repo, while still be able generate gerber packages one by one.
The monorepo idea to kicad: putting many kicad projects in one git repository (#18956) · Issues · KiCad / KiCad Source Code / kicad · GitLab
2 Likes
Flat design. Remove the mandatory usage of hierarchy blocks.
7 Likes
This is something that was planned for v9, but got pushed to v10
2 Likes