I am hoping the next release with have via stitching which will make this much nicer to implement. In the meantime, converting vias to single pin modules seems to be the best way.
while the via to pad hack works for standard via’s, it can’t work for berried via’s, so I would expect
the same limitation would still holds for via stitching. I’m have no idea if the via stitching allows you to use
berried via’s.
Lachlan
Hm… ‘berried vias’, I like those 
As for the features & improvements… with more users come more coders/hackers and thus more helping hands for KiCAD.
Will be fun times.
I just hope the dev crew can cope (or better deal) with it(*) constructively 
*) it = the influx of new/different ideas
yes very tasty ! LOL,
Lachlan
Adafruit had been a retailer of Eagle software, but that is now gone from their online catalog. I’ll probably suggest to both them and Sparkfun to switch to KiCad to better serve the maker community, at least to offer KiCad versions of their part libraries.
I have used eagle in the past to design a PC board or two for myself. I’ve now started to teach myself KiCad from many of the tutorials on line. The schematic capture part is on par with Eagle’s, and I’ve not dove into the board design part much yet. The bit with separation of footprint and schematic symbols makes sense, with that one could easily take an existing through hole design and change it into an SMT version very quickly. Why hasn’t anyone else thought of this?
1 Like
If the anticipated influx of people converting to KiCAD from Eagle is a culturally diverse, international, group . . . will we need a new Forum category to explain the English-language humor, idioms, and slang expressions?
Dale
One of our Czech colleagues was very puzzled by our request to put “ferrets” on the cables, he replied with a picture of a ferret and the words “This is a FERRET???” we all had a laugh about that. 
2 Likes
I just blame it all on the spellchecker and the fact I’m 60 and have Swiss cheese brain, after spending a life
in front of the computers ! 
Talk about diversity and tolerance .
Perhaps we should open up a forum to make fun of native speaking English folks raping the German language 
.
Or things like this one: I just bought something in the UK and instead of Austria, they sent it to Australia. No kidding.
In the same way evil Oracle ended up with MySQL, so too has monstrous Autodesk ended up with EAGLE.
In the same way that nearly everyone fled to either MariaDB or MongodB after the Oracle takeover, nearly everyone will similarly abandon Autodesk’s mauling of EAGLE.
Even if Autodesk rebukes itself and returns to original EAGLE pricing/purchasing model untouched, they have already rolled the boulder over the cliff’s edge for many serious commercial users.
We have hundreds of boards in EAGLE and have been paying their per-major-upgrade pro fee for at least two decades. That may amount to $20k by now.
KiCAD needs two things:
-
a way to optionally store component + model into a file and then be able to reuse that combined data in new projects, instead of forcing everyone to the hideous redundancy of assigning model to component in every single board.
-
a “code bounty” section where money can be paid by serious commercial users-to-be to have specific features created like #1.
We’re swtiching to KiCAD anyway, but good grief, #1 REALLY REALLY MUST BE ADDRESSED ASAP.
2 Likes
This feature already exists in Kicad.
But if you want to pay for it, the guys at CERN will be delighted to accept a donation 
5 Likes
Which feature? #1 or #2 ?
#1. It is called atomic part
Each symbol has its footprint field and possibly other fields like house part number, order information, … pre filled. You can add any field you need to your personal libs via the symbol editor and give it the value you like.
This of course means you need one symbol per part. (Maybe even one footprint per component. But i think footprints can be shared for a lot of different components.)
Such a library needs to be build up by each user thought. Because it is too much work to handle a generalized lib that fits the needs of everyone. (A lot of incompatible requirements -> not practical)
2 Likes
I didn’t call it an atomic part, but I believe this is what I was showing in this video? It’s on the older version of KiCad, but should still be valid:
I agree that I prefer not to make atomic components because of the work required.
3 Likes
Components with pre-assigned footprints and part numbers look like this in the latest nightly version, when placing them in EEschema:
So while this visual candy isn’t yet in the stable version, the principle behind it is available since v4 at least.
PS: anything below ‘Datasheet’ field is customizable, so you can use whatever you want.
I went with Manf# and Manf, other people use other designators for other purposes.
There even was some thread around here that tried to work out a common approach/naming scheme for atomic part libraries to make it easier for tools to work with those additional fields (KiCOST for example).
PPS: if you’re on windows and want to try yourself, this is:
Version: (2017-05-12 revision b823d0b78)-makepkg, release build
You can find it here (May-13):
I had it running non-stop for 5 days and can’t fault it yet. Didn’t work in OpenGL canvas though, just Legacy and was hitting [Ctrl]+[S] every other minute just to be sure (old habit)
3 Likes
Can you provide a screen shot for what is seen when selecting a common device part; ie. a resistor or capacitor.
Those are where the parts get overwhelming.
I have one symbol per every part I use at the moment.
There is a more elegant way of doing this with house-part-numbers.
It is more flexible as for parts like this you only have one symbol/component for a series of the same kind, but needs an extra step to get a BOM with order-able numbers.
Depending on your organization (private hobbyist or small company) it might be the better choice anyway.
@Andy_P has described it a couple of times and you’ll run across it when you follow the search for ‘atomic parts’.
You essentially place a generic symbol (for example) 0805, X7R, Kemet, … which has a house part number instead of a manufacturer number and then replace the VAL field with the actual value you want to put in your circuit.
If you then check out the BOM you run it past a script that references the house-part-number AND value field and retrieves the manufacturer part number from a look-up-table,etc…
This way you also can replace parts that are EOL relatively easily for older designs, etc.
I’m a hobbyist/amateur and it’s just me who uses KiCAD anyway atm., so when I created and reworked my libs for the 3rd time 1 year back I opted for the at-first-look ‘easier’ approach of defining the resistors/capacitors I need instead of the house-part-number approach.
I created the libs via python, so in the end I would say the house part number approach even for a single hobbyist use case might be the better way as you spend the time anyway.
PS: problematic on top of all this is the current way the component library framework operates, that’s why I need to have such descriptive component fields.
If the same system was used like what we already have for footprints, where the library is part of the identification, the identifier for those parts could be simpler.
But I defined 0805, 0603 and 0402 size SMD parts, thus their identifiers are so verbose as I couldn’t have 100n for all three sizes in the lib (not to mention further options like material, manufacturer, etc…).
2 Likes
Well this is just tremendous. Thank you guys. Another huge bang for open-source.