What schematic component should I use for “pin headers?”
There are various kinds of headers; traditional 100 mil headers; 2mm headers; 50 mil headers, etc.
They are not “connectors” really, but they’re also not “screw terminals” (because there are also screw terminals, for real!)
5 Likes
Depends on what you want to achieve.
The simple option is to use the kicad suplied conn_MMxNN (where MM is the number of rows and NN is the number of pins per row. Both with leading zero of number < 10)
But if you want something else you might need to create your own library.
Especially if you want to have some sort of material management included in kicad, so called fully specified symbols might be what you want.
(This are symbols where the footprint is already connected to them. They also contain additional information like partnumbers, order numbers, …)
This of course means you need one symbol per part type.
8 Likes
The trick turns out to be to search for “CONN_” rather than “header” or “hdr” or “pin header”
It is fairly common to call these headers “pin headers” so I think it would be useful to add those words to the description in the library! I notice someone else thought that wasn’t needed in the past, but there’s multiple people confused about this trying to move to KiCad from other packages, so I think it would be valuable.
Especially now that Autodesk bought Eagle and turned off the pay-once ability and removed the “Maker” edition, KiCad has a huge opportunity to capture disenfranchized Eagle users!
6 Likes
Kicad has a quite unique idea of how to manage a library.
In kicad you have symbols which are an abstract representation of the parts function. (not of the part! only its function)
The footprint is what creates the connection to reality. (but it again does not hold ordering information or something similar.)
There is no requirement of a connection between symbols and footprints.
You can connect them in your library or you can run cvpcb or you can do it per symbol in the schematic editor.
In eagle there is the idea of a part. This entity connects footprints to symbols and holds stuff like ordering information. (It is an abstraction of the complete component. not only of its function.)
The kicad way has his advatages:
You don’t need the same symbol or footprint stored more than once.
My eagle library had many ic footprints stored in multiple libraries. If i find out that this footprint makes problems in my production process, i need to change all of them separately. (What if i forget one?)
Yes it is different. I’m not sure it’s really worse.
By the way: What i tried to communicate above is that you can recreate the eagle way in kicad.
But don’t expect the library maintainers to maintain such a big library.
If you want a library of fully specified symbols you can create it quite easily from the symbols and footprints supplied with kicad.
4 Likes
DigiKey lists them under Connectors, Interconnects
RSonline lists them under Connectors
Element14 lists them under Connectors
…
Also, as has been said KiCAD (or better the libraries that it ‘ships’ with) doesn’t know about parts.
There is no pre-defined connection between a schematic symbol (component) and a footprint.
If one wants that he has to do it himself for his local libraries.
2 Likes
I understand the KiCad separation, and I even think it’s pretty good. (I don’t want to draw out yet another SOIC-8 footprint for adding yet another MOSFET part – much better to associate with a footprint I already know!)
I also understand that “connector” is one of the commonly used terms for these devices – no complaint from me there.
All I’m saying is that many people think of these, and search for these as “pin headers” so it would be very helpful to add the words “pin header” to the description of these parts. That’s not a particularly hard ask, and it will solve this problem to everybody’s satisfaction.
If you search the forums (which I should have done before posting; shame on me!) then you will see that I’m not alone in this, and assuming that most people DO search the forums, we have a significant under-count in the number of people who have this quesiton.
I honestly don’t understand what the pushback is against making the product better for people who transfer in? It doesn’t make it worse for anyone else.
2 Likes
First, the schematic and electrical function of all of those headers are the same (unless you use grounded sheath/shroud) so that’s fine. Searching for “header” will find the right (or “a good”) schematic element.
Second, are you seriously suggesting that “pin header” is as uncommon a name as “berg sticks”? There actually exist a spectrum of commonality, and my experience (based on a bunch of sources, including common places like Sparkfun and Pololu, as well as making boards in China and selling on Amazon, as well as using other tools) is that “pin header” is very common.
But, you know, if you don’t think that matters, feel free for you to not implement that change. Someone else might think it actually does matter what the onboarding experience is for new users, and might fix it. That’s my hope.
And, really, think about it: I found the alternative, and now have “learned how it’s done,” so I don’t really need to be invested in this, except as feedback from a new user for what can make the product better. This kind of feedback only comes once per person, and is highly valued in product development disciplines. I’m contributing because I actually think it’s worth doing so, even though I already “solved my problem.”
You seem to be approaching KiCad as a corporate product, and this forum as some sort of official support for a corporate product. I guess people fall into paradigms they are familiar with, even if that is not appropriate. Open Source software projects like KiCad are quite different. To be fair, a lot of people fall into the same trap, including myself.
If you want to see KiCad improved, raise an issue, in the case of library components here https://github.com/KiCad/kicad-library/issues
1 Like
Professional users will have enough experience that they WANT to run their company libraries, which are validated and tested.
And they will want to use the BOM functionality of KiCAD which straight away NEEDS atomic parts - this means components will have a footprint + ID assigned and stand for EXACTLY ONE device.
They will never touch the KiCAD libs - maybe as a start to create their own - but that’s it. Anything else would be very unprofessional and way too risky.
Hobbyists will be using the KiCAD libs as they offer time saving (an individual is not a company) and will be happy to assign footprints after drawing the schematic.
For this group pin headers aren’t appearing before they look for the footprint.
And their workflow also doesn’t include pin headers straight away.
But if you would check the actual symbol definitions inside the lib files you’d find that pin headers are one of the suggested footprints for CONN_??x?? components.
And as @bobc has pointed out, all that would be missing was an alias entry in the dcm-file to include your desire… but you’d have to talk to the librarians.
We’re open source support here mostly.
I agree that would be helpful. It’s not a complete solution to the problem, because “header” still covers a wide range of items.
Dale
1 Like
I am not viewing KiCad as a corporate product (we have Autodesk, Altium, and the rest for that.)
I am assuming that KiCad, as a community, wants to make onboarding of new users who may have used other products or come from various other communities, as snag-free as possible. To do that, I apply the experience I have with product development, both professional, hobbyist, and open source, to talk about what can help achieve that goal.
In this discussion, I realize that I forgot to ask those arguing against adding a common alias to the description of a schematic symbol, for why they are against that. Clearly, there are benefits from changing it, but what’s the draw-back? Is more words in the description field a cost that will matter to someone? Is making the pull request the main problem? Is there some religious aversion to the particular term “pin headers”? (Which, btw, is widely used in places like Arduino, SparkFun, Seeed, Adafruit, and so on.)
library team didn’t choose your favorite doesn’t mean that their work is not worthless
Why are you trying to twist my words to imply that I believe the work of the library team is worthless? All I’m doing is trying to help them make the library even better.
Thanks for the kicad-libraries link, I find it very helpful!
1 Like
No problem, you’re just barking up the wrong tree.
We’re supporting KiCAD here, we’re not the librarians (even if some of them post here - don’t think I’ve seen one in this thread yet though).
All other rumblings of us (at least of me) had been about them not being ‘connectors really’ from your POV and me not being able to let it stand like that - as the whole world seems to be of different opinion 
So yeah, I’m with @Andy_P there, I don’t care either way if the keywords get added or not. But good for you if it helps you and others.
Try finding parts that come under the “pin header” or “socket strip” description in the RS or Element14 catalogues. They are all over the place due to different manufacturers opinions.
Yes, and because there are different words from different groups, that’s why it’s important to get the most common names in the description (see patch.)
I’ll totaly yield that yes, pin headers are a subclass of connectors! That’s not what I meant to say with that comment. Sorry about causing consternation with that.
Finally: “we are not the librarians” – as a newcomer to KiCad, that’s not something I intuitively know, and I didn’t see any section of this website that says “post requests for improvements to libraries here.”
If you think “KiCad Libraries” is a totally different thing from “KiCad Software,” then that may be an accurate description of the current world, but that would be a state of the world that most people in the world wouldn’t know, and it certainly wasn’t obvious to me! So, another thing that might be improved in communications …
(Why is it always the case that writing the code is the easy part, and making sure all involved human beings understand each other is the hard part?)
The symbols for connectors (Conn_AAxBB) in the conn.lib library are not “for” headers, or IDC connectors, or what-have-you. They are for connectors, in the general sense. You can assign them to footprints for any of the above or many other footprints.
Adding the “header” keyword to the connector symbols has value, especially as this question has come up a lot recently. I see that someone has made a PR requesting this.
There are too many product specific names for these connectors when these symbols are designed to be generic.
I stand corrected, now we had a post by a librarian… *runs*
1 Like
Y’all just got told!
Seriously though, this is all good user feedback. It is informative to know how people are using the libs and what they expect from them.
1 Like
Generally the two or more column connectors could do with a few more numbering options.
I have seen:
1 4
2 5
3 6
or
1 6
2 5
3 4
or
1 2
3 4
5 6
or
1a 1b
2a 2b
3a 3b
all used by different manufactures and I always prefer to follow any scheme printed on the connector