search

KiCad / kicad-symbols

Official KiCad schematic symbol libraries for Kicad 5
https://kicad.github.io/symbols
Other
704 stars 745 forks source link

How to name symbols for 'equivalent' parts with different MPNs #2184

Open evanshultz opened 5 years ago

evanshultz commented 5 years ago

Picking off a conversation from https://github.com/KiCad/kicad-website/pull/407 about KLC clause S2.1. I believe the idea was originated at https://github.com/KiCad/kicad-library/issues/1398#issuecomment-316121470. @poeschlr mentioned making an issue for discussion at https://github.com/KiCad/kicad-website/pull/407#discussion_r322583378. Here it is.

The discussion is about naming parts that can be used equivalently but don't share exactly the same MPN. Further complicated if the part comes in multiple packages. The topic is currently covered by KLC S2.1.

My original thought was that rule applies if the suffix for the packaging differs. And only the suffix. If a prefix is missing or changed then it's not as obvious that it's an equivalent part. So MC78 and UA78 and whatever else could be a different symbol than L78*. So to me, the text I submitted at the website PR is more clear and the example works (but maybe there are better ones?).

I have suggested a change to If multiple manufacturers produce equivalent parts where the part number is the same except for the suffix that specifies the package, then the common base part number is kept and suffixed with a simplified footprint name (e.g. L78L05_TO92). Sorry if that sounds self-serving to create this issue.

That was my intent. But it doesn't mean it's the best solution. If the library moves toward being full specified we will then have, for example, MC33078N with an ALIAS of MC33078P and both have a unique entry in the DCM file. I'm not sure if there's a better way.

I always understood KLC as reflective of what is getting merged rather than what is already in the library. Rene certainly has supported changing the "rules" and then accepting PRs based on the change, even if the change was informal (not in KLC). But I do think it's nice to have things documented yet not over-documented.

So... is the existing KLC clause good and salient? Add or remove anything? Change anything?

BTW, no need for cursing here. I'm not trying to beleaguer work being accomplished, especially volunteer work, but trying to find the best solution. And not with malice.

evanshultz commented 5 years ago

Edit: Somehow pressed a keyboard key and submitted this early. Oops.

poeschlr commented 5 years ago

To clarify this is about a subsection of S2.1 that was touched in https://github.com/KiCad/kicad-website/pull/407

The wording before the KLC change:

My original suggested wording:

Wording suggested by evan:

The problem: It seems the example listed (which was one of the original reasons why this rule even exists) would violate the rule by evan (and probably also the original wording)

poeschlr commented 5 years ago

And maybe stating the obvious: If the current wording is kept (yes it got merged) then we have quite a few symbols to rename for v6.

And if we already go this far why not get rid of this exception as it only creates more work for us and is not really well liked anyways.

evanshultz commented 5 years ago

I think we're on the same page that this is hacky and it would be nice if we found a better way. I noted a fully-defined example above where we could use an ALIAS to capture two identical PNs. Kind annoying to have to maintain two identical DCM entries, but this doesn't happen often and fully-specified may be the best method for KiCad library users. Food for thought...

chschlue commented 5 years ago

The discussion from https://github.com/KiCad/kicad-website/pull/407 has shown (I think) that narrowing the exception down to just suffixes makes it basically useless because it would only apply to a handful of parts (e.g. 6N137). Broadening it to "base MPNs" makes it wishy-washy because it is not always clear what the easily recognizable "base MPN" is supposed to be when prefixes and possibly more differ. It seems to me that going with aliases and actual package suffixes makes everything cleaner and clearer.

Some examples:

Current symbol: L78L05_TO92 (ST prefix but covers ON, TI and many more) Alternative: L78L05xxZ (ST), alias MC78L05xxP (ON), alias UA78L05xxLP (TI), more as required

Current symbol: 6N137 (no suffix, alias of HCPL-261A, specified for DIP-8) Alternative: 6N137 (Vishay, Broadcom), alias 6N137xM (ON)

Current symbol: 74HC04 (generic) Alternative (SOIC-14): 74HC04D (Nexperia), alias MC74HC04AD (ON), alias SN74HC04D (TI)

Pro: Rule is always clear

Con: Package suffixes might conflict A lot of work

Edit: Would be easier with a future lib format supporting optional inheritance (FP, DS link, description).

poeschlr commented 5 years ago

The logic libs (your 74HC04 example) do not have footprints assigned so they are considered generic symbols and are not covered by this rule for this reason.

We can make the fully specified but well lets say i am not optimistic that we will find a volunteer for this thankless task (we could not even find enough manpower for fixing the hidden power pin problem)

chschlue commented 5 years ago

I know it's probably not going to happen soon, but all the parts covered by S2.1.3 and by my examples are basically generic (in that they have several manufactures using the same "base MPN"), so my suggestions would mean fewer rules and, more importantly, fewer exceptions. Or is there a particular reason for keeping generic libs at all, except for the lack of manpower?

poeschlr commented 5 years ago

We will always have some generic libs where it makes sense. Connectors for example make no sense to be made fully specified. Same with standard passives.

Edit: we are also currently looking into allowing easier more generic button/switches and relays.

chschlue commented 5 years ago

I thought the context implied we're talking about ICs here. And in that realm, I fail to see the real difference between 4000 series, 7400 series, 78/79xx regulators, "generic" op amps and so on.