You kind-of can, but it is an all or nothing deal. When exporting to gerber you can choose to tent or not tent ALL vias:
I’m not convinced that either of those two links in @eelik’s reply will do anything for via tenting, unless the mask layer is included in the future pad stack editor. (I don’t see any explicit mention of the mask layer mentioned when quickly looking the links over.)
If by “component pad library” you mean what KiCAD calls a “footprint”, yes that is a known issue. I think it is being worked on, but I don’t know the specific gitlab issue number(s). Hopefully because the head librarian also wants this it will float up near the top of features to add before v6 is released.
I’m not familiar with Altium, (and I never will be) but I’m curious how familiar you are with the interactive router in KiCad. I find that with the right settings it just pushes traces and via’s aside to make just a little more room to squeeze in those last few tracks. I’ve made a denser board with it then I would have dared otherwise because of a too big risk of having to move QFP components on a nearly finished design.
Not to denigrate KiCad, but the Altium router is worlds above. In some cases it’s more like a guided autorouter. I especially like glossing and the nice track cleanup tools in Altium.
I love KiCad more because: freedom, open file format, scripting, etc but on nice interactive routing interface and control, Altium is so so much better
If someone needs via mask options and wants to remind developers about that, they can go to the main issue and add a comment there to make that detail explicit.
If our chain of interpretation eepete->SembazuruCDE->eelik is correct, we are talking about “keepout areas” in footprints so that you can keep tracks and zones out of an area in a footprint.
I supposed that the talk is about Edge.Cuts in footprints.
In my first KiCad PCB (4.0.7) I needed it and have to do it at PCB level so any move of footprint resulted with separate moving the opening (rectangle with 4 round extensions for milling tool).
Now I have the E ferrite going through PCB so 3 openings each with 4 round extensions.
It is not explicitly mentioned, but once KiCad can keep track of pad stacks for every hole, it is possible to modify pad stacks for individual holes easily. Pad stacks include all layers that are relevant to holes, including masks.
thanks for the reply ! I looks like these ideas are in the works which will make a great system even better. Seems like big software packages like this are prone to feature creep and “80-20” rule (80% of your use is with only 20% of the features). The “two character shortcuts” seem like a natural evolution when you run out of single keys. They support a somewhat natural hierarchy since the first letter is a general action (Place, View, Edit, Move) and the second is the object for the action. Having looked at the link you were kind enough to supply, it looks like there is good awareness here and I’m sure the same skill that produced KiCad will implement this in time. Since we are all good 'ee’s I’m sure we will argue vociferously about the letters and then learn to use the final outcome.
I’ll try some screen shots for the routing issues.
Other replies were correct on the “cut-out”. I have a small OLED display where the footprint is the overall rectangular area with 4 holes where screws hold the display in place. The display fits in an area of the board where the entire PCB has a cut-out/routed-out hole. I could not use the layers that is used to prescribe the outline of the board for final routing to get the finished shape in the footprint, so I had to add it in at the end of the layout.
OK on that being a known issue. It’s one of many things that save a few minutes. I have only one component (a display on a small PCB) where the footprint has the cutout where I place the display “inside” of the plane of the PCB and thus need to route out an area from the PCB.
It looks like the Pad Stack concepts that are in the works will get to this. Hopefully that will also allow you place an arbitrary pad in the PCB without having to create a one-pin component in your schematic.
Thank you for your reply !
Indeed the routing is the only thing I found that was in Altium favor.
It is not a “Different approach, but still gets the job done” contrast between the two systems. It certainly behaves like a system that remembers what it tried to do for you, and if you back-off it is smart enough to try another approach. So from the end users point of view, you just keep “approaching” the direction you want to go until you see what you want. Easy and quick to do. I’ll have to take some screen shots and post to better illustrate the issue.
A few years ago I was in need of an update for a PCB & schematics program that ran on Linux. Back then KiCad had some quite horrible bugs in the library management and with KiCad 4 those bugs have been fixed. In the mean time KiCad has grown considerably and it gets better every update. The stable version is still missing some “obvious” features, and some of them have already been fixed in the nightlies.
A few years back I was longing for KiCad updates and ran the nightlies just to get rid of some of the annoying bugs. The current V5.1.5 is so good that I no longer feel a real need to run nightlies, and prefer a stable platform.
At the moment I absolutely love the interactive router in KiCad. Just being able to push a track or via in between an already existing layout works already better than any other program I have used, Though that does not say much because my old software was obsolete anyway.
I am also aware there is still lots of room for improvement.
Having good descriptions of newly wanted features is one of the first steps to be taken before they can be implemented. User input of people experienced with other layout programs and detailed descriptions of how those nice features work in those other programs may help in improving KiCad.
One example of a report is https://gitlab.com/kicad/code/kicad/-/issues/2336. (Reminds me to add an example board there…) It shows how screencasts and/or screenshots can be very valuable for these kind of things. Describing with words may be nearly impossible sometimes. If you have access to Altium maybe you can take a screencast of the wanted behavior.
Honestly, this is what I was hoping. I was just pointing out that mask layer wasn’t explicit in the top level of those discussions so there was no guarantee that you Devs had that on the radar. Having heard from you, I’m now convinced.
I found this to be a major problem with KiCad. Old design files are basically un-openable. Even if it is possible to get them to open, you get a bunch of dialogs which are really hard to understand and it is unclear what the result will be (or even if your files have already been modified or not).
The way I solve this is by using brute force. I set up the (current at the moment) KiCad version in a VMware Fusion virtual machine, copy my files into that, verify that it works (without networking), and then archive the whole thing. Yes, it takes up gigabytes of space per project. It’s an insignificant cost compared to not being able to open and modify your project a year later.
I think this is a problem that some KiCad developers might simply be unaware of: if you live with the latest version every day, you don’t much care about backwards-compatibility, and not everybody needs to pull one- or two-year old projects out of storage. I had a fruitful discussion with Wayne about this during last year’s KiCon, so I hope things will improve on that front some day.
These bunch of dialogs appear because of the current symbol library system. That will change with the new file formats when symbols will be embedded into schematics, like board files/footprints are now already. Adding something to old designs may still need some work because the libraries may not be fully compatible, but we’ll get rid of the first-time dialogs and old schematics and boards will be fully understood with new versions.
If there are interpretation problems when opening old files, they are high priority bugs and will be fixed when found.
IMO it’s probable that when 6.0 is released some cases will be found where conversion from old to new schematic/symbol file format doesn’t work perfectly. But they will be fixed quickly.
Updated libraries are actually part of the problem. What I’d really like to see is a way to “freeze/archive” a project: create a static package with everything inside the project (e.g. copied from the libraries), so that the project becomes independent of external libraries.
That way I could work on a project, freeze it, and be sure that I could open it a year or two later.
This is exactly what I’m doing with my VMware virtual machines: freezing the project, libraries, KiCad and Ubuntu Linux in a single archive, which I can open two years later to make a small modification and produce another set of gerbers.
Around 2020-03-03 I also posted a few messages on Mitja’s Issue 65.
I have sort of concluded that most of it will be in KiCad V6 anyway.
In KiCad V5 Footprints in the PCB are cached in the PCB anyway, and they will only be updated from the libraries by explicit user intervention.
I assumed that the new schematic format in KiCad V5 will work the same for schematic symbols.
But still, I would much prefer to have an “archive” button in KiCad that removes all references to external libraries. It is my opinion that old projects are better to be preserved as they are then updated to possibly incompatible symbols or footprints. But then again, If parts are only updated from libraries if you explicitly tell KiCad to do so, the whole subject becomes mostly irelevant. Maybe it’s useful to open an issue about archiving projects to make sure developers are aware of this. Such issues probably already exist on github / gitlab. Also here on the user forum there have been multiple discussions about archiving projects.
As it is now, 3D footprints are not archived in any way I think
I’ve opened some old KiCad V4 projects in KiCad V5 by absent mindedly accepting the “Resque” thing, and then later closing the schematic without saving it, cause I just wanted to look at the schematic. This seems to break the schematic. I do not have enough experience to remember what happened exactly. It seems you change the links to the “rescue” lib during the “resque” process, and if you then not save your project the links get broken. Read rene’s FAQ on how it works exactly.
I remember following this guide a while ago to have portable projects, where all the information was contained in the project folder and it worked pretty well. If you haven’t maybe you would like to give it a try (it is convoluted, but scriptable)
