kicad-developers team mailing list archive

[Maciej Sumiński <maciej.suminski@xxxxxxx>]

One more field that could become predefined and receive a special
meaning is 'Mounted' or similar. This will come handy when we decide to
support assembly variants and will let us add a visual distinction
between mounted and not mounted components if we want it.

The remaining fields is a matter of configuration, particularly that
there is a way to specify the default fields in eeschema. I am quite
sure that there are existing libraries using other field names than the
ones we would hard-code, so such change would make users upset. I do not
see there is a reason to enforce field naming for everyone, unless the
field needs to be treated in a special way:

- "Reference" as the unique component identifier and a link between
schematics and board
- "Footprint" to pick the physical representation with the footprint browser
- "Datasheet" lets open corresponding documentation for a component
- "Value" is the only field that serves the description purpose only,
but it seems a sensible exception to the rule

Cheers,
Orson

On 05/20/2018 10:00 PM, kristoffer Ödmark wrote:
> Hello!
> 
> I will open this can of worms again, I feel that I have to. So from what
> I gather we have proffessionals as the main aim in Kicad.
> The reason I will open this issue again is that I feel we have a
> collaboration issue, maybe not a mayor one. But one nonetheless.
> 
> We really need more default fields for our schematic symbols. Im not
> proposing required fields, I am *ONLY* proposing that
> there should be default fields added into the default fields settings
> tab. I am not proposing they need to be filled in the
> libraries, nor that people need to use them. only that they need to
> exist with a fresh install of kicad so that easy problems
> such as theese do not happen:
> 
>     - Collaborators working on the same project will not create
> duplicate fields in libs/projects describing the same thing by mistake
>     - Projects that aim to interact or add to Kicad can assume that the
> Fields will exist, and will know what name/tag to look for
>       (bom exporters, price checkers, MacroFab, etc)
>     - Open source projects will be easier to collaborate, read and order
> 
> The reason I think it is better to have the fields by default than the
> current solution to add them is that the majority will use
> what exists, and tools can support it from the very beginning, people
> with inhouse tools seems to dislike this, since they map their
> parts with an inhouse number - and then handle the information about the
> part there. From what I gather, this is not the majority, and
> these persons still modify the default fields settings.
> 
> I spent maybe 30-40 mins checking the "made with kicad" projects, I
> found that the most common addition to libs and schematics are:
>     - Manufacturers part number, these were named widely different in
> projects, (BOM, MP, MPN, #mfg, or different syntaxes in the Value field )
>         I even saw a mix of these in the same project once, along with
> some people having the vendor id only.
>     - Manufacturer ( found some different languages though )
> 
> more uncommon things was, Tolerance( 10%, 20pps), Ratings ( 1/4W, 85C,
> 16V ), Vendor information and different Descriptions. They were named
> and abbreviated
> very differently accross projects.
> 
> What I would like to see is these additional fields by default, but
> hidden from the schematic unless changed by user.
>     Tolerance ( used for setting tolerances of resistors, capacitors,
> oscillators, etc )
>     MaxRating ( field were one can specify max Voltage, Ampere,
> Frequency, or whatever the component needs )
>     Manufacturer ( For inhouse numbers, they could either just remove
> it, or use the company/group name )
>     MPN ( Maybe PartNumber could be used here, and people who use
> inhouse numbers use it aswell, I dont really care what its called, as
> long as its called something )
>     Vendor
>     Notes
> 
> I would be all up for extra additions/removals, but I would prefer if
> the naming is not discussed, but rather just decided/agreed upon by
> someone in the lead team.
> The very least I think should be added in case the previous is to much are:
>     Tolerance
>     Manufacturer
>     MPN
> 
> I attach a patch for the minimal set, tested on linux by removing the
> .config/kicad/eeschema file.
> 
> - Kristoffer
> 
> 
> ps
> Some github files i reviewed, not all:
> https://github.com/AnaviTechnology/anavi-gardening/blob/master/MCP3002-I_SN.lib
> 
> https://github.com/jonpe960/blixten/blob/master/Blixten%20LED%20Device/Blixten.sch
> 
> https://github.com/paltatech/half-bridge/blob/master/pcb%20design/IGBT_board-cache.lib
> 
> https://github.com/pluggee/KiCADLibs/blob/master/sch/cap_smd.lib
> https://github.com/jim17/memtype/blob/master/schematic_pcb/electronic_design_kicad/electronic_design_kicad.sch
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

Attachment: signature.asc
Description: OpenPGP digital signature