No sir, I have not but now I will. Thank you 
FYI, this is already possible in v8, in Board Setup → Formatting:
1 Like
I’m happy with how KiCad is now 
I don’t know what is in V9 so may be what I write here is already done.
- I’d like to see in KiCad User layer pairs (I need only one pair).
I start using KiCad from V4 and to make documentation files we ‘since always’ do for us (element rectangles with reference inside, and separate file with values inside I decided to have reference and value at Courtyard layer (to add to rectangles that are already there). KiCad V4 had nothing against it but later started to complain on it. The only alternative I find is to use Adhesive layers for it as we had never used them, but as you never know if you will not to have some feature there is no idea to block it for yourself. If we will have User layer pair I will move there with value and reference and will have Courtyard in the form satisfying KiCad.
- I’d like to have block dragging.
Beginning PCB design I divide footprints into blocks and connect everything in blocks. Then I move blocks on the PCB and make connections between blocks. If I find that block should have little different position my current way is to cut it out (disconnect its connections) move a block and re-route connections.
But as I have written at the beginning - KiCad practically fulfills all my needs but I mainly design 2 layer boards and recently some 4 layers.
When I was using Protel 3 (1997 - 2017) I was using few design rules.
One example: to make thermal connections width being dependent on element belonging to class (I was dividing elements into small / medium / big classes). In KiCad I just made correct settings for each footprint in my library.
Second example: to delete default paste layer opening for thermal pad to be able to replace it by defined by me openings. As I remember I didn’t found the other way. In KiCad I have correct openings specified just in footprint definition.
I have never used even a one design rule in KiCad, but my pcbs are relatively simple.
2 Likes
Kicad ist not only developed by hobbyist but also by paid developers at KiPro (KiCad Services Corporation). And it is not only used by hobbyists but also by companies and organisations of any size. When migrating from any kind of EDA system like Altium, PADS, Eagle etc. to KiCad, it is very important to have a reliable roadmap for further development of the software. Keep in mind that migration includes many tasks which are very costly.
It is also a misunderstanding that FOSS means that there are no professional activities. Instead there are big ecosystems around many FOSS projects, especially Linux. Many companies use Linux based servers for business critical services, and other companies build their entire hardware products around a Linux based firmware.
For my company the planning of a migration from Altium to KiCad took several years because some important features were missing. And I wouldn’t have started the migration without joining the KiCad conference and talking to the lead developers because this means a complete shift of my business model.
2 Likes
Have you had a look at KiRI (KiCad Revision Inspector) ? (Also available here as a Docker container).
3 Likes
Thermal simulation, using the board setup with tracks, copper thickness, via position, count, copper surface and thickness would be great. Even if done outside of Kicad (maybe in Freecad with an exported 3D).
What is that simulation picture taken from?
4 Likes
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