Standard symbol field names initiative

Community
43

I currently use several custom fields in my parts. I use house numbers and Manufacturer and MPN. The first one is to connect the fields with my BOM management system. The latter is as documentation. (and yes only one MFG and MPN because I want to know exactly which particular part I am using in the particular project, not all the possible options)

It is nice to have this as a standard. I am generally fine with whatever you guys end up deciding on. I voted on the polls according to my personal preference. At the end if it does not suite my workflow I will be able to customize it. So no harm done. :slight_smile:

Completely off topic: What I am actually missing the most are custom fields in kicad_pcb, and having them synchronized using netlist export from the schematic. When exporting centroid data for the pick and place machine I need at least the house number to be in the final CSV. Currently I have to use an external tool to merge BOM with the centroid data from kicad_pcb. It would be nice if I could just generate the needed data for the P&P without the extra leg work.

Overall I like the effort of trying to standardize some fields. Good luck! :slight_smile:

1 Like
44

Could the house part make sense added to the schema?

| Name            | Value          |
|-----------------+----------------|
| Manuf<Integer>  | <Manufacturer> |
| MPN<Integer>    | <MPN>          |
| Vendor<Integer> | <Vendor>       |
| SKU<Integer>    | <SKU>          |
| House<Integer>  | <House>        |
| HPN<Integer>    | <HPN>          |

Where <HPN> is a house part number. With all fields I am now thinking, putting 1 as an integer is optional. The House field wouldn’t striclty be needed either and could be left off but really all the fields are optional anyway. (I don’t think I made this clear enough before.)

The main issue I see with looking at this is that HPN is quite close to MPN and makes it harder to see at first glance.

45

That is why I call it Key in my system. As it is used as a Key for the “other” database. One could call it HKey, or PartKey? But for someone who is new to it all, and does not read documentation, that might not be obvious what it means. :slight_smile:

46

How about UID for “unique id” for linking to any external databases?

3 Likes
47

Sounds good to me. :slight_smile:

48

“UID” is a very generic abbreviation, there are many things that could have a UID : footprint, symbol, supplier, etc. It’s best used as a suffix, e.g. PartUid.

I would suggest “UPN” instead, although I use CPN meaning “Company Part Number”, but could equally be “Common Part Number”.

1 Like
49

+1 from me for “UPN” which can be regarded as User Part Number or Universal Part Number or Unique Part Number, depending on personal preference. This one identifier should cover the needs for everybody using external tools for parts management and might be more colloquial than using SKU et al.

While there might a gazillion use cases against having them, I’d like to see two fields for Manufacturer Part Number and Manufacturer (or Vendor and Vendor Part Number, or Distributor and Distributor Part Number, you get the concept) included as well, because that is what probably 99% of the hobby/not-for-profit users of KiCad will ever need and it saves them the hassle of creating the fields themselves.

Making life easy for the Newbies can only help in the proliferation of KiCad

2 Likes
50

It would only agree the field definition, it doesn’t mandate they’re used! The (blank) fields could be added to existing libraries with a simple script to “convert” them. …Or not!! Libraries can be left without these fields if desired.

The important thing is that if/when people/groups/projects choose to add manufacturer/part information to their libraries/designs that everyone uses the same field definitions. It’s a massive interoperability problem otherwise.

EDIT: this looks out of place because the forum doesn’t group/indent replies and I was replying to an older comment. Nevermind… Basically I think this is a great idea and heading in the right direction. My only two cents is I would prefer MPN1 MPN2 SKU1 SKU2 etc because they usually have a direct relationship. (SKU1 is only the number for MPN1, not MPN2). And having “MPN” and “MPN2” is just bizarre to me as this changes the format between the two fields.

2 Likes
51

Good point, I think this is what’s leading to most misunderstandings in the discussion about these fields (no matter how they are called): You are not obliged to use them but for them to be of any use, their name should be the same in all schematic symbols.

1 Like
52

It is slightly uglier but allows for compatibility with existing tools, e.g. KiCost. It could be argued that it is nicer for parts that only have one of each. It’s not really changing the format it’s just that the integer “1” is implied when omitted.

53

Yeah you’re probably right. It’s only a minor point anyway. Either would be a huge improvement.