search

KiCad / kicad-footprints

Official KiCad Footprint Libraries for Kicad version 5
https://kicad.github.io/footprints
Other
617 stars 714 forks source link

Manufacturer-specific connectors with double series name #1141

Closed evanshultz closed 5 years ago

evanshultz commented 5 years ago

Pulled from https://github.com/pointhi/kicad-footprint-generator/pull/224#issuecomment-442506843, which was spawned from https://github.com/KiCad/kicad-footprints/pull/1107.

@SchrodingersGat @poeschlr Some footprints fall into the "Manufacturer Specific Connectors" section of http://kicad-pcb.org/libraries/klc/F3.6/, I believe, where Series comes before MPN. Neither field is optional. This can result in text for Series and the same text again in MPN; this looks weird, especially if the the two pieces of text follow each other, but follows convention. I wonder if we should do something different.

None of the connectors in the Harwin repo have a datasheet or appear to be relatively modern so they don't make a good example, but let's look at the JST repo where I know many of them are recent. They have doubled text to follow KLC: image

That does look a bit bizarre and does not add clarity to me.

This convention, however, works well for Molex (https://github.com/KiCad/kicad-footprints/tree/master/Connector_Molex.pretty) where you have Series names like "CLIK-Mate" and "Micro-Fit_3.0" which are quite distinct from the MPN.

The Samtec repo (https://github.com/KiCad/kicad-footprints/tree/master/Connector_Samtec.pretty) doesn't double text in the scripted LSTM footprint names and I think it's clear.

Should KLC state that the Series field is required only if it is not a substring of the MPN? This would require updating a number of footprint file names if we change existing ones, but we could start a new precedent (perhaps updating all for v6?) to avoid doubled text. I agree that removing one "M20" looks better and doesn't lose anything, but since we're noticing this inconsistency now let's sort it out.

evanshultz commented 5 years ago

@poeschlr @SchrodingersGat (and anybody else @Misca1234 @antoniovazquezblanco @DanSGiesbrecht @myfreescalewebpage ) Thoughts on the above?

If we decide to do any renaming, should that wait until after 5.1? Wait for 6?

What about renaming if the MPN above is in error? For example, ACH headers should start with "BM" but our library shows "BBM". See http://www.jst-mfg.com/product/pdf/eng/eACH.pdf and the screenshot above. Can that be done now or just after 5.1 since it's a bug?

Misca1234 commented 5 years ago

I don't mind it is double, better to stick to convention than create exceptions

poeschlr commented 5 years ago

Large reorgs might best be left for about half a year before the planned v6 feature freeze.

evanshultz commented 5 years ago

@poeschlr Understood. There are two items I'm wondering if they should/could be done soon:

  1. Is the series name always given even if it's in the MPN? This varies in the library now, as noted above, but at least if we decide what to do I can make an issue for existing footprints and we have a direction for new contributions. The inconsistency noted above is against the footprint naming in KLC so I'd like you to clarify your preference.
  2. Correct the footprints that have an error in the MPN. I noted the ACH series above but there may be others.
poeschlr commented 5 years ago

Having the series name duplicated helps with grouping similar parts in the same lib (JST is the best example. Remove the first EH, XH, PH and the series grouping is lost.)

So for consistency and for easier KLC i would prefer the series to always be listed even if the mpn includes it.

The alternative is to specify that the series must be included only if the MPN does not start with the series name. (I would accept this way of doing it as well.)

evanshultz commented 5 years ago

OK. So KLC says always include the series name but you're allowing an alternate to that. Which means the original PR that spawned this line of questioning is OK. And KLC needs an update.

What about the timing of fixing names that truly have an error (wrong MPN) like the ACH series I mentioned above? Now? After 5.1? For 6?

poeschlr commented 5 years ago

True errors can be fixed right now (They are real bugs)

The only thing we should not do is breaking designs just to get KLC compliance.

evanshultz commented 5 years ago

JST MPNs fixes pushed. Script: https://github.com/pointhi/kicad-footprint-generator/pull/256 Footprints: https://github.com/KiCad/kicad-footprints/pull/1238

Since the Harwin M20 series were just merged, would you want to add back the initial M20 even though the part number starts with it? You said you'd accept this above but if you prefer compliance with KLC they haven't been in the library long.