← Back to team overview

kicad-developers team mailing list archive

  1. kicad-developers team
  2. Mailing list archive
  3. Message #29652

Re: [RFC] Standard field for manufacturer part number in schematic symbols

  Thread Previous • Date Previous • • Thread Next
These tools are not only supporting Kicad, some of them are supporting multiple CAD packages, they just look at what information that they know is available and use that. Not really bothering with what information "can" be there if only.
There is also the collaboration issue, where if you would use components from other people, they can have different names for the MFPN, the MPN, or the ManufPart or PartNo or whatever I have seen many. If I ask a classroom full of students to fill in the manufacturer part number for their projects, I usually have to explain where and how to fill that number very thoroughly. This is such a trivial thing that almost every EE uses in some way.
I really dont want to get into this discussion about why again. Rather make it about how can we implement it without breaking everything for those who dont want to use it. There is some serious power in sane default configurations.
With JP custom field I am refering to the settings tab in eeschema called Template Field Names.
Ok, good. So no hardcoding then, although that could have the benefit of adding things such as "Search digikey/mouser/google for ...". The same way we have with datasheets etc etc. 

Wayne Stambaugh wrote:
Maybe we should add a "FieldNames" entry to the default project file (.pro) that 
gets copied to the project folder when a new project is created.  That
can be read and merged with the user's custom fields defined in the
eeschema config file.  This seems like a better solution.  This way if a
user just doesn't like the default, they can just modify their default
project file accordingly.  There may be other potential solutions but
this is the best I can think of at the moment."
This seems like a good idea! Not breaking anything already there, but providing help for new stuff! 

On 06/06/2017 07:42 PM, Wayne Stambaugh wrote:

I feel the same way.  My guess is that some of this is new users coming
from other EDA apps that provide default fields which we do not provide.
  I personally would rather let users configure fields in the way that
works best for them rather than the KiCad project forcing defaults upon
them.

On 6/6/2017 1:25 PM, Bernhard Stegmaier wrote:

And why shouldn’t just make all those external tools the field names they look for make configurable on their end?
Instead of trying to satisfy them all with one field defined on KiCad side?
I guess someone who wants to setup a serious BOM workflow should be able to configure field names on both sides to match…

Just my 2 cents…


Regards,
Bernhard


On 6. Jun 2017, at 18:51, Kristoffer Ödmark <kristofferodmark90@xxxxxxxxx> wrote:

The main reason for the discussion ( From what i gather ) is that external tools then have a field they know will be there and can all gather around, since they know what it is called.

I dont really think it needs to be hardcoded as such, it could just be a default preference to the "JP custom field" table, but then at least there would be some solid ground to parse or create scripts around, IE anyone can expect that the field "Manufacturer Part Number" ( for example!) is going to be there by default. If it has been renamed or removed, so be it. But it can reasonably be expected to be there.

The only thing people agreed upon in this long discussion was that there should be some field that one can expect to hold a Manufacturer part number. The only way I see this happening (or not) at this point is that someone takes an executive decision here, and I believe that Wayne should be the one saying yay or nay, and decide upon a name. Adding it is probably not very hard. I could take that upon myself, in whatever form it takes.

I also dont think that anyone should have problems creating a script or tool that parses a field with a spaces in it, if they do have problems with that, I do not expect that script to be any good anyway :)

Regarding the UPN, I think it was just a compromise about the people wanting a house part number and the ones who wanted a manufacturer part number.

- Kristoffer

On 2017-06-06 17:48, Fabrizio Tappero wrote:

talking about complains... back on the wild KiCad forum (I did not know existed), people are kind of "destroying"  Kaspar's initiative to make KiCad a better tool.
Kaspar, I personally support your effort but I do not know how since I do not have any special need in the BOM department. I am happy with JP's custom table.
One the other hand... I would find schematic variants a way more interesting matter. But that is an other episode of the KiCad series.
cheers
Fabrizio
On Tue, Jun 6, 2017 at 5:15 PM, Wayne Stambaugh <stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>> wrote:
    Are the KiCad library developers planning on providing atomic symbol
    libraries?  I'm guessing that is the end goal for reserving a name for
    an optional field.  I cannot think of any other reason to do this.
    On 6/6/2017 9:22 AM, Kristoffer Ödmark wrote:
    > Hi!
    >
    > I will bump this issue again, but to avoid bikesheeding I will ask for a
    > decision from leader Wayne. Should there be a default field in kicad for
    > part number and if, what should it be named?
    It doesn't matter what I decide.  Since these are optional fields, users
    can choose to ignore, change, or delete them.  In my own projects I use
    the obvious field name "Manufacturer Part Number".
    >
    > From what i gather, a field for a part number is the only thing everyone
    > agrees on, after that everyone has some different standard and wishes
    > for default fields ( Tolerances, fitting, vendors, manufacturer,
    > housepart etc etc ).
    >
    > The name for a part number seem field to most favoured to be MPN or
    > ManufacturerPart (differs between github and the user forum), although
    > UPN for universal part number was suggested and not flamed.
    "MPN" it's not very descriptive (human readable).  "ManufacturerPart" is
    more descriptive but I'm not thrilled about the camel case name although
    I could stomach it.  Field names are not programming language syntax.
    They can have spaces in them for readability.  I'm guessing that someone
    is using an application where spaces in the field name causes issues but
    I'm not sure that should be a concern for KiCad.  I don't much care for
    "UPN".  Are manufacturer's even talking about a universal part numbering
    system?  I would be very surprised given that manufacturers do their
    best to differentiate there products even if they are functionally
    equivalent.
    I don't have a strong opinion on this but if I had to pick one of the
    choices you have given me, I would pick "ManufacturerPart".  Let the
    complaining commence. ;)
    I hope this helps!
    Cheers,
    Wayne
     >
     > Pros:
     > Easier with a standard for external tools.
     > Every component has one, not every component has values, many
    have both.
     > Is optional to use, so will not break anything for anyone not
    wanting to
     > use it
     >
     > Cons:
     > Some are worried the fields will be impossible to keep updated in the
     > standard libs
     > Some people are using House numbers instead
     > Some think this data should not be in the schematic but handled
    by other
     > tools
     >
     > Links to discussions I you want to read it:
     >
    https://forum.kicad.info/t/default-manufacturers-part-number-field-in-kicad-libraries/4387/28
    <https://forum.kicad.info/t/default-manufacturers-part-number-field-in-kicad-libraries/4387/28>
     >
     > https://github.com/KiCad/kicad-library/issues/808
    <https://github.com/KiCad/kicad-library/issues/808>
     >
    https://forum.kicad.info/t/standard-symbol-field-names-initiative/4870/3
    <https://forum.kicad.info/t/standard-symbol-field-names-initiative/4870/3>
     >
     >
     >
     > On 2017-01-12 20:12, Kaspar Emanuel wrote:
     >> I have put up a proposal for a "community standard" on the forum:
     >>
    https://forum.kicad.info/t/standard-symbol-field-names-initiative/4870/1
    <https://forum.kicad.info/t/standard-symbol-field-names-initiative/4870/1>
     >>
     >> On 12 January 2017 at 18:33, Kaspar Emanuel
    <kaspar.emanuel@xxxxxxxxx <mailto:kaspar.emanuel@xxxxxxxxx>
     >> <mailto:kaspar.emanuel@xxxxxxxxx
    <mailto:kaspar.emanuel@xxxxxxxxx>>> wrote:
     >>
     >>
     >>     On 12 January 2017 at 16:44, Kaspar Emanuel
     >>     <kaspar.emanuel@xxxxxxxxx <mailto:kaspar.emanuel@xxxxxxxxx>
    <mailto:kaspar.emanuel@xxxxxxxxx <mailto:kaspar.emanuel@xxxxxxxxx>>>
    wrote:
     >>
     >>
     >>         Is there actually any issue, internally to KiCAD, with
    creating
     >>         multiple fields with the same name? It seems to let me
    create
     >>         two fields called MPN and save and re-open without a
    problem.
     >>
     >>
     >>     Actually, just tested again and it doesn't like fields with
    the same
     >>     name, it simply overwrites them once you press ok, not sure
    what I
     >>     was doing before. That's a shame.
     >>
     >>
     >>
     >>
     >> _______________________________________________
     >> Mailing list: https://launchpad.net/~kicad-developers
    <https://launchpad.net/~kicad-developers>
     >> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
    <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
     >> Unsubscribe : https://launchpad.net/~kicad-developers
    <https://launchpad.net/~kicad-developers>
     >> More help   : https://help.launchpad.net/ListHelp
    <https://help.launchpad.net/ListHelp>
     >>
     >
     > _______________________________________________
     > Mailing list: https://launchpad.net/~kicad-developers
    <https://launchpad.net/~kicad-developers>
     > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
    <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
     > Unsubscribe : https://launchpad.net/~kicad-developers
    <https://launchpad.net/~kicad-developers>
     > More help   : https://help.launchpad.net/ListHelp
    <https://help.launchpad.net/ListHelp>
    _______________________________________________
    Mailing list: https://launchpad.net/~kicad-developers
    <https://launchpad.net/~kicad-developers>
    Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
    <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
    Unsubscribe : https://launchpad.net/~kicad-developers
    <https://launchpad.net/~kicad-developers>
    More help   : https://help.launchpad.net/ListHelp
    <https://help.launchpad.net/ListHelp>
_______________________________________________
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


_______________________________________________
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



_______________________________________________
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



_______________________________________________
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



--
 -Kristoffer

References

  Thread Previous • Date Previous • • Thread Next