Shrouded, latched IDC headers

[evanshultz]

As I've threatened to do before, here are these IDC headers which are missing or outdated in our current library. The most recent threat was posted at pointhi/kicad-footprint-generator#134. Footprint dimensional info is at https://docs.google.com/spreadsheets/d/16SsEcesNF15N3Lb4niX7dcUr-NY5_MFPQhobNuNppn4/edit#gid=0.

Here are the varieties:

• Vertical no latch
• Vertical no latch with mounting hole
• Vertical latching in these latch flavors: 12mm, 9.5mm, 6.5mm, none
• Vertical latching with mounting hole in these latch flavors: 12mm, 9.5mm, 6.5mm, none
• Horizontal no latch
• Horizontal latching (latches in open position aren't shown because it's assumed they're off board)
• Horizontal latching with mounting holes

Here are images of 2x5, 2x13, and 2x32 footprints in all flavors (2x5 and 2x13 horizontal latching with mounting hole at the bottom):

Some questions:

1. Is the footprint name proper? Specifically the Latch section.
2. Is the size and naming of the mounting hole versions as desired?
3. Is the courtyard acceptable as a rectangle around the latches? Should the courtyard NOT include the latches since those do not touch the board and small parts can live on the PCB under the latches?
4. Can/should these eventually replace the footprints at https://github.com/KiCad/kicad-footprints/tree/master/Connector_Multicomp.pretty? I think these are better versions with a newer script. What about https://github.com/KiCad/kicad-footprints/tree/master/Connector_IDC.pretty? I've replaced and expanded on the footprints here, and I never found a script for these. In some cases, the footprint names are identical to existing IDC footprints and those cases footprint is extremely similar and, I think, interchangeable for this generic footprint. I propose those two libraries have all footprints copied to an archive location whenever this is merged, not waiting for any KiCad release, and overwrite any conflicting footprints so that users can take advantage of the new footprints if the names match but they don't lose any existing footprints. Then near v6's release the old footprints are removed and only the archive copy remains so users of v6 will only have the new footprints with one naming convention.
5. Are the pin 1 silk and fab marks good?
6. Should the notch for polarization with the mating connector be a "U" shape instead of two lines all the way across the body on the horizontal one to better reflect the real part? For the latching horizontal, should I add a notch lines?
7. Some of these footprints have mounting screws. I used the same size pad on all layers even though the screw head is only on one side of the board. Should the mounting screws have big pads next to the screw head but small pads on all other layers?
8. The existing horizontal latching footprints have small mounting holes which are much smaller than screw heads. Mine are bigger and that prevents the user from putting traces under the screw head or adding some manual method to capture this area (could be a bigger pad or a keepout). Are smaller pads desirable for some reason I haven't thought of?
9. Edit: This is only if the above is true. Should the horizontal latching footprints have the 4-sided diamond-like shape around the mounting holes? The existing IDC footprints have it but I didn't add it in my script since I didn't feel it had value.

Script PR: pointhi/kicad-footprint-generator#387
After taking a look at https://github.com/pointhi/kicad-footprint-generator/tree/master/scripts/Connector_PinSocket, I decided to make my life easy and base this on https://github.com/pointhi/kicad-footprint-generator/tree/master/scripts/pin-headers_socket-strips (using functions in https://github.com/pointhi/kicad-footprint-generator/blob/master/scripts/tools/footprint_scripts_pin_headers.py). Once I got in there, though, I realized that this script was outdated. So maybe it was a mistake on my part and didn't make my life easy. I could use the newer script and figure it out if required.

Edit 14 May: Major code update and some items above removed or changed.
Edit 17 May: Support non-latching vertical headers and suggested replacing the existing IDC footprints.
Edit 20 May: Support horizontal no-latch headers and fix a footprint name clobbering issue.
Edit2 20 May: Support latching horizontal connectors.
Edit 21 May: Minor code cleanup and improvements.

---

All contributions to the kicad library must follow the KiCad library convention

Thanks for creating a pull request to contribute to the KiCad libraries! To speed up integration of your PR, please check the following items:

• Provide a URL to a datasheet for the footprint(s) you are contributing
• An example screenshot image is very helpful
• If there are matching symbol or 3D model pull requests, provide link(s) as appropriate
• Check the output of the Travis automated check scripts - fix any errors as required
• Give a reason behind any intentional library convention rule violation.

[herostrat]

I am just skimming through your comments and compiled data.

First some thoughts:

• I agree that this should be in a generic library, the existing one (Multicomb) should then move to obsolete as they are replaced
• I could not find any errors in your research (yet)

Your questions:

1. I have not heard PinHeaderShroud before, for me they always were called IDC header. I think IDC should be mentioned somewhere (the tags?). I agree with Latch naming.

2. The mounting holes should not be connected to any net, and therefore I agree with the empty name. The size of the mounting hole is adequate. If it is mounted in the fashion that is recommended e.g. in the 3m version, the spae for the washer should be reserved to avoid damage to traces.

3. Imho the courtyard should be the way it is now, although the latches will not bend down to the board. BUT high components, e.g. caps will be in the way. Better to trow an DRC error to much than to not. If the designer sees the error he/she can validate if there is enough space and ignore the error.

4. Yes.

[evanshultz]

@herostrat
Thanks for looking!

1. Yes, "IDC" is the term I'm familiar with as well. Digikey uses "Rectangular Connectors - Headers, Male Pins" and the number of walls is specified, Mouser put them in "Headers & Wire Housings", and Farnell doesn't seem to have an especially specific category for them. I would suggest HeaderIDC_*?
2. Or... what if the mounting holes are desired but the user doesn't want an 8mm+ hole in the board copper? In that case, the mounting holes should be named MP (right?). I didn't think of that. This option is easy to add to the script if it's desirable.

[evanshultz]

1. I had forgotten about https://github.com/KiCad/kicad-footprints/tree/master/Connector_IDC.pretty. With some expansion, this script can replace all these footprints. Should I also adopt the naming system used there?

[evanshultz]

Just pushed a commit to my branch above that supports the non-latch vertical headers. Next are the horizontal non-latch ones...

[evanshultz]

Pushed another commit to add the no-latch horizontal headers.

Last is the horizontal headers with latches.

[evanshultz]

I've pushed an initial commit to my script that adds the horizontal latching connector footprints. I need to do a bit more review before I add the connector footprints to this PR.

[evanshultz]

More review and code improvements in the last script commit. Things are looking good, I believe. Only missing feature I'm aware of is silk clipping around mounting hole pads.

[evanshultz]

Ready for review!

Please look at the questions above and add onto the conversation about them. Some footprints are replaced with nicer versions and others are totally new.

There are two items to note from Travis:

1. 3D model mismatch: This is desirable because the presence of mounting holes on the PCB doesn't affect the component model.
2. Overlapping elements: There is something wrong with the algorithm reporting this check because there are no overlapping elements.

Note that I abandoned footprints with mounting holes which aren't already in the library. Our current tools for detecting clipping lines is too basic for what I need here, and if we're to support more advanced clipping I think we should integrate an external module which is broadly tested rather than develop more complex home-brew solutions. I'm happy to accept suggestions and make fixes on the footprints here but I do not want to pollute this PR with discussion adding more footprints with mounting holes. So please make a new issue for that topic if you want to bring it up.

[evanshultz]

For connectors which have been "replaced" (even if the name has changed, such as "lock" to "latch", it may be a replacement), a comparison would be nice. Here you go using a 2x5 footprint as an example (old is always on the left):

In the last one I noted that some connectors are slightly wider than the existing footprint, so made it slightly taller (in the orientation shown above) for better compatibility and kept the original dimensions otherwise.

[cpresser]

2. Overlapping elements: There is something wrong with the algorithm reporting this check because there are no overlapping elements.

I looked into this and found overlapping elements:
In the Silk-Layer its basically the same, two lines exactly on top of each other.

So I don't think its a false positive.

[evanshultz]

@cpresser
It appears only the *Latch_Vertical footprints had this issue. Thanks for catching that!

With the known error in the script (at the time I pushed my commit, now fixed) I didn't see my mistake earlier. I figured out what was going on and fixed it. CI is all green now.

Do you see anything else?

[cpresser]

Do you see anything else?

I did not do a review when I looked at this the first time. I was just interested to see if the travis scripts have a false positive.
I can do a full review, but I wanna handle some other issues first. If its not urgent feel free to assign me to this one. I will work on it soon-ish :)

[evanshultz]

Add vertical mounting hole footprints that were missing (and some old footprints existed which would not have been replaced). Representative screenshots added as the 3rd screenshot in the first comment.

[cpresser]

Regarding your research I found DIN-EN-60603-13 (replacing the older DIN-41651) which covers those shrouded headers. I am not sure if you are/were aware of that standard. Anyway, now you are for sure.

I did take a quick lock inside and it has measurements for shrouded connectors with locking, horizontal and vertical. It also contains a naming scheme.

[poeschlr]

Also regarding the mounting pin stuff, look at the molex picoblade connectors. These are examples of parts with numbered mounting pads. I would not add a full suffix to be honest but would not be opposed to it if you think it increases clarity.

[evanshultz]

@poeschlr
Thank you.

I think the naming convention is the same with -1MP in the same place as those connectors even if there are multiple MP pads. And I don't feel the suffix adds anything either. So hopefully all good.

[poeschlr]

By the way, the reason i assigned this to me is such that it has a higher priority than most other pull requests (in most review sessions i start with the stuff assigned to me) However i forgot to mark this as ready for review which is why i kind of overlooked it.

I am not opposed to some other maintainer taking this on by the way. This is true for any pull request that i assigned to me.

[evanshultz]

Out of curiosity, what made this PR "higher priority"?

[poeschlr]

It has high priority for me for the following reasons:

• I used similar footprints quite often and it was quite annoying to make them myself.
• I had plans to make scripted versions for these for quite some time but never got around to doing it
• It is made by a librarian so i suspect less work for the review (effort to payoff is huge)
• It is scripted which further improves the effort to payoff factor

[poeschlr]

It might be a good idea to include a link to your research document in the documentation field.
Or alternatively one of the datasheets for a fitting part but with a mention that it is only an example.

---

my keyboard just broke so i can not really continue today. (software keyboard is ok for typing but not for librecad)

[evanshultz]

OK. Done.

Sorry about your keyboard. It seems like that kind of thing always happens to me right when it's most annoying...

[poeschlr]

The horizontal and vertical versions seem to require a different mounting hole distance (Example [3m datasheet](https://multimedia.3m.com/mws/media/22448O/3m-four-wall-header-3000-series-100-x-100-ts-0772.pdf Same with latcon) dim A vs dim B) but your footprints use the same for both.
This seems to be done to allow the same tooling to produce the body for both versions.

I checked the vertical version against your document and a few measurements do not agree with what you wrote you will aim for. (shown in orange)

[evanshultz]

I don't see the first issue. This is the mh_overlen variable in make_idc_headers.py and it is correct. Line 46 is 8.94mm above pin 1 for vertical and line 73 is 5.905mm above pin 1 for horizontal. I checked the generated footprints and they're correct. This in the spreadsheet cell C15 where I just updated 42.2mm to 42.29mm to match the footprints.

The 1mm drill is because I generally used the 3M datasheet, but it says 0.89mm drills. Other datasheets ranged to 1.02mm. I picked 1mm to be a bit in the middle. Changed cells C9 and C27 to 1mm.

For the 52.42mm, this is because the height of the body above pin 1 varies a bit depending on pin count. Instead of tweaking it for each pin count, I picked the mean value which is 10.97mm and so there was a 0.02mm error from the value in cell C6. I updated that cell.

And finally the 48.36mm was similar to the above, where I started out comparing the 26-pin header but then found that might not be the mean value for the whole family as I checked out the scripts. I edited the value in cell C11.

I think all of these were because I started from the spreadsheet but then dialed things in once I started reviewing the script output. And I never went back and updated the spreadsheet. Sorry for that since it ended up being misleading. The spreadsheet should now reflect the refining I've done with the script to things are in sync.

[poeschlr]

Damn you are right the mounting pad distance is indeed different for horizontal and vertical footprints. I somehow misremembered this from my first review.

I am satisfied with your remaining explanations so this is now good to go. Thanks for your great work.

[chschlue]

https://lists.launchpad.net/kicad-developers/msg43785.html

Changing fp-lib-table was forgotten here.

[evanshultz]

I think fp-lib-table is OK. It still lists Connector_Multicomp, which I intended as to not break things (apparently that didn't work, though...), and the new footprints added here went into the existing Connector_IDC library.

I retained README.md in Connector_Multicomp so that the folder wasn't totally empty as I recalled that any file (even just a text file and not a single footprint) in the library prevented issues. I didn't and still don't have any problems launching and using Pcbnew or Fpedit with master.

@poeschlr
Do you want to restore all the old Connector_Multicomp footprints? Or something else?

[chschlue]

Actually, I'm not sure what the fuss is about.
We generally do not regard FP changes as breaking because users actively have to update FPs on their boards from the lib to actually break anything and I don't see what we broke here.

But leaving Connector_Multicomp in fp-lib-table doesn't really make sense to me, I'm with Carsten Schönert on that.
When upgrading your installation to 5.1.6, your local fp-lib-table stays the same (including the almost empty Multicomp lib and libedit doesn't complain because the readme is in there). When freshly installing, a reference to obsolete Multicomp from our fp-lib-table gets copied to the users' local tables. What is that good for?

[evanshultz]

I should probably look this up instead of going by memory, but I recall that if a library (.pretty folder) is removed but lib-fp-table points to that library then there is trouble. That seems obvious.

The issue is that lib-fp-table is maintained here as part of the library and we manually keep it in sync but there is no connection between the table and the actual libraries which leads to:

1. Things can get out-of-sync for users during KiCad installation depending on the installer (lite or full) and their particular setup (clean install or overwrite).
2. If they library is updated routinely, like from GH or the website, library folders could be added or removed but that won't change fp-lib-table.

https://bugs.launchpad.net/kicad/+bug/1820305 (now https://gitlab.com/kicad/code/kicad/-/issues/2360) was supposed to cover this issue. It is silly to have an empty library but we only control the library folders and so I don't see another option without some changes to KiCad's behavior.

Having a totally empty folder or no folder was an issue, I recall, but having even a text file was not a problem. And when I tried that (updating the readme file to be helpful) I didn't find any issues either when working on this PR. And I still don't.

There's something we're seemingly both missing.

[chschlue]

Having a totally empty folder or no folder was an issue, I recall, but having even a text file was not a problem. And when I tried that (updating the readme file to be helpful) I didn't find any issues either when working on this PR. And I still don't.

Same here. I'm not questioning the folder (and the readme), I'm only wondering whether leaving the table entry does any good (though it doesn't hurt much, either).