My major wish about personal symbols and footprints libraries: simplify, simplify and again simplify! Not downgrade features, but unify the interface (which nowadays is spread over and unclear).
My wishes are small as of now.
- Native Git support and graphical diff viewer (like CADLAB.io).
- Multi-board support.
- Board variants support (like Git branches).
- Native PCB panelization support. Currently, I import a design and create array from it for making the panel. But no DRC or nothing.
- Native V-Scoring support and 3D visualization.
- Able to see individual inner copper layers in 3D viewer.
- Exporting 3D image in custom resolutions (other than the native screen resolution).
- Able to specify Via-in-Pad for vias and able to see render them correctly in the 3D viewer.
- Via explorer to highlight and see same types of vias in the PCB and change properties together (instead of the existing non-interactive method).
- Track explorer to highlight and see same type of tracks in the PCB and change properties together (instead of the existing non-interactive method).
- Click a model in the 3D viewer to highlight the part in PCB and Schematic.
- A native parts database with MPN, Manufacturer, Footprint, Alternative Part, and other details that we assign easily while preparing the BoM.
- If a parts database it too much to ask for, then at least a generic API for applying these properties via plugins or CLI.
- Able to place hierarchical sheet pins multiple times!
- Edge plating support with 3D visualization.
- Grouping in schematic editor.
- Shortcut to move to next visible layer including to non-copper layers. Key modifiers will also be nice to switch between different layer sets.
- Multiple design constraints and rules profiles in a single project and the ability to switch between them and do DRC. This will allow a single design to be readied up for multiple fab houses.
- Swap option everywhere possible.
- Ability to measure Resistance, Capacitance, Inductance and Impedance of tracks and vias based on the board stackup data.
- Routing helper tool that will predict and show the next best possible move based on the constraints data. The predicted routing can be shown as a transparent or in some highlighting. Can be extremely useful when routing differential pairs. Press Tab key to accept routing.
- Graphical via stackup modifier tool.
- A beautiful splash screen to look cool in front of non-techy friends
11 Likes
- Fix 4-5 year old problems (systemic)
- Add multithreading to improve performance
- Stop changing file formats every year
- Introduce new features as they become shitty within one branch
- Don’t release new versions knowing about unresolved problems and errors
1 Like
I think this topic has turned into a hubbub of wishes that will be ineffective because they are not issue submissions at Gitlab, interspersed with whinge posts.
Well I’m pretty sure I’ll get my wish of tripling of the download price. 
5 Likes
Maybe Freecad has improved since I tried years ago and gave up on it as being WAAAAY too basic to be useful. But anyway, there’s another free 3D CAD tool that already has FEM, CAM, and a ton of other stuff already integrated and working well. Maybe it’d be better to use that instead?:
Can you share some info (possibly in a separate thread) about this?
A part from this post i cannot find any recent useful thead about salome in the forum.
A simple KiCad project example of exporting to Salome and some basic analysis would be great…
The greatest problem i see about a tight integration with KC, is the missing macos support; personally is not a deal breaker but i can clearly understand the importance of that for the KC project.
Normally, a good schematic contain all indication to a good PCB routing. I think that can be usefull define some Net propierties predefined on schematic. Posibility mark one wire on some parameters like minimum track width, min cleareance with another tracks, etc.
This is already (partly) implemented.
- Put a resistor and a Fet on the schematic. Make it R1 and Q1
- Put a 0805 and SOT-23 footprint on the PCB. Also change their RefDes to R1 and Q1.
- Draw a track between the 0805 and the SOT-23 (KiCad lets you do this, because all pads have the “No Net” name.
- Select the track, press e to edit it, and just type in a net name. In the “filter” part you can also create new net names. (I used “Birkel” as net name.
- PCB Editor / Tools / Update Schematic from PCB. Make sure that updating net names is also selected.
Voila:
The method is far from perfect, but also reverse engineering functions are being improved upon. I guess one of the complications is that it may not interfere with the forward workflow in KiCad. For reverse engineering you want to create connections on the PCB, while for the forward workflow, you want to prevent faulty connections in the PCB from being created.
If you have some bright ideas of how this can be improved (preferably in small steps) then create some feature requests for this on gitlab.
Yes. Nice hubbub. There are already plenty of feature requests on gitlab (1000+ I guess) and most of this thread will already be on gitlab. But this has a lower threshold, not all people are (willing to) participate on gitlab, and maybe this thread turns up some new ideas that are worth adding to gitlab.
4 Likes
Thank you for pointing out this workflow :-}. I’ll experiment with it and think harder about the topic. While my skills in KiCAD aren’t of the highest order, they are improving in at least some respects. “Round-tripping” isn’t necessary/desirable as an immediate task. At first blush it seems to me that exporting the derived schematic to a new project and then, if desired, forward-engineering from there would be a reasonable way/context in which to invoke the Schematic DRC rather than during the reverse-engineering process. I do think that forward-engineering a new PCB layout that correctly captures, in the sense of visual approximation is a good correctness check but that only needs to happen occasionally during the reverse-engineering process – at suitable well-defined check-points or simply at the end of the process. One thing that I’ve struggled with is how to capture vias properly so that I can work one side of the PCB before tackling the other. Handling partial knowledge of traces that disappear under device footprints (e.g., IC socket) and can’t be resolved without considering the emerging schematic and what would be “meaningful connections”. Your thoughts? A new thread would be fine. Or direct messaging.
Pin and gate swaps, synced between Schematic and PCB. It would make life so much easier during layout and routing. This would also be a huge thing for reverse engineering, today it’s a bit of a slow workflow going back and forth between PCB and Schematic.
API for Schematics would also be a nice one to have.
2 Likes
FreeCAD was chosen by a trusted, active member of this community who was willing to do the work that was needed at the time. You’ve posted a link to software that is ‘info wall’ protected and, after trying two different browsers, won’t let me download it anyhow.
User error. 
Like I said, if it’s improved enough in the meantime to be useful, or if we end up making it useful, then that’s good too.
Really?! It was free for me, anonymous with no account, and “just works”. Downloaded with Firefox in snap on Ubuntu Studio 22.04. (not a big fan of snap, but that’s how it comes) Installed first try, and works like the YouTube tutorials say.
It was a bit odd to find all of that though - the website isn’t laid out the way I expected, and the tutorials are not well connected to it - but it’s all there.
For you or for me? Did you cross it out because you eventually found what I did? Or are you still having trouble?
Yes.
freaking word limit fluff
Unfortunately, I’ve only started to use it myself, so I’m still bumbling around too. But everything I’ve done so far has worked well…once I figured out how this piece of software thinks. Mostly parametric modelling of some large woodworking projects, then getting dimensions from it.
I have not tried to integrate it with anything outside of its ecosystem, so it’s entirely possible for that to be a deal-breaker. It does import a bunch of standard formats though, so maybe that could be an option…
Just thought I’d mention a possibility, is all.
1 Like
I’d like the ability of saving/loading presets for plotting/fabrication output.
Without that, the risk of using the wrong options is too high. Unless you absolutely never change options. But if you use plotting frequently for different use cases, that IS going to happen.
I’m astonished about how many of the wishes in these lists are already there, sometimes even in older versions. This one is in 9.0rc.
People, please at least read the development news thread(s) first.
6 Likes
I’d like to have a clear separation between “Design Relevant” settings and settings like window position, last open files, etc.
This would it make much easier to have the different config json files under source control.
1 Like
The settings relevant to the actual design on the one hand and the settings for each user (UI etc.) are already mostly separated. The .kicad_prl file has the UI stuff and should be left out from version control, backups etc. If you find something which is in a wrong file, you can start a discussion about it in the forum or file it as an issue.
As eelik says, that’s been true for a while. See the file types documentation here for which ones you don’t need under version control.
Hi gkeeth and eelik
Thanks for your response. I know the different file types cause I am using KiCad since V4. As an embedded HW and FW developer I also now what files normally go into GIT. Maybe may wish above was not clear enough so I will try in other words.
In our small HW Team I would like to have a setting that all KiCad user have the same “Design Relevant” setup and that this cam out of GIT. Modification after a review go back to GIT.
The Idea is to symlink the local git repo to the KiCad setting location (as ex: ln -s ~/Desktop/eb-kicad/kicad ~/Library/Preferences/ on OSX).
This setup works beside the following things…
For me “Design Relevant” settings are: (jsut some to show the problem)
- annotation settings (eeschema.json)
- default fieldnames (eeschema.json)
- “origin_invert_x_axis”: false (pcbnew.json)
- “origin_invert_y_axis”: true (pcbnew.json)
- “origin_mode”: 1 (pcbnew.json)
- “plot settings” (pcbnew.json)
- “gen_drill” (pcbnew.json)
- fp-lib-table
- sym-lib-table
“Fancy Settings” are:
- last open files (eeschema.json), (pcbnew.json)
- last open windows position (eeschema.json), (pcbnew.json)
- “last_footprint_lib_dir”: (eeschema.json), (pcbnew.json)
Now the problem is that “Design Relevant” and “Fancy Settings” are stored in the same files and therefore it is not possible to have them in GIT or it makes it at least very difficult to track/merge only the important things.
So it would be nice to split the different json files in static and dynamic files. The static files could then go easy to GIT.
I know the big discussion would be then to decide what settings go in which files.
Hope that helps to understand my idea.
1 Like