You misunderstand. I was looking in all libraries.
Go back and have a look at my first reply where I have described the problem in detail, asked about the reasoning behind certain naming conventions, and suggested a couple of possible changes (either or both of which may be a good or bad idea; I just don’t know).
a) As well as whatever time it takes from the developers, even if small, it’s using my time on something that may be the wrong thing to do. (As I already pointed out, there are several options available.)
b) I cannot provide an explanation, because I don’t have a deep enough understanding of the naming scheme. Thus my questions above.
None of the library team has answered here and to be honest, in general we the regulars here are more familiar with the KiCad application development process than with the library development process. You should probably file an issue to the libraries’ gitlab issues, KiCad Libraries · GitLab, and ask there.
Librarian here.
I suggest we add “ZIF” to the name or description so that people searching for the term most often used for these will find it.
Fair point. But when I search for ZIF, the search does show some ZIF sockets. So which footprints exactly do you want to change?
You mentioned Package_DIP:DIP-28_W15.24mm_Socket having the description 3M 24-pin zero insertion force socket, through..., but I cannot see that. On a 9.0.3 install the description instead is 28-lead though-hole mounted DIP package, row spacing 15.24mm (600 mils), Socket, and the keywords are THT DIP DIL PDIP 2.54mm 15.24mm 600mil Socket.
The title of this thread is misleading; due to my inexperience the problem is not at all what I thought it was. And I’m still far from a good understanding of How Things Should Work, so do feel free to correct me anywhere I’m going wrong in the following.
I started out looking for a ZIF socket schematic symbol. There isn’t one of those, but I am thinking that that’s actually how it’s supposed to be, because you specify the particular device you want to use (e.g., a 27C64) and whether the socket is standard or ZIF is all about the footprint, not the schematic symbol. (Yeah, duh, obvious to me now.) So being unable to find results for ZIF in a symbol search is not an issue.
When searching all footprints, the ZIF socket show up because, though “ZIF” is not in the name or description, it’s in the keywords field. (When I was having difficulty finding ZIF sockets, I thought only the name and description that were searched; this turns out not to be true.)
So the actual problem I had was as described here: the footprint filter does not match ZIF sockets for the 2764.
Sorry, that was a typo on my part. Best not to look at the head post; that was when I was still very confused. Instead look at the post I linked above, explaining the apparent mismatch between the 2764 footprint filter and the ZIF socket names.
So I understand your proposal is to add the ZIF footprint to the 2764 symbol? So its in the dropdown of the proposed footprints when placing that symbols?
I would rather not do that, because then we have to do that for all kinds of devices that have a DIP footprint. Only changing this on the 2764 EEPROM would be weird. Besides, quite a few devices with ZIF sockets are rather generic, so one could also have a 40-Pin ZIF-Socket to program a 2764. Then the pin-mapping would not match.
At the moment I am not convinced that adding ZIF-footprints to regular symbols is the way to go.
There is indeed no ZIF-Socket symbol. Instead you could use a Conn_02x14_Counter_Clockwise as a generic symbol and then add select the ZIF-footprint for it. KiCad does not stop you to use any symbol with any footprint. This is actually how its supposed to be used.
A lot of the symbols are generic, that means no specific MPN and footprint. You can adjust them to your needs as a designer. Resistors are a good example. We have only one symbol for all possible variations of footprint and value.
Right now I don’t consider your issue as a bug. But learned that there are no symbols for ZIF-Sockets. Having those would have helped you. And would allow for nicer schematics that better communicate the intent. That sure is something we can improve.
Yes, but not to that footprint alone, and definitely not making a special case for that.
Yes, exactly.
Why is that? It seems to me that a ZIF is just another socket that can be used for DIP devices just as any regular socket.
I am not entirely sure that’s what’s necessary, or even a good idea. It definitely wouldn’t have helped me in this case because the particular board in question was designed only for a 2764 and so that’s symbol I used (and the correct symbol to use, I feel); it just happened to use a ZIF instead of a standard socket. Or optionally, really; there’s nothing stopping you from soldering a standard socket in place of the ZIF. The schematic doesn’t care.
Now I do have a board where a I need a 48-pin ZIF socket symbol because it’s got some similarities to an EPROM programmer and is designed to take many different devices in the socket. But this is a strange and complex enough thing that (even as a bit of a noob) I don’t see any real issue with having to make one’s own symbol for this. And I’d imagine a symbol for an actual EPROM programmer (as opposed to my “reconfigurable ROM reader board” would have a rather different pin configuration, anyway.
But there’s another part to my question, too, which might provide some insight ito the problem (or perhaps lack thereof): why does the standard library use “15.24mm” for standard sockets, but just “15.24” for ZIF sockets? Is there reasoning behind that, or was it just an accident, or…?
Recognizing that ZIF’s come in a variety of flavors and they only ‘hold’ Chip’s (no Salsa).
Thus, for me, the most useful way of thinking about them in Symbol’s is as shown below…
I’ve made several Programmers using ZIF’s (and I have a dozen different brands from many years of using them… )
You could simply draw a representative ZIF shape around the Chip and/or place a Screenshot into the Schematic (as shown below)…
Regarding the Width: Except for the inexpensive TexTool Zif’s, all of my other one’s (More expensive brands) have changeable Width (you open it up and rotate the hardware - see image below… the extra Pin-Hole’s)
Exactly as non-ZIF sockets.
Ha! In fact, that’s exactly what I did when I didn’t get a match for ZIF sockets on the 2764. And exactly why I ended up with a board in which I couldn’t put a ZIF socket, because of the hole size difference. Thus this post. :-)
Oh, that’s totally cool. I’m glad to know about that in case I should need it.
But that’s not the width I was talking about. I’m talking about the exact strings “15.24mm” versus “15.24” in KiCad’s footprint names and footprint filters.
That would be silly to even consider… what if some company listed there’s as 15.240 (with or without the Units…? Would you complain about it not having the extra Zero? What if it get’s name info based on actual units and for some reason Brand ‘X’ was 15.241 ?
More importantly, a Kicad experienced user (and I’m talking only 5-minutes experience in using common Search knowledge) would enter useful search info, including the typical Wildcard syntax…
No, I would complain if KiCad did include the extra zero. KiCad’s names are KiCad’s names, designed to work with KiCad’s footprint filters; what the company puts in their data sheets isn’t relevant to that, is it? I think it would make it very hard to build good footprint filters if they didn’t have consistent names.
Well, you’d have to take that up with the librarians; they are the ones who entered the footprint filter, not me.
I am suspecting you might be misperceiving a few things about the issues here; you might find it useful to carefully re-read the post that describes the problem.
I read it and it’s become a useless Saga…
All of the Expensive (high-quality) ZIF’s that I have contain Round Pins of 0.6mm Diameter (look at the photo I posted). Only the Inexpensive TexTool ZIF’s (that I have) use Wider Flat Pin’s.
Professional companies that I’ve worked with and for (I was Engineering Director for JAE and AMP/Tyco, decades ago), for the past 50yrs use good quality stuff, not cheap, Hobby/Common quality…
I think this has run its’ course? Feel free to over ride me if I’m wrong. Most of us recognize the library symbols and footprints as starting points and verify and build personal, trusted libraries from them.
Opened so @cpresser could add a closing comment. Warning, any other comments may be deleted as this was going off the rails.
While I see your point, I don’t fully agree. A ZIF socket usually is a different design intent. But it does not matter to much.
Changing the whole library is a pain. Even though most of it is scripted its not something I am interested in doing.
The library does not aim to be complete or be perfect for all use-cases. We think that matching 80% of all use-cases is perfectly fine. 100% sure is unattainable.
In your specific board, the solution is to exchange the default footprint of your symbol with the one you intended to use.
Fortunately, there is an easy solution
I did some digging and found this PR where those footprints where originally added.
It was suggested to add mm to the footprint name. Most likely its a plain oversight that they did not get added. Fixing the footprint name will make most of the footprint-filters work.
A possible fix is here: Add mm to the footprint name for ZIF DIP sockets (!1835) · Merge requests · KiCad / KiCad Libraries / KiCad Footprint and 3D model Generator · GitLab
Sorry, but I feel this whole mess needs to be put in place before someone starts modifying footprint libraries etc.
This is what I get when I open the footprint library in V8.0.9 and just enter “zif” in the search field:
And guess what? All the holes are 1mm.
I’ll go away now.
But don’t save the original thread for posterity.
