search

KiCad / kicad-library

The schematic and 3D libraries for KiCad 4.0. Note that the footprint libraries are the *.pretty repos themselves. This is an orphaned repo, the news about the v5 libs, http://kicad.org/post/kicad-official-libraries/.
Other
749 stars 953 forks source link

KLC Addition - PWR and GND pins #879

Closed SchrodingersGat closed 7 years ago

SchrodingersGat commented 7 years ago

Nominally we suggest PWR pins are located at the top of a symbol, and GND pins at the bottom. However this is not stated in the KLC rules.

I suggest that rule 3.5 be updated as follows:

Old Rule 3.5

Whenever possible, inputs are on the left and outputs are on the right.

New Rule 3.5

Wherever possible, pins should be arranged by function:
* Power pins should be placed at the top of the symbol
* Ground pins should be placed at the bottom of the symbol
* Inputs should be placed on the left of the symbol
* Outputs should be placed on the right of the symbol
jkriege2 commented 7 years ago

ad 1) yes, that's what the checker does at the moment (although silkscreen can easily be added ;-)

ad 2) ... mmmhhh ... preview images are not possible I pressume?

SchrodingersGat commented 7 years ago

I've managed to get inline images looking pretty nice now actually - what do you think?

jkriege2 commented 7 years ago

awesome ... just the way I imagined it ;-)

jkriege2 commented 7 years ago

I'm thinking that maybe over time, we should assemble a gallery of good footprint-images. AT least, where t makes sense (i.e. IC-packages), so people can have a look when designing a new one ... but that's for future work. Maybe this evening I can have a look at your updated scripts ...

JAN

jkriege2 commented 7 years ago

A suggestion. Now we have:

7.3.x Silkscreen is completely visible after board assembly (should not be under component)

Maybe change to:

7.3.x For SMT components, silkscreen is completely visible after board assembly (should not be under component) 7.3.y For through-hole (THT) components, silkscreen should not be completely covered after assembly, i.e. usually a circumference should stay visible. Silkscreen may also be put under the components to make assembly easier. 7.3.z REFDES on silkscreen must be visible after assembly in all cases.

What do yout hink?

jkriege2 commented 7 years ago

Also maybe change:

7.5.x Clearance is measured from package, pads, and silkscreen

To:

7.5.x Clearance is measured from package- and/or pad-circumpherence (i.e. circumphere these elements with the given clearance)

SchrodingersGat commented 7 years ago

Thanks :)

poeschlr commented 7 years ago

I would also clarify that the silkscreen pin 1 marker is always visible after assembly.

Otherwise great work

SchrodingersGat commented 7 years ago

Thanks @poeschlr , added

evanshultz commented 7 years ago

Sorry if I'm being too pedantic, but a few comments. I haven't looked at this for a while so sorry to drop in so many comments at the 11th hour.

First, I see some bullets with a period at the end and some without. Is there a standard followed in this regard for KLC?

And also, bullets are much harder to mention in particular than a named/numbered scheme. Would it be better to avoid them? If all numbers are used, a specific rule could be "6.4.3.1" instead of "6.4 bullet 3 first sentence", for example.

1.4 Not showing units will affect a lot of current footprints that have mm in them for dimensions. CapacitorsTHT, Connectors, PinHeaders, Sockets, Symbols, Wire, etc. Is there a plan for updating the footprints in this case?

1.6 Is there a better way to word this? I feel it's unclear. Or perhaps it's covered by 4.5?

3 If mm is the standard dimensional unit in KiCad, why not dispense with mil and only use mm? All footprint info is only in mm.

3.1 In the last bullet, diodes are arguably not a passive part since they're semiconductors.

3.2 I feel it reads better as IEC-style symbols are used _whenever_ possible.

3.4 UART and RS232 are both bidirectional, so it seems odd to include one as an example of input pins and another as an example of output pins. Am I misunderstanding?

3.6 Should it mention not to stack NC pins? Or not to stack any pins, for that matter. See #849.

3.9 For parts with a single package or package type that is broadly compatible (like a part that comes in DIP8, SOIC8, TSSOP8, etc.) should it be mentioned that package is listed in the Description field?

3.10 It mentions itself, but should instead mention 3.11.

3.11 The third bullet should show possession, KiCad's.

3.11 Can the first and fourth bullets be combined?

3 I don't see anything about Reference and Value placement or justification. Such as center justified if placed on the y-axis, left justified if placed right of the origin, etc. See #848.

4.3 Should 1N4001 be in tick marks?

4.5 Perhaps this is better written as an imperative sentence, such as Indicate quantity of elements for symbol arrays. Ex: resistor array: Resistor_x8.. Also, this uses "ex" whereas other examples I saw used "e.g.".

5 Perhaps this reads better if changed to ..where _multiple elements_ (if present) _are_ separated..?

6 No tick marks around .kicad_mod and .pretty. And consider _within_ the .pretty _directory_.

6.1 Perhaps Specify package type first. And also isn't the "_" in the example a separator?

6.2 Suggest Package name and number of pins are separated using a hyphen.

6.3 The second example seems to use an underscore to append the unique package variation. Should it end in -1EP instead of _1EP?

6.4 The last comma is unneeded.

6.2/6.3/6.4 These items list separator characters explicitly, but others don't. Should each step show this? Or one item could be added in 6 to cover an underscore separator between the elements below, and these few items show a hyphen separator within each element? So we end up with element1_element2_element-3_element-4_element5.

6.5/6.6 These use a comma before e.g. while elsewhere is a period.

7.2 Uses pad 1 while 7.3 and 7.4 use pin-1. Let's be uniform. Is this somewhere to unify?

7.3 Should any guidelines or examples for the pin 1 mark be given? Also 7.4.

7.4 Perhaps add (footprint name) after Component value in first bullet for clarity?

7.3/7.4 Any text placement rules/requirements? Like ref des silk above, ref des fab at the origin, and value (footprint name) below?

7.5 Should the 5th through 8th bullets be indented another level?

7 As the rules are clearly meant to have the component body lie on the front layer of the board (see the copper layers in section 8), the sub-parts of section 7 can specify F.SilkS, F.Fab, and F.CrtYd.

9 Any need to specify a minimum drill size for the lead diameter or minimum annular ring? Sometimes this is clear in the datasheet but not always. We could require Level A of IPC-2221 and IPC-2222.

10.2 As datasheet URL is a separate field from description and keywords, why not give it a bullet point all to itself? And is this a duplication of 3.8 where we're best off to only have one place for each topic?

10.4 Perhaps specify this should be added even if the 3D model doesn't currently exist? That will ease maintenance later if/when the model is created.

And finally, how about rules for PR submissions? New symbols show an image including the pin table with pin types visible, etc. It could also mention automatic rule checking by Travis-CI, etc.

jkriege2 commented 7 years ago

JAN

SchrodingersGat commented 7 years ago

Thanks for the great feedback guys.

Check out updates to https://github.com/SchrodingersGat/kicad-library/wiki/KLC

I have also adjusted new KLC scripts to add new rules:

  1. 3.3
  2. 9.5
  3. 9.6

https://github.com/KiCad/kicad-library-utils/pull/81

jkriege2 commented 7 years ago

What about the unit-issue?

Also one addition: We should mention somewhere (especially in 10.4) the license of this lib and that 3D models that have been copied from a manufacturer site need to clarify that their license allows redistribution on this page!

JAN

evanshultz commented 7 years ago

Great work! Thanks for so much effort and letting us all collaborate!

1.4 Agree with Jan. Still no units?

3.2.iv Remove the "as" and is some text supposed to be bold?

3.5.iv UART and RS232 are both bidirectional, so it seems odd to include one as an example of input pins and another as an example of output pins. Am I misunderstanding?

3.8 I don't see anything about Reference and Value placement or justification. Such as center justified if placed on the y-axis, left justified if placed right of the origin, etc. See #848.

3.9.iii Mentions 3.10 but I believe it's now 3.11.

3.12.i Still one bullet here which is probably unnecessary and can be part of the rule.

4.5 "Indication" should be "Indicate".

6 Is the bold text intentional? Seems normal format would be fine here.

6 Is the use of an underscore to separate the section called out? I'm not seeing it.

6.3.i In the library I see a hyphen before 1EP, not an underscore.

7.3.viii Change "as far as" to "where".

7.5.v This should be indented one more since it, and the following three elements, and details for 7.5.iv. Also change the bullets here.

9 Should be specify the diameter of the drill over the lead diameter, at least for round leads? IPC also specifies this for various manufacturing levels.

SchrodingersGat commented 7 years ago

@evanshultz thanks for the feedback - most of that has now been implemented:

UART / RS232

My thinking is that UART is interior to the PCB, whilst RS232 is "outside" (to another board). Such chips are level-shifters and functionally separate the UART and RS232 sides

9

I'm not sure what you mean by drill over the lead diameter? Can you provide some more info here?

poeschlr commented 7 years ago

@jkriege2

We should mention somewhere (especially in 10.4) the license of this lib and that 3D models that have been copied from a manufacturer site need to clarify that their license allows redistribution on this page!

For 3d Models (In the new repo) we have a separate wiki page about licensing: https://github.com/KiCad/packages3D/wiki/Model-Licencing I don't think that there are any manufacturers who's models are under a compatible license.

We also have an extensive how to contribute page: https://github.com/KiCad/packages3D/wiki/Contributing

Maybe something similar would make sense for the symbol and footprint libraries.

SchrodingersGat commented 7 years ago

@jkriege2 @poeschlr @evanshultz do you three mind if I add you as contributors to the KLC? You have all made valuable contributions

evanshultz commented 7 years ago

@SchrodingersGat Of course!

In general, there are inconsistencies with period use. For example, 7.6 does not have a period in the second sentence. Most of section 1 does but the rest does not. 3.2.i does but the rest of 3.2 does not. There are, however, very minor details that don't detract from the core message of KLC. I can point these out or make tiny edits to this effect myself if you would like.

3.4.ii Perhaps best to include the CS signal in the SPI bus and separate the two examples? So this:

Pins with similar functions should be placed together, e.g. SPI_MISO, SPI_MOSI, SPI_SCK, SPI_CS and UART_TX, UART_RX.

3.5.iii/3.5.iv I was thinking that since this is about the schematic symbol, both UART and RS232 will/can have data going to and leaving the symbol (part). They're both bidirectional. Whether the signals leave the board or not didn't strike me as mattering when it came to the symbol creation. I was only thinking that abus where data can go both ways was not a good example of input or output. SPI is also bidirectional and could only be an input or output (for example, I've used logic chips to only receive data from MOSI and only place data on MISO and in both cases the other data pin wasn't present). But really, this is a small point and the idea is probably understood regardless of my words above.

3.8 My understanding is that my suggestion above is not going into KLC. This is fine as we're a democracy and we don't have to agree on every detail to be unified in making this update as a whole. Just checking that you saw my suggestion and we're deciding it doesn't fit into KLC 2.0.

3.11.iv Should it be 3.11 instead of "3.11"?

4.5 Is the italic text intentional?

9.5 Is this supposed to be the drill size over the lead diameter? Right now it's easy to read that this is the minimum drill size without a lead. Like for a via. So if 0.15/0.2mm is the diameter the drill must be over the max lead diameter, then we should specify it clearly as being the max lead diameter + some dimension.

SchrodingersGat commented 7 years ago

@evanshultz

3.8

The reason we use mils here is that eeschema uses mils as its internal unit. Unlike pcbnew which uses mm. It's an inconsistency on the part of KiCad

9.5

Can you provide some wording here?

Generally regarding periods I have dropped trailing periods for list items and dot points.

I think I have adjusted to fix your other points (still not sure about UART / RS232).

UART / RS232

I don't think "Inputs" vs "Outputs" is really the best wording for this rule. e.g. most chips "convert" data from one format to another. ADC, DAC, CAN to SPI, etc. In this case, the split data types should be on opposite sides of the chip. How do we word this?

SchrodingersGat commented 7 years ago

The latest update to https://github.com/KiCad/kicad-library-utils/pull/81 features some good checks for pin-stacking (KLC3.3)

evanshultz commented 7 years ago

Periods: Understand the method. But 1.1 and 1.4 don't have periods while the rest of section 1 does. 3.2.ii does but other 3.2 items do not. 4 and 5 are missing a period for the second sentence. 7.6 is missing one after the second sentence.

Also regarding style, typically a single sub-section is discouraged. For example, 9.3 has i but not ii or any others. It's not a big deal to me, but if you want to change it I'm letting you know.

3.5.iii/3.5.iv Agreed this is tricky to word. The + and - input pins of an opamp are clearly inputs, though, while signals go into and out of UART and RS232 pins. Please see the below and if you don't have for it then I say we leave it in the interest to releasing KLC 2.0. I've given many example from various disciplines of devices so you can see these examples and pick and choose what you like, such as only listing transformer in one of the two sections so that we cover a lot of examples but don't need to have all the matching input and output examples in both sections.

Input/Control pins should be placed on the left of the symbol, e.g. opamp + and - inputs, NPN base, JFET gate, 7404 input, SPI pins on an ADC or DAC, ADC input(s), linear regulator input, enable pins, transformer primary, etc. Output/Controlled pins should be placed on the right of the symbol, e.g. opamp output, 7404 output, DAC output(s), linear regulator output, transformer secondary, etc.

3.8 This is about text placement and justification for symbols. Not about units.

3.11.iv Should the reference to section 3.12 be in code marks, like 3.12? Currently it's normal text.

9.5 In thinking about this, I believe we want a standard instead of options. This would have to be manually checked so it's not something we can automate and just one rule makes that easier. And if we want our footprints to be generally manufactureable instead of requiring advanced processes, we need to err on the conservative side. Also, 0.05mm is tiny in absolute terms so I don't see that it's a drawback to go big. So all that said, how about this:

Minimum drill size is the maximum lead diameter plus 0.20mm (IPC-2222 Class 2)

10.3 Is the bold text intentional?

SchrodingersGat commented 7 years ago

Thanks for your patience in finding all these small discrepencies. I think i have caught all the errant periods now.

3.5

Perhaps "Logic" and "Driver" are good way of separating UART / RS232?

  1. Input/Control/Logic pins should be placed on the left of the symbol, e.g. opamp +/-, NPN base, SPI pins on an ADC, transormer primary, UART Tx/Rx pins, etc.
  2. Output/Controlled/Driver pins should be placed on the right of the symbol, e.g. opamp output, ADC output, transformer secondary, RS232 Tx/Rx, etc.

3.8

This is a weird one as Kicad auto-places these fields anyway.

Currently Rule EC03 checks for this but it's very complicated and the output it generates is quite difficult : https://github.com/KiCad/kicad-library-utils/blob/master/schlib/rules/EC03.py

Do you have an example of a library part I can look at as an example of a "good" text orientation?

SchrodingersGat commented 7 years ago

Another thing to discuss is naming convention for part-variants of symbols : ref - https://github.com/KiCad/kicad-library/pull/1079

The libraries currently manage this in different ways:

jkriege2 commented 7 years ago

Hi!

evanshultz commented 7 years ago

Periods: If there is a complete sentence with a period in a block of text, periods should be everywhere. The paragraph directly under 4 and 5 are both missing a period for the second sentence, as is 7.6.

Style: I would discourage the use of a single sub-level. Merge the sub-point into the level above it. Here is where I see this happening:

3.5 Seems OK to me. Any more and it's probably just going to get worse and more confusing. @jkriege2 I don't see this as an issue. ADCs can have SPI control pins and digital output pins. Maybe I'm not understand your comment so could you add a bit more detail?

3.8 I'll quote what I wrote in #848, which is linked above:

KLC does not specify how and where text should be located or justified. From seeing many library parts and the changes being made (like the huge update from @jkriege2), it seems the following is the correct convention:

Vertically-oriented symbols have text placed to the right of the symbol and left-justified. Horizontally-oriented symbols have text above and below the symbol and center-justified.

This would also be relatively simple verify in checklib.py as the X- or Y-location and justification are easy to parse.

Good point on naming convention! I think using the package (2nd option) is best since, for a user, they don't need to know the unique suffixes for each vendor. Getting started and changing the package later seems easier if we go that way. And if there are multiple packages of the same base type, like SOIC and SOIC with a thermal pad, we can still note that in plain English rather than a cryptic code.

evanshultz commented 7 years ago

Another one: 3.3.ii The word "in" is duplicated.

poeschlr commented 7 years ago

do you three mind if I add you as contributors to the KLC? You have all made valuable contributions

I don't mind. (Haven't seen your question until now.) Aren't we included by: (maybe add the github contributer list)

With help from members of: kicad-lib-committers kicad-developers

Today again the problem with the hidden power pins has resurfaced in the info forum: I think we should have clear rules under what circumstances hidden pins are allowed. (It is mentioned implicitly over a few rules.)

I would suggest something like: The use of hidden pins is discouraged if not allowed explicitly by any other rule.

I am still not sure if it is a good idea to have nc pins hidden. (Yes symbols might get cluttered otherwise but i think it is a price worth paying.) Maybe add a rule that hidden nc pins need to be inside the symbol to reduce the danger of connecting them by accident? (Or say something like it is preferred this way if possible)

jkriege2 commented 7 years ago

What about rules for pin-stacking? They are in the scripts, but should also be in the KLCs ... or did I miss them?

JAN

SchrodingersGat commented 7 years ago

@jkriege2 Rule 3.3

SchrodingersGat commented 7 years ago

Hmm @poeschlr the whole invisible pin saga keeps coming back to haunt us.

The only reason I even contemplate allowing NC pins is to aid in the "associate by pin number" trick in KiCad. Until the new library format is implemented, we have to specify each pin otherwise the numbers don't match.

Perhaps we do need to prohibit "invisible" pins in the symbol entirely. The one exception would be for pin stacks where all-but-one must be invisible.

i.e. if there are any invisible pins on their own, this will be an error.

poeschlr commented 7 years ago

Hmm @poeschlr the whole invisible pin saga keeps coming back to haunt us.

Yea once a month we get a newbie question on the forum regarding some problem with invisible pins. (Most of the time it is about the invisible power pins in the 74xxx lib. This time someone volunteered to fix the problems. Lets see if this person really does something.)

Perhaps we do need to prohibit "invisible" pins in the symbol entirely. The one exception would be for pin stacks where all-but-one must be invisible.

If the invisible pins are at some place where no sane person would ever place either a junction or another symbol, there is no danger. So i would allow nc pins to be invisible if they are placed within the symbol. (I think @evanshultz made a few symbols this way. They looked ok for me.)

jkriege2 commented 7 years ago

About KLC3.3: Thanks ;-) ... thought it was there, but didn't find it, because I was searching for "stack" ... should we mention that somewhere, e.g. as (pin stacking) as I presume I won't be the only one searching for that ...

cu JAN

jkriege2 commented 7 years ago

About 74xx/cmos/...: yes that's a real pain ... I feel we should either wait until we have the new format and then do it by hand, or find some script-approach that will allow for an easy overdo of the lib, when the new format arrives, or even add different varaints/styles for each symbol ... But first we should decide how we want to handle the power-pins (visible/invisible/extra componen/...) and whether we really need two styles (IEEE+the round one) + "DeMorgan"???

Best, JAN

poeschlr commented 7 years ago

For power pins: Never ever invisible. To quote Andy_P from the forum "Hidden power pins are the tool of the devil." For single unit symbols there is no problem. I think the rule about pin placement already takes care of them.

For multi unit symbols: I would make a separate unit for the power pins. I use this in my personal library: multi_unit_with_power_separate

Yes there will be the danger that some users might forget to wire the power pins. But i think the current solution with the hidden pins is much more dangerous. (Especially if one has more than one supply voltage)

evanshultz commented 7 years ago

I agree. Never hide power pins. Perhaps the check script could throw an error if not all units are placed? And since we have checking for unconnected pins which aren't marked as NC, we should be good.

Regarding power pins style, I also prefer a separate unit for power pins rather than power pins on each unit.

evanshultz commented 7 years ago

Two more topics:

For both items, see the root discussion at https://github.com/KiCad/kicad-library/pull/1081.

SchrodingersGat commented 7 years ago

+1 from me to never ever have hidden power pins. It's allowed for user libs but it's time we made an executive decision for the official libraries.

  1. Undefined / opaque behaviour
  2. What if you want to connect to something other than Vcc
  3. No. Just no.

I agree that multi-unit symbols should have an extra unit for power and gnd pins.

Now, to add and word the appropriate rules

SchrodingersGat commented 7 years ago

@evanshultz regarding "variants"

Package variants

For part variants that use different symbols, we should specify that a unique symbol must be made that points to the correct footprint. This is functionally a different component and should be treated as such.

Component variants

e.g. different temperature ratings, etc I would vote that (for now, until we have the new lib format) we add a basic version of a symbol as we are not specifying entire MPN yet anyhow (I think we should, in the future, specify "complete" parts with MPN, exact specs, etc).

But how far do we go on this?

Example: INA19x ( http://www.ti.com/lit/ds/symlink/ina197.pdf )

The variants of this part have different gains AND different pinouts

Or MCP2551 - http://ww1.microchip.com/downloads/en/DeviceDoc/21667f.pdf

Different temperature are available, as well as different footprints (that are pin compatible) so we could have a single MCP2551 symbol which has two footprint filters, no default footprint, and no mention of (e.g.) temperature.

This is probably all we can do for now, as the format of .lib / .dcm files is SO BAD.

poeschlr commented 7 years ago

Because it happened today: What should we do about rounded rectangles? Or for that matter any future addition that is not supported by the latest stable version. I vote for disallowing anything that is not supported by the most recent stable version.

What should we do once kicad 5.x comes around. Should there be some period of transition where we only allow features that kicad 4.x also supports? If so, how long should we give users until we expect them to update to the latest release? (Or is there some other solution for this problem i am not aware of?)

SchrodingersGat commented 7 years ago

The solution to the problem is for KiCad to continue to load footprints when it encounters one it can't understand. Currently it hits a problem and stops loading the entire library.

If it saw a footprint with unusual data, it could say "footprint either corrupted or from future version" and continue on its way.

poeschlr commented 7 years ago

Do you think that this feature will be added to kicad 4.x? (This would mean that there needs to be a version 4.0.7 before kicad 5.0 comes out)

Otherwise we need to take care of this problem by ensuring that only footprints are in the library that can be interpreted by the stable release. (In my mind we should ensure that everything is compatible with the latest stable release.)

Even if this feature is added in another kicad 4.x version. Until this version is released we need to ensure that footprints are compatible with the stable version.

SchrodingersGat commented 7 years ago

@poeschlr agreed, yours is the right course of action. I have just asked about it here - https://lists.launchpad.net/kicad-developers/msg28618.html

SchrodingersGat commented 7 years ago

Any outstanding issues preventing this from going "live"?

jkriege2 commented 7 years ago

none in my view ... we can always add additions later ... but I think this should really go online ...

poeschlr commented 7 years ago

I can't find anything pressing either.

evanshultz commented 7 years ago

Yes. Let's not let perfection be the enemy of good enough. That being said, to me there are a few topics worth closing before going live.

Are visible power pins clearly spelled out? We agree on this above, but I'm not seeing it in the latest KLC 2.0 draft. Probably there but I'm not spotting it...

I think package variants should be settled. The library already has at least two variations on this and it's unclear to me what should be done.

The updated Python check scripts should be published in concert with this release. Are they totally ready, as far as can be known now? We're advertising the check scripts on the KLC page so we should be sure the scripts will help guide users to follow these rules once they're published.

3.5.ii How about "Negative Power and Ground pins..."

3.8 For clarity, how about giving the "F1" through "F3" values so a user can more quickly orient themselves to which line in the LIB file is being referred. As the libraries are text files, and sometimes that's the best/easiest/fastest way to edit/view, we can be explicit about which line has which function.

3.12.i I sometimes see "?" used instead of "*". (I assume to match at least one instead of zero or more characters.) Should KLC specify only an asterisk?

jkriege2 commented 7 years ago

About the scripts: I'm trying to use the version from @SchrodingersGat 's PR that matches teh KLC: https://github.com/KiCad/kicad-library-utils/pull/81 ... I think the check-side works quite fine ... Here and there I spotted a bug when using the --fix-option, but that's at least not in Travis ;-) ... The problem is: We don't have a complete set of test-cases, so we can only poke at the scripts and see what falls out ... but for that it seems they work nicely ;-)

Best, JAN

SchrodingersGat commented 7 years ago

@evanshultz let's try to get these last two issues sorted, then:

Hidden power pins

We should specify that hidden pins are generally not allowed, hidden power pins are definitely not allowed for symbols. Where should this rule be placed do you think?

Package Variants

My personal preference is to use the part number and call out the package variant in the description. I can see how it is more user friendly to use the package name in the name of the symbol but this makes it harder to include multiple variants... Anyone else have thoughts on how to proceed with this?

evanshultz commented 7 years ago

Part of me wants to group 3.3 and 3.7 together as they, and power pins, deal somewhat with a common theme of pin visibility. But perhaps it's best to make another item. I can see it fitting with 3.5.

3.5.v Power pins may not be hidden. For symbols with multiple units, the power pins will be on the last unit and arranged as described above. For example, a quad opamp will have four logic units and the power pins will make up the fifth unit.

For package variants, I already mentioned that I favor using the package name since the manufacturer part number can include lots of info not related to package. I see non-idealities with both approaches, but this seems the best to me. One example is AD7533 where I could add the package and then the variants could be an ALIAS. If the manufacturer PN is used it seems, to me, that the symbols are more mixed up. Do you have an example where full part number works better, or where using the package breaks down? More detail on how this is harder for multiple variants?

Also, I wrote 3.8 above but either KLC got changed or I mis-read because I was referring to 3.9.

jkriege2 commented 7 years ago

@evanshultz In an ideal world I would fuly support your rule 3.5.v, but with the current status of KiCADs library format we will run into problems - especially for logic chips, but also for Opamps - it's hard to draw up a sensible power-symbol-part due to placement issues of the labels: In the current lib-format, the labels+REFDES have ONE and only one position in ALL parts of a symbol ... Then when you need different positions of that label with respect to the pins, you will have the anchor wandering all over the place (see also https://github.com/KiCad/kicad-library/issues/605) ...

SO I'm not sure, whether we should have such a detailed rule YET???