kicad-lib-committers team mailing list archive

[Phinitnan Chanasabaeng <phinitnan_c@xxxxxxxx>]

See the example.ps at
http://bazaar.launchpad.net/~crackerizer/kicad-newlib/trunk/files for the
drawing example.

Tony

On Thu, Sep 27, 2012 at 2:08 AM, Phinitnan Chanasabaeng <
phinitnan_c@xxxxxxxx> wrote:

> On Wed, Sep 26, 2012 at 7:18 AM, Vesa Solonen <vesa.solonen@xxxxxxxx>wrote:
>
>> Nice to see that some spark is still glowing. Let me get some tinder...
>>
>> Tony, your input for the dicussion is again very well thought and full of
>> insight, not to mention the habit of professionally documenting it all.
>> Felix, welcome on board and I agree 100%. Bernd, thanks for your library
>> work and enthusiasm to make it even better. 73 de oh2jcp ;)
>>
>> To me the main annoyance was drawing style inconsistencies in the
>> symbols, but the following includes some other points that need fixing for
>> the future.
>>
>
> 25.09.2012 19:34, Phinitnan Chanasabaeng kirjoitti:
>>
>>  Hello,
>>>
>>> In my opinion, we should discuss and agree on a set of rule and style
>>> before start working. It should be well documented with clear version
>>> number just like in .lib and .mod specification. This will help users
>>> whether they should upgrade their library or not in case of major changes
>>> in the specification. I would like to propose my idea how the new library
>>> would be restructured and recreated here and will summarize it in detail
>>> as
>>> a blueprint (and a odt document) after the discussion.
>>>
>>> 0. Definitions
>>>      0.1 Directory structure - the directory consists of symbol,
>>> footprint,
>>> model, document and probably readme, changelog, etc files.
>>>
>>>      library ------
>>>                   |---- symbol             ---> symbol libraries
>>>                   |---- footprint            ---> footprint libraries
>>>                   |---- model               ---> 3d models
>>>                          |----source
>>>                   |---- document         ---> datasheet, application
>>> note,
>>> pictures, etc.
>>>
>>
>> I think we would need a fifth definition for a component/part.
>>
>> Symbol => Schematic representation. This is the logic for the net list
>> and an abstract interface for a human.
>>
>> Footprint => 2D PCB object with a bounding box, outline, solder and
>> mechanical board level details.
>>
>> Model => 3D representation of a real physical object.
>>
>> Documentation => datasheet, SPICE model, version, production status, etc.
>>
>> Component/Part => The rule how Symbol-Footprint-Model-**Documentation
>> are related. A representation of a real component/part, like 2N222 or
>> 2N3055. Gate swap and pin swap model contained here.
>>
>> Why so complex? To get flexibility and to get around copying. Also this
>> is the only way to get the whole verified for correctness. It needs more
>> effort in the design phase, but less effort in the maintenance and use
>> phase. (Some larger software projects might be good examples) Current data
>> structures in KiCad don't allow this, but we should start building the data
>> for the future and then "downsample" for the current use. Say collecting
>> the data in odf spreadsheet and scripting it into the current library
>> format for release. Any python gurus? A spreadsheet interface could also
>> mobilise some less technically inclined for the cause. We just would have
>> to make a fill up form for it. Or maybe a dynamic web form at
>> kicad-pcb.org/library...
>>
>> Let me give a few examples:
>>
>>
>> NPN bipolar transistor.
>>
>> Symbol: Looks like a NPN BJT. Contains pin functions E, B, C. Special
>> versions for the ones with housing connected to E, B, C or special
>> terminal. Their use is optional. That would mean five symbols for all NPN
>> BJTs. Pin numbers are _not_in_ the symbol, they are rendered when a
>> component/part is defined and the pin functionality-number mapping gets
>> known.
>>
>> Footprint: Any of the available with enough pads.
>>
>> Model: May be tied to the footprint, but one footprint may have more than
>> one model as the height is not in the footprint. Models with vertical
>> heatsink as an example.
>>
>> 1)
>> Component/part: PN2222 tells that pin E=1, B=2, C=3, footprint and model
>> are TO-92 and links to the documentation. No gate or pin swap available.
>>
>> 2)
>> Component/part: Change PN2222 to 2SC945. No need to change the symbol,
>> just update the BOM and the net list automatically changes to E=1, B=3,
>> C=2. Autorouter does the pin swap between pins 2 and 3.
>>
>> 3)
>> For some odd reason one wants to use a plugin NPN-BJT in a DIP-8
>> IC-socket... the collector and emitter currents are so high that one has to
>> use at least 2 pins for them, but for mechanical reasons pins 1-4 are
>> connected to emitter and 5-7 to collector with 8 to the base. Routing DRC
>> is happy as long as two of the pins of each bank are routed and autorouter
>> is free to pick any of the available for a best fit. Pin swap is available.
>>
>> 4)
>> Nice three winding coupled inductor for your latest PFC converter.
>> Calculations and point to point test setup measurements tell that ETD49 is
>> good enough for 2kW. Slap a standard 20 pin ETD49 bobbin on the PCB and
>> your three winding transformer symbol piled up from inductors in the
>> schematic is just fine. Pin mapping is just the one liner in your
>> component/part definition file with the documentation showing the winding
>> details.
>>
>>
> Totally agreed. My proposed spec is based on current functionality of
> kicad. If the new lib is separately designed from kicad, it would have its
> own direction and is not limited by kicad development. But I think we
> should use a real database engine like SQLite for this. Because it's easier
> in the programming interface. You can also edit a file by any supported
> software just like editing a spreadsheet.
>
>
>>
>>       0.2 Grid unit (GU) - 25 mil
>>>
>>> 1. Symbol library and symbol naming scheme
>>>      1.1 Library naming - as the symbols are put in library files, this
>>> is
>>> the way symbols are categorized.Therefore, I think, the way libraries are
>>> named should reflect its category as much as possible. Here is the
>>> scheme I
>>> proposed:
>>>
>>>      {main-category}-{manufacturer, standard}-{other fields separated by
>>> "-"}.lib
>>>
>>>      the main category and manufacturer fields are required. The other
>>> fields can be added to describe the lib. For example,
>>> "device-en60617.lib",
>>> "connector-molex.lib", "microcontroller-microchip.**lib", etc. "generic"
>>> should be used in {manufacturer} field for any standard components. The
>>> file name should be in lower case.
>>>
>>>      1.2 For symbol naming, I proposed:
>>>
>>>      {name}-{other fields separated by "-"}-{footprint}-{pin quantity}
>>>
>>>      Only {name} is required here. For examples, "MCP73832-SOT-5,
>>> 2N2222-A-TO92", etc. For fundamental devices, there should be a set of
>>> name
>>> to be derived from such as "RESISTOR, CAPACITOR", etc. All other
>>> libraries
>>> of fundamental devices should use this name set. I'm not sure whether
>>> lower
>>> or upper case is suitable.
>>>
>>
>> Agreed, but do we need that much data in the name? Eagle style "heavy
>> symbol" system is quite ugly when it grows a to a bit more than two
>> capacitor manufacturers. Even capacitor cases are standardised. For
>> microcontrollers and special function stuff with only one source it makes
>> sense and is the only way.
>>
>>
> As noted, only name is required. ;D
>
>
>>
>>  2. Line style - the style proposed by Vesa can be used. But the DU unit
>>> and
>>> other line weight should be specified. This line style will be used in
>>> both
>>> symbol and footprint drawing. The line weight should be chosen based on
>>> physical print quality (especially, on PCB silkscreen layer).
>>>
>>
>> I'd say footprint side is a lot less critical than schematics as there is
>> not much data on the same layer. That makes separating objects by line
>> widths unneeded. Just rendering time option depending on the process.
>
>
> The constrain is now changed :D. This definition is almost unnecessary.
>
>
>>  3. Symbol drawing style
>>>      3.1 Block model - all symbols will be drawn as blocks
>>>          3.1.1 Fundamental symbols - devices such as resistor, capacitor,
>>> logic, etc, will be separated into 2 types
>>>              3.1.1.1 Symbol - this block is 16x16GU. It is used in
>>> schematic
>>> as a normal symbol. Drawing and all interface pins should fit inside this
>>> block.
>>>              3.1.1.2 Building block - this block is 8x8GU. There is no
>>> assigned pin as it is used to build the other block symbols.
>>>
>>>          3.1.2 Block Symbol is a blank block or block built from building
>>> block with assigned pins. A specific width and height ratio should be
>>> used
>>> (except the square block). I propose the golden ratio (1.618). The
>>> closest
>>> even number from multiplication/division of width/height will be used.
>>>
>>>          3.1.3 Orientation - For fundamental symbols, should they be
>>> placed
>>> horizontally? For block symbol, see pin position and orientation.
>>>
>>
>> Agreed. Some very interesting ideas, like the golden ratio. Are you going
>> to make some example drawings? Eventually the drawing style will end up
>> being somewhat after the standard and the rest by the test and vote. I
>> haven't seen good looking schematics from any CAD that would have conformed
>> strictly to the standard. Strictly standard compliance library would almost
>> have to be a separate one to be pleasant :D
>>
>>
> I'm currently reorganized my library to meet the spec and I'll show the
> example in a couple days. I agreed that we wouldn't get a good looking
> symbol by strictly to the standard (my lib is a little bit modified from
> 60617 standard). But the standard will still be used as reference. ;)
>
>
>>
>>  3.2 Name and designator
>>>          3.2.1 Designator - what standard should be used? or should it be
>>> redefined (based on available standards) especially for kicad?
>>>          3.2.2 Position - Designator will be placed at the middle-top and
>>> name at the middle-bottom of the symbol. At least 1GU space to any nearby
>>> line or pin should be added.
>>>
>>
>> I've been using top-right for the designator and left-bottom for the
>> name. Those are usually the empty areas and are easy to find by the glance
>> as one finds them by following either vertical or horizontal line. Corner
>> is like an arrowhead that catches ones attention and there it is, the
>> needed data.
>>
>>
>>
>>>      3.3 Pin
>>>          3.3.1 length for block symbols - 12GU (300 mil, current pin
>>> length
>>> used by kicad)
>>>          3.3.2 Pin to pin space - 4GU (100 mil)
>>>          3.3.3 Pin to corner space - 4GU (100 mil)
>>>          3.3.4 Position and orientation
>>>              3.3.4.1 Positioned by its function - group the same function
>>> together
>>>                  3.3.4.1.1 Input pin - start from top-left of the block,
>>> counter-clockwise
>>>                  3.3.4.1.2 Output and Bidirectional pin - start with
>>> output
>>> pin from top-right, clockwise
>>>                  3.3.4.1.3 Power input - Distributed at the center of top
>>>                  3.3.4.1.4 Power output - Distributed at the center of
>>> bottom
>>>
>>>              3.3.4.2 Positioned by its footprint - the 1st pin is placed
>>> at
>>> top-left of the block
>>>
>>>          3.3.5 Pin naming and numbering
>>>              3.3.5.1 Left,top = 1, right,bottom = 2
>>>              3.3.5.2 Anode = 1, Cathode = 2
>>>              3.3.5.3 Control = 1, input = 2, output = 3
>>>              3.3.5.4 GND = 1, input = 2, output = 3
>>>              3.3.5.5 BCE = 123
>>>              3.3.5.6 GDS = 123
>>>              3.3.5.6 Pin name should be exactly the same as noted in the
>>> datasheet
>>>
>>
>> For pin legths we need to take tha total count of numbers in account.
>> Otherwise four number pins will overflow and the one number ones would look
>> empty. For some special purpose IC's the in-out-power pin directions would
>> have to be relaxed. The purpose of the schematic is to be clear and
>> readable and in the special purpose IC's the surroundings are so tightly
>> defined that pin locations have to be picked according to the surroundings.
>> PFC IC's are a good example. For logic the opposite is true and that's what
>> you wrote.
>>
>> The numbering is something we can't always pick as it depends on the
>> physical world. Schematic doesn't care about it anyway. Schematic is just
>> for the human. What ends up in to the netlist is something I don't care as
>> long as the machine reads it ;)
>>
>>
>>       3.4 Symbol property
>>>          3.4.1 For symbol with multiple units, the power unit should be
>>> created explicitly.
>>>          3.4.2 Symbol description - The value should be put in all
>>> fields,
>>> especially keyword. See below
>>>              3.4.2.1 Keyword - this field should be changed to "Tag" and
>>> will be used for the search tool. It is probably used for footprint
>>> lookup.
>>>              3.4.2.2 DocFileName - should refer to a file in the document
>>> directory or a download link
>>>          3.4.3 Alias is obsolete, do not use it.
>>>          3.4.4 Footprint filter - I'm sure how this works but if possible
>>> the words put here will be used to search in the module keyword.
>>>
>>>      3.5 Symbol field property
>>>          3.5.1 Symbol with {footprint} in its name should be mapped to
>>> the
>>> exact footprint in the footprint library.
>>>          3.5.2 Datasheet should referred to a file in the document
>>> directory
>>> or a link to download website. (DocFileName
>>>
>>
>> I'd say no to copying of any data. If the value is in the value field,
>> that's it. It's the UI's job to present the data as conveniently as
>> possible.
>>
>>
>>  4. Footprint creation
>>>      4.1 Naming scheme
>>>          4.1.1 Consider the IPC7351B, I once implemented it in my local
>>> library. It was good for machine, but not for human, It was very
>>> difficult
>>> to understand. I had to look through the footprint list to find the one I
>>> wanted. However, it is still possible to implement using footprint filter
>>> and/or keywords. To be discussed.
>>>          4.1.2 For file naming scheme, see the symbol scheme above. JEDEC
>>> name can be use as the {main-category}.
>>>
>>
>> Øyvind Aabling did quite a good job here. His system is very human
>> readable and I'd like to follow that. IPC7351B is a "design by committee"
>> so it must be equally annoying to everybody that nobody can be jealous of
>> somebody's enjoyment. It can be included as a tag to become an option.
>>
>>
>>       4.2 Pin number identification - for a footprint without pin number,
>>> put
>>> the component faced-up on the floor, the most pin count side on the left.
>>> The top-left is the 1st pin and count around the component
>>> counter-clockwise.
>>>
>>
>> Exactly.
>>
>>
>>       4.3 Footprint orientation depends on the first pin of the footprint.
>>> The first pin should be at top-left position. The footprint should be
>>> aligned horizontally first. If the 1st pin is not at top-left, align it
>>> vertically.
>>>
>>>      4.4 Silkscreen drawing - to be discussed
>>>
>>>   5. Model
>>>      5.1 Model name should be the same as footprint name.
>>>      5.2 Each available footprint should have a model assigned to it.
>>>
>>
>> Agreed. Documentation part should include draft-checked-production status
>> and the same for 3D model.
>>
>>
>>    6. Library organisation - I have been thinking about this for quite a
>>> while, how the new library should be organized. Open as kicadlib.org or
>>> well organized and verified by set of maintainers. To me, the only
>>> problem
>>> of kicad is it library consistency. I wouldn't use kicad for a large or
>>> commercial project even the main components are ready. I would proposed
>>> that kicad-lib-maintainer should be responsible for organizing and
>>> verifying all submit libraries to maintain its quality.
>>>
>>
>> I'm sure kicadlib.org won't go anywhere or at least the one with a
>> similar idea will pop up the moment it does... A few of grumpy lib
>> maintainers would probably do fine with the verifying and organising work.
>> Those maintainers would just have to clearly state that we don't accept
>> anything, but stuff that conforms to the following
>> guidelines/standard/whatever. Just for the fun of it I'd gladly accept an
>> "old radio style" symbol set for those few components that were available
>> 50 years ago. Only if it's good enough of course ;D
>>
>> -Vesa
>>
>>
>>
>> --
>> Mailing list: https://launchpad.net/~kicad-**lib-committers<https://launchpad.net/~kicad-lib-committers>
>> Post to     : kicad-lib-committers@lists.**launchpad.net<kicad-lib-committers@xxxxxxxxxxxxxxxxxxx>
>> Unsubscribe : https://launchpad.net/~kicad-**lib-committers<https://launchpad.net/~kicad-lib-committers>
>> More help   : https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp>
>>
>
> As the condition is now changed, I think there is more work to do. :)
>
> Tony
>