c96abc and all other DIN41612 connectors pins dont match sch lib v footprint pin numbers

[achiestdragon]

the pins on the symbol in the schematic are wrong ,, the pin names 1a though 32c thats correct but the pin numbers are numbered a1 though c32 that dont match the footprint numbers that are numbered like the pin names 1a though 32c so none of the pins produce a usable netlist connections

the same problem is also true of all the schematic symbols associated with all the DIN41612 footprints

[antoniovazquezblanco]

Does the standard specify any preference on whether to use letter-first or number-first pin numbering?

[achiestdragon]

actually no , but consistency across the schematic libs/footprint lib's matters , when it comes to net lists

…

On Thu, 22 Nov 2018 at 09:54, Antonio Vazquez ***@***.***> wrote: Does the standard specify any preference on whether to use letter-first or number-first pin numbering? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1157 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEZbtF6V6z0FMCO_v-PzukWeltJgvFuTks5uxnQ6gaJpZM4Yu7UA> .

[antoniovazquezblanco]

Would you please be willing to contribute this issue by elaborating a list of affected symbols or even creating a PR that fixes the issue?

Thank you!

[evanshultz]

I don't think anything needs to be done.

Here are our current footprints:

They are letter-number.

(KiCad/kicad-footprints#1076 will be adding a ton more which are also letter-number.)

The symbol library have both letter-number and number-letter:

So while we provide symbols that don't match with the DIN41612 footprints, this is a convenience for the user if they want to add footprints which are number-letter. I agree that it would be easy to make a mistake since the footprints are only letter-number and the user needs to pick the right symbol to make them match with our DIN41612 footprints, but this report is wrong because there are no specific DIN41612 symbols and the symbols needed to match our DIN41612 footprints are provided.

If there is no action on this soon I think it can be closed.

[achiestdragon]

on the other footprints for the 64 ab and 96abc i get as attached dave

On Thu, 22 Nov 2018 at 15:05, evanshultz ***@***.***> wrote: I don't think anything needs to be done. Here are our current footprints: [image: image] <https://user-images.githubusercontent.com/1936989/48910194-2b732580-ee24-11e8-890f-d737e404ffb9.png> They are letter-number. (KiCad/kicad-footprints#1076 <KiCad/kicad-footprints#1076> will be added a ton more which are also letter-number.) The symbol library have both letter-number and number-letter: [image: image] <https://user-images.githubusercontent.com/1936989/48910339-89a00880-ee24-11e8-8f9a-e02c974e52d7.png> So while we provide symbols that don't match with the DIN41612 footprints, this is a convenience for the user if they want to add footprints which are number-letter. I agree that it would be easy to make a mistake since the footprints are only letter-number and the user needs to pick the right symbol to make them match with our DIN41612 footprints, but this report is wrong because there are no specific DIN41612 symbols and the symbols needed to match our DIN41612 footprints are provided. If there is no action on this soon I think it can be closed. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1157 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEZbtP8B2ahzVlR3iwUDKReO_2a-bupQks5uxr05gaJpZM4Yu7UA> .

[test.pdf](https://github.com/KiCad/kicad-symbols/files/2608689/test.pdf)  

[evanshultz]

@achiestdragon
Thanks for the reply.

I see the schematic symbols, but they don't have a footprint assigned.

I'm not seeing these footprints in the current repo. Can you tell me the library where you found those footprints? Also, are your libraries up-to-date? The old Connectors footprint repo (https://github.com/KiCad/Connectors.pretty) had some C96 connectors but they were of low quality and were not ported to the current footprint libraries.

[achiestdragon]

the schematic symbol is in a lib called "Connectors" and the footprint in a lib called Connectors_IEC_DIN as to if the libs are old or not i have no idea , installed from the version in the current suse rpm repositories , there may be old libs from the previous version , i have some schematics that still use them

[evanshultz]

Your libraries are outdated. You can find information on updating them at http://kicad-pcb.org/libraries/download/.

The connector symbol in the current library should be updated to the current, scripted style. And the footprints do not yet exist in the current libraries. Those items will be addressed.

[antoniovazquezblanco]

Please @achiestdragon confirm if @evanshultz has solved your issue and close this if yes.

Thank you!

[achiestdragon]

still the same the new sch libs lable the pins A1 - C32 the old ones a1 to c32 and the footprints in the current libs are still 1a to 32c

[achiestdragon]

New Folder.tar.gz
i moded the 96way verson (should be in the zip but the error still remains in the 64 way and some of the other veriants

[antoniovazquezblanco]

Pin numbering starts with a letter. I don't know if pin numbering is case sensitive. That may be a the problem.

[achiestdragon]

with new libs , , the parts with the lib starting with conn are 2 rows , the ones starting with socket are 3 row shells eather way those parts with footprints conn are letter first , the others are number first , even so there is a lot of mixtures here where the format is inconsistant with others of the same type

[achiestdragon]

bit of clarification on number/letter order ,, according to the manufacturer data http://mdmetric.com/harting/download/catalogueconnectorsdin41612.pdf the pin number format of number then letter in lower case is used on all connectors in this series

[achiestdragon]

saves you reading all the data sheet pdf ,

evanshultz if the difference bettween the footprints labled conn and socket are the old and new libs its fair to point out that they are both different connectors in the same series , the old libs are the ones with a.b.c shells and the others a,b so thay may not be up to your looks spec but are still valid as they have not been replaced , the abc type shells are still availiable and where used on a wide range of systems for expantion ports and still are , they should not be removed just because there not pritty if they are still valid and functional

[evanshultz]

@achiestdragon
So I believe the scope of this is only for the 96-pin schematic symbol which is not scripted and thus not included in the newer schematic symbols. Yes?

It is not a given that the datasheet from a vendor matches the actual DIN spec. Do you have it? We would probably be best to find out if they go letter-number or number-letter.

[poeschlr]

we might need to add specialized symbols for din connectors to the lib in the long run. There are simply so many variations of connectors out there that are called din which makes it impossible to create generic symbols fitting all of them. (There are parts with missing pins like the one shown here. There are parts that mix signal and power pins, two row, three row, three row with a full on missing row, ....)

So my suggestion would be that we start a separate Connector_DIN_IEC symbol library that holds symbols specifically designed to fit footprints in the Connector_DIN_IEC lib. We would then require every contributor adding a part to either of these libs to provide the opposite part as well (meaning if somebody adds a footprint that does not yet fit a symbol than a symbol must be created)

Just be prepared that this lib might get huge over the very long term. I looked a bit into this mess as wayne and i where contacted by somebody from infineon. I tried to find some common scheme opon which we could base a library system. Without access to the full standard we really do not stand a chance here.
One kind of cheaty way out for us would be to ignore that these are (in theory) standardized and simply go with the nomenclature of manufacturers.

---

My reasoning is that it is simply not worth our time trying to save a standard that got seemingly butchered by manufacturers a long time ago.

Just look at these catalogs and try to find a common ground. If they truly follow a standard then this should be easy. (I fear this standard can be compared to the standard about reference designators. Everybody knows there once was a standard. Everybody kind of ignored it. Newer standards only try to document what others did after ignoring the standard. The result is even more confusion.)

• https://b2b.harting.com/files/livebooks/en/PRD0200000100063/downloads/livebook.pdf
• https://www.mouser.com/ds/2/625/ERNI-DIN41612-IEC60603-2-e-364520.pdf
• http://www.erce-sa.com/uploads/elfinder/din_41612.pdf
• https://www.te.com/commerce/DocumentDelivery/DDEController?Action=srchrtrv&DocNm=1-1773725-1_Eurocard_QRG_EN&DocType=DS&DocLang=EN

[poeschlr]

My reasoning for this being a feature request instead of a bug:

• We do not guarantee that the library has symbols or footprints for every part that exists.
• We do not even guarantee that there is a fitting symbol for every footprint or the other way round. (The lib gets better in this regard but we will never give this guarantee.)

Conclusion: The request is to add symbols for parts not yet supported in the library.

My reasoning why invalid is the wrong label:

• There are footprints specifically for these parts already in the lib.
• These footprints are kind of useless without symbols.

[evanshultz]

OK, so let's see what we have and what is needed. I'll address capitalism at the end.

Here is Connector:C64AB (note the pin number is letter/number format), Connector:C64AC, and Connector:C96ABC:

The first one can be replaced by Connector_Generic:Conn_02x32_Row_Letter_First as shown to the right of those three. Note this is in a different library and is much more compact.

The second one could be replaced by a similar connector but replacing the letter b in the pin name with the letter c.

And the last one would need some kind of new symbol. It could either be a big symbol with, say, a and b on the left side and c on the right, or perhaps have a and b on one unit and c on a second unit.

@achiestdragon
Would that resolve your issue?

@poeschlr
Yeah, I was very simple in my question above to try and cut to the answer instead of prolonging discussion. I think a dedicated library would be easiest as well, since that makes it clear the purpose and avoids the user having to choose which letter/number order is required. Plus we can include symbols that match up with the footprints we have (or will soon have, courtesy of KiCad/kicad-footprints#1076) instead of a miasma of uncorrelated symbols. Are you up for enhancing the symbol generator to spit out the new library and add in the three row symbols?

FYI I noticed a typo on line 232 of https://github.com/KiCad/kicad-library-utils/blob/master/schlib/autogen/connector/Connector_generator.py. It's a copy of line 216 and didn't get the words "number" and "letter" flipped.