If you’re designing something to be manufactured, sure. But this is a one-off thing to fix an annoyance with a vintage computer I own. I could indeed order that exact part from Digikey for almost $30, but that would increase the cost of the board more than five-fold compared to just using one of the cheap Chinese TEXTool knock-offs kicking around in my parts bin. (And yes, it’s possible that this footprint won’t work with the cheap knock-off part, but I expect it will be just fine. And no, it’s not KiCad’s problem if that footprint doesn’t work, it’s mine; I’ll just have to get out the calipers and edit the footprint myself. Or spend $30.)
3 Likes
Ok, but what you’re proposing is a quick hack workaround - making this change wouldn’t have guaranteed you didn’t make this error, only properly verifying your footprints will do that.
1 Like
I just grabbed a Textool zif socket from my components boxes: pins are 0.77mm x 0.32mm, so will fit a 1mm hole easily! (I bought these ZIP skts to be able to quickly change PIC chips for software testing… normally the chips just get soldered into the PCB, and mine didn’t fit the PCB, so I bodged it by soldering on some long pins that DID fit the PCB! This was a 1-off situation)
I made some PCBs using some PCB mounted RCA/phono sockets (which needed a custom footprint creating), first thing I did was buy some, so I could double check the dimensions! I often take a standard footprint and tweak hole sizes or pad sizes, to meet MY needs.
It is the job of the engineer to double-check all dimensions for a job, never assume, others make mistakes.
1 Like
In which case I reckon approximately 100% of engineers do not “do their job.” When you built your board, did you manually measure every. single. component yourself and compare those measurements against the footprints before you sent your board to the fab? Or did you just pick the components that seemed most likely to have issues (such as your RCA jacks) and just measure those?
But this is getting well away from the point of this thread which, if you read my response analysing what went wrong, is this:
Is it correct and desired that, when you select a component using a DIP-24W socket, and look at the footprints that can be used with it, KiCad should by default not show the ZIF socket footprints that can be used with it? If so, why? (This is a serious question: I can imagine that there are reasonable reasons that this might not be fixed.)
1 Like
Yes, you actually do that. Except your company likely maintains a database of verified parts (or pays for access to such a database), so you don’t have to do it every time.
EDIT: and no, you usually don’t physically measure components but rather consult the manufacturers mechanical drawing.
This is quite often not the task of an engineer, but it is quite common that larger companies have people whose job it is to maintain & extend the libraries that are used in PCB design, as halachal already mentioned, and the engineers only use verified parts that are in the database. If an engineer wants to use a new part, then it first has to go though the verification process. How formal and extensive this verification step is depends on the company, but it may very well extend to verifying dimensions on 3D models too.
In smaller companies the process is often less formal, but the complexity of the projects and the cost of mistakes are bigger drivers for deciding on the procedures. On a hobby level, something like the test fitting below is often sufficient. And I do this for all parts where there is a suspicion it’s not perfect.
Hole size errors are probably one of the most common mistakes, and many hobbyists will probably get bitten by that.
1 Like
Not for “standard” 0603, 0402 type components, but for more complex packages yes I check and make my own if I’m not happy with the KiCad supplied match . . . some recent examples:
1 Like
When you built your board, did you manually measure every. single. component yourself and compare those measurements against the footprints before you sent your board to the fab?
Very fair comment.
My first PCB was fairly simple (just looking at it now, from 2018!): it did use a relay that I needed to create a custom footprint for, but the pin-size was pretty normal, but I definitely double checked it all. I also had some ‘molex pins’, and it looks like I made the holes plenty big enough for them!
Having made that first board, I learned a lot: some hole sizes were rather bigger (eg on transistors) than needed, so they got reduced. The biggest thing I learned was that, for hand-soldering, you need slightly larger pads than for automated soldering, especially on things like the standard resistor and capacitor footprints.
I’m lucky in that, historically (in the early 80s) I was a hardware designer, and used to chat to the guy who laid out our PCBs (using tapes etc!), so I probably picked up a few useful tips along the way. I’m also old enough to have had other (non-PCB) things fail due to silly mistakes, so I’m definitely a believer in “measure twice, cut once”.
1 Like
In which case I reckon approximately 100% of engineers do not “do their job.” When you built your board, did you manually measure every. single. component yourself and compare those measurements against the footprints before you sent your board to the fab?
Well, I do look up all components datasheets, dry test on laser cut stencils things I happen to have at hand, to verify assembly of other tings too like is the case in my way etc. I try to do this at least to the parts i must assemble myself. Its fairly commotion that whatever footprint i have don’t match what i need. I mean i don’t measure standard surface mount 0603, 0402, nor any trough hole resistors off course. But have tested the footprints before.
Sometimes i don’t test because there is no time, however i do note this in my notes. So i am fine with errors that come my way this way, or if i really must be sure. I send then measure and send again.
Name of the game, quite much, is avoiding stupid mistakes. But yes I am to blame for every and all mistakes, even if they are not something I could account for.
Note: I don’t think its out of the question to change the standard library footprints (I have corrected clearly wrong text). But you can do that in gitlab, open issue, then fork and ask for merge. You don’t need to have a conversation on this forum about it. Though in this case it still was useful to check your mistakes.
Yes, I absolutely do need to have a conversation about it, for at least two good reasons.
-
There are at least two obvious solutions to the problem I described above (change footprint names or change footprint filters), and possibly more. I can’t see which one would be better.
-
There may be further solutions, or reasons that neither of the solutions above should be implemented. I have little or no idea why the footprint filters are that way, nor why the ZIF names are that way; that indicates that I should be seeking to learn, not proposing arbitrary changes that are likely to waste the time of both me and the KiCad maintainers.
I notice that you have not made any attempt to address the problem that this thread is really about. I don’t know if that’s because you’re as ignorant as I am or whether you feel it’s just too obvious, but if it’s the latter, please provide an explanation of what’s going on with those footprint names and filters (even if it’s just, “Yeah, it’s something we did without too much thought at some point”) and what the correct solution to this is.
Yes but you should have this discussion with the library team. Discussing here just talking to users. If you want to do a change you need to open up a ticket in the library issues database.
I don’t think changing footprint names is feasible, because that would break it for all users who are currently using the library. Changing filters is pretty low hanging fruit that does not impact as much as changing names does.
Personally i don’t think the library needs to be changed, but it certainly can be. Just do it, the library team will then either consider it or shoot it down. Its not really using much of anybody’s time if you did all the work and wrote the explanation.
I am getting confused now. So what is this thread all about?
Best I understand it, you were looking for ZIF sockets in the Package_DIP library, and that is not where they are. They are in the Socket library.
To me it looks like a simple user error of a wrong search, but maybe I missed something, I easily get lost when threads become as long as this one.
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.
1 Like
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)
