Closed evanshultz closed 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?
I don't mind it is double, better to stick to convention than create exceptions
Large reorgs might best be left for about half a year before the planned v6 feature freeze.
@poeschlr Understood. There are two items I'm wondering if they should/could be done soon:
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.)
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?
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.
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.
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 beforeMPN
. Neither field is optional. This can result in text forSeries
and the same text again inMPN
; 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](https://user-images.githubusercontent.com/1936989/49164836-d6557900-f327-11e8-802d-faf66d2b1a9b.png)
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.