Any plugin, etc that wants to deal with a part number (and does the plugin mean internal “house” part number, or MPN, or distributor part number, as you say?) will inevitably need to deal with the fact that users may prefer the field to be called different things. Even if KiCad proposed a standard, not everyone would be able or willing to follow that standard (for example, due to wanting to integrate with an existing system). Because of this, I think we are unlikely to push for standard naming of fields in any situation other than providing some kind of example setup as part of a tutorial. We should encourage plugin authors to provide configuration and flexibility here.
Reading a field with named “Foo” in application A and applying it to a field named “Bar” in application B is simple glue logic for plugins and/or ODBC scripts.
But…
That is a fair decision.
Why?
None of us got where we are because we guessed and stumbled upon best practices. You learned from others before we could even spell “professional”. I have been in electronics, hardware, software, manufacturing for some 40 years. I have worked for a bunch of companies spanning a range from consumer products to systems that go into orbit and even the International Space Station as well as owning and running a couple of engineering businesses.
What most good companies --one man shows or 3000 engineers in a building-- have in common, can be boiled down to one word: Process.
Not the same process. There are plenty of variants out there. However, for the most part, at the core, when it comes to hardware development, they are all very similar.
The things people with that kind of experience are saying here were not learned casually. Much like civil engineers have a process to follow in designing and building bridges and infrastructure, a process developed over decades, if not centuries, the core processes used in developing electronic products have a commonality that has evolved over time. In fact, some of the terminology we use today goes back even way before my time, to the 60’s and 70’s.
I have always, from a young age, taken the attitude that I should listen to those who might just have more knowledge and experience than me. Not because I am less than them. Rather because I want to learn what they know. Nobody is interested in sharing what they know with someone who isn’t interested in listening.
Now, this is an open forum and anyone is perfectly entitled to ignore anything and everything said here. That’s OK. It isn’t about “castes”, it’s about mentors being willing to devote a non-trivial amount of time and effort helping others learn and understand the engineering process as it has evolved over many decades. I go back to when we had to print or plot circuit board layers on D size paper to then have it photographed and scaled down to expose PCB’s during manufacturing. Lots has changed since then, and lot has survived the test of time.
To repeat myself: Semantics is very important. Values are not part numbers. That is the focus of the thread I started. If I didn’t think this was important I would not have bothered to invest this much time having these conversations. Not to be pedantic or divide users into “castes”, but because I genuinely want to check my assumptions with others and, in particular, learn from other professionals who have done things differently and yes, hear from hobby users and students in order to also get a sense of their perspective. From that comes understanding and from understanding come options that one might recommend as a potential path forward for KiCad.
1 Like
I have to think about this a bit. My first reaction is to disagree.
I think it would be OK and beneficial for KiCad to be opinionated so long as two conditions exist:
- The opinionated bits are well vetted
- There’s enough flexibility at the user level to express their own opinion in the form of changes
I want to keep this conversation on the topic of semantics. This, I feel, is seriously lacking from the standard set of fields shipped with libraries and baked into the software right now.
In the experiments I am currently running to gain a better understanding and devise a usable process, this is what my Symbol Properties looks like:
This is not enough to create a design you can actually build. You can’t even extract a BOM and drop it into Octopart to get some idea of pricing.
The opinion KiCad is currently expressing by taking this approach is somewhere between “we don’t care” and “you are on your own”. Or mabye “it’s just too hard”.
If I add just a couple of fields, “part_number” and “manufacturer”, all of a sudden the opinion being expressed is somewhere around “this is the basics you need to actually be able to build boards”. You can generate a BOM from this and drop it into Octopart with minimal effort.
The manufacturer is a necessary part of the primary key because there are components that require disambiguation. For example the 2N3904:
https://www.mouser.com/ProductDetail/Rectron/2N3904?qs=rrS6PyfT74dTuLo4YQnGYA%3D%3D
https://www.mouser.com/ProductDetail/Diotec-Semiconductor/2N3904?qs=OlC7AqGiEDlYMySw5i2rlg%3D%3D
While internal (house) part numbers linked to a database would obviate the need for this, what I am talking about here is a semantically useful standard set of fields I think KiCad should ship with and promote as a starting point for the benefit of all. Advanced users will do something different. And that’s OK.
Frankly, strictly speaking you don’t even need the link to the datasheet. It’s very convenient, so I would definitely include it as a good-practice place holder to guide folks into using it. However, if you have part number and manufacturer it would be a simple matter to add a button to use these two and “pdf” to search for a datasheet in a fraction of a second. I might even suggest providing the ability to populate one or more user buttons right next to “Spice Model…” that could be linked to user-designed functionality via Python. For example, we have a centralized repository of datasheets. I might prefer to first look there and then on the web.
A long way of saying that I think expressing a reasonable opinion on what an initial best practices workflow looks like is a really good idea. The alternative can become messy and frustrating.
Look at it a different way: You are looking at a whole new generation of designers and engineers that are going to come up using KiCad. Isn’t it worth the effort to at least shove them in the right direction in terms of starting out with a sensible process and standard practices? KiCad could do that.
1 Like
I understand you think about it this way, but I also don’t think these are the only options. The KiCad dev team’s opinion is more like “there is not one obviously right way to do this, so it is best to let users configure it themselves”.
There is not consensus that:
- Storing a MPN in the schematic should be done
- A MPN should be stored in a field called “part number”
Software design can fall in many places on a spectrum of how “opinionated” it is. Some software takes it to either extreme, for example many Apple programs have very little flexibility/configurability, and one “right way” to do things, and some other programs have near limitless flexibility at the cost of painful user experience. KiCad’s philosophy is to try to find a happy medium where the defaults are suitable for many users, but configurability exists in areas where opinions differ.
In this particular instance, our stance is that choosing and encouraging a specific schema for storing manufacturer part information is not a thing we can do in a way that will satisfy the vast majority of users. We instead opt for configurability here.
2 Likes
So, it’s a hobby tool then.
I don’t care what the field is named. It could be called “goofy” for all I care. Nobody builds circuit boards with the information that comes stock with KiCad. You can’t. And you also cannot build a board without a MPN. That is what we choose when we go out and buy a component. When all the smoke and bs clears out, we need an MPN.
Keeping it in the schematic and not in the library isn’t sensible at all. We don’t use components once. It has to be in the library and the part number, whether it is in-house or MFN should be the king of the hill, not the value.
Anyone who doesn’t believe or get what I am saying is invited to run through the following exercise. I searched for an active low pass filter circuit and got this from a page at Arrow:
Now, use stock KiCad and stock KiCad library conventions, create this circuit ONLY with the information given in the picture, generate a BOM and get it priced. Let’s ignore layout for the moment but do setup the footprints.
You can’t. Not if you are honest with the process.
For example, the top amplifiers, AD8622. Mouser shows 9 different options. And the second op amp another 9.
The resistors? Search Mouser for 2.67 K resistors. 642 to choose from. Did you assume they were 1%? Well, as it turns out they are available from 0.01% to 5%.
Get the point? The manufacturer part number (along with the manufacturer for disambiguation) is the most important bit of data for any component. And KiCad has no opinion on this other than “it’s too hard”, I guess. The fact that the library structure does not include “manufacturer” and “part_number” is incomprehensible to me. The only justification given so far is “do as you wish”. Which is an invitation for a mess.
I want to remain open minded because I am genuinely trying to move over to KiCad from Altium. Some things, though, are pretty fundamental. We don’t order values and we don’t order house part numbers. Without an orderable manufacturer part number the library is pretty much useless.
I really think you are wrong on this. You would not be dictating the one and only way to do it. You would be providing a sensible starting point that can take a circuit from schematic capture to sourcing, layout and manufacturing. By avoiding the problem what you have created is a situation --as evidenced by my challenge above-- where nobody can build a board if they stay within the strict confines of what KiCad ships with.
Another way to put it: If every single user has to add one or more fields in order to be able to make boards, you are neglecting something very important. What do you want to bet that EVERYONE who uses KiCad has to add a real orderable part number somewhere?
I just read this whole thread.
So many different opinions on what is wanted.
To me it seems a fifth field which links to a line in a spreadsheet that the user can setup as they wish, if they wish,would solve every ones problems.
Not sure if and how this would be doable, but is this worth a consideration?
My conclusion is that what OP wants is feasible already, and will get easier when DBs are linked in. The problem is that OP wants the developers to be more prescriptive. (This reminds me of the conundrum of the immovable object vs the irresistible force. I think IO wins because there is one way to do nothing whereas there are infinite ways to do something.)
But I say there is more than one way to skin a cat (ouch!). If all your suasion gives you hand RSI (and the readers eye RRI), then change tack. People are more likely to be convinced if it actually helps them rather than think yawn someone else’s problem. As an instructor used to say, people tune in to station WII-FM (What’s In It For Me). So I say, OP, give your engineers hand RSI developing an easy path towards a part_id field with a ODBC shim to connect to a DB, say PSQL, and migration scripts from libraries. One month tops Python programming, but you didn’t see me write that. If you get in early, and your software is popular, you get to influence the future. You even get to name the field. You’ll know you have suceeded when 9 out of 10 doctors prescribe your part_number_ization toolkit for headaches.
FOSS works better this way, when people contribute, and the best solutions thrive, rather than attempt to prescribe how the software should be used.
So here’s a little starter gift, a quickie script I wrote to learn JSON manipulation in Python. When applied to the eeschema.json file, it adds a part_number field.
#!/usr/bin/env python3
""" Add part_number field to eeschema.json """
import json
with open('eeschema.json', 'r') as eeschema_file:
CFG = json.load(eeschema_file)
CFG['field_editor']['fields_show']['part_number'] = True
CFG_STR = json.dumps(CFG, indent=2)
with open('/tmp/eeschema.json', 'w') as eeschema_file:
eeschema_file.write(CFG_STR + "\n")
(You will note that it is incomplete, it has to be run in the configuration directory, and also it doesn’t actually rewrite the file, it puts a new version in /tmp.)
in parts but serious overall.
I read the whole post too, i am still not sure how valuable those fields are for the official libraries.
@robomartin since you started talking about bets,
“part_number” and “manufacturer”
Do you think your proposed names suit everyones needs? I can raise that bet because someone will complain that a different name should have been used. But you can in fact (and this is freedom) to add any field, named as you want, to your custom libraries and use them. (Either manualy when creating the part, or have a script prepopulate those fields in the official libraries and derive yours from there.) As others already mentioned.
Again this is freedom.
I assume that you are ok with the rest KLC and those missing fields is the key factor to think of KiCad as a hobby tool. Am i correct? Well, i think your are biased here. You judged KiCad because of some missing libray fields? I think this gets out of scope…
FWIW, i know universities that used to “train” their students with cracked commercial software. The next generation of engineers has a lot of problems to solve… Good luck to them.
In any case, having MPNs to sort adds A LOT of work on top of the current situation regarding libraries, feel free to help with library maintainance. I do not think we can handle this ATM or in the near future. (I would be happy to proven wrong)
Best regards!!
PS: I understand the “power” of a habit, using a tool for a long time can cause that. It is a hard task to “forget”/change a workflow developed over time.
1 Like
IMHO, no fields shall be “baked in” or “standardized” (i.e. being obligatory), perhaps apart from “Reference” field.
Lots of people and companies use KiCad professionally already and I bet most of them have very different workflows (including component libraries organization and use) so KiCad shall not impose any restrictions unless absolutely necessary (e.g. a “Reference” field is absolutely necessary but the “Footprint” field is not, let alone “Datasheet” and “Value” fileds).
2 Likes
Footprint is also necessary; it’s part of the link between the schematic and the PCB. I agree Value and Datasheet are not necessary to bake in, although they are for historical reasons (we can’t really get rid of them at this point because too much depends on them)
Footprint is not always needed.
For example things like the company logo added to the schematic does not need a footprint.
GND and other power symbols also do not have a footprint.
You misunderstand: any given symbol does not need a footprint, but it is necessary for KiCad to define the Footprint field as fixed/standard for those symbols that do need a footprint.
I know there are 4 mandatory fields for schematic symbols and they have historic reasons.
To me it’s a (minor) flaw in KiCad.
My preference would just be an empty container with nothing but an UUID, and the rest would be optional, even the Reference Designator.
1 Like
This is my ideal as well 
Not sure why people are focusing on the name of a field rather than the functionality lacking out of the box.
At a fundamental level I don’t care what the fields are named. They could be named “field_1” and “field_2” for all I care. This would be sad, because they lack semantic meaning, but if that’s what you got you work with it.
Also, nobody is suggesting a fixed unmodifiable schema. Quite to the contrary. What I am saying is that today, out of the box, KiCad ships without fields to store a part number and the manufacturer, without which you cannot order a component. Try ordering a component from any parts distributor without specifying at least the part number and see how far you get.
And so, every EE, for every design in the world, throughout history, has to assign a part number and often select a preferred manufacturer before the board can be manufactured.
With KiCad, before the chosen part number and manufacturer can be inserted into the part specification, the designer has to manually add two fields to every component on the board. However, when you do it that way, these components are fully specified only within that schematic, not the library. You can do this conveniently in the schematic by using Tools/Edit Symbol Fields. However, if you want to do it at the library level you have to painfully make this change symbol by symbol…or figure out how to write some code to do it for you. And you have to do this for every single component you will ever use with KiCad.
The other alternative is to completely forgo the stock libraries (which most professional users are likely to do for a range of reasons) and create your own libraries from scratch. With work, the option exists to perhaps produce them with software by translating from existing company sources.
Even with this you still run into some oddities. For example, the value field being linked to the symbol name is interesting --not in a good way. I haven’t fully explored how this works but quickly browsed through a thread that discussed it. You can’t get rid of the other fields. The first four fields, “Reference”, “Value”, “Footprint” and “Datasheet” are mandatory.
I find it very interesting to see that “Datasheet” was deemed to be so important that it is mandatory and there is not the part number and manufacturer.
All of the above circles back to “All I wanted to do is store my chosen part number and manufacturer”. Instead, due to these fields lacking, any designer using KiCad has to choose from the above menu at some point in some way. This, to me, is a perplexing decision.
Can’t agree on the naming of the fields? Give people the ability to rename them to anything they want then. Don’t omit them. That’s the wrong decision… You can’t design boards without those fields, again, from my perspective, an incomprehensible decision on the part of the KiCad team. Having everyone roll their own solution isn’t, again, from my perspective, a sensible decision. I am thinking about this from the perspective of a newbie or a student. The BOM that comes out of stock KiCad is unusable. You can’t make a board with the stored information. How is that a sensible software design decision?
What are we doing? Well, I am committed to staying with KiCad for a year and doing a few designs with it before making a long term decision about dropping our Altium licenses. We’ve already done two. However the situation with regards to the lack of important fields isn’t sustainable. We solve this by creating our own libraries to add those fields. The problem with this is that the KiCad tools does not give these added fields the kind of importance the designer might want to attach to them. For example, the part number (internal or manufacturer), in most workflows, needs to be your primary key. Not so in KiCad, it’s the name given to the symbol. Etc.
For historical reasons, KiCad does not treat symbols as necessarily mapping to specific parts. A workflow where a symbol maps to a specific orderable part will be easier in the future.
In other words, “I know the One Twue Way, and everyone else must adopt it”.
I’m a professional software engineering consultant, specializing in embedded systems and low-level hardware interface. In my business, it’s very common for a company to design a custom hardware platform, smoke-test it, then hand me the board and the schematics and say, “Give it back to us with a running OS and all drivers.”
The last thing I need on a schematic is a bunch of manufacturer-specific part numbers instead of values. Yes, this information is critical for manufacturing, but it doesn’t help anyone understand what a circuit does (and, sadly, whether it’s properly implemented). Unless I’m forced to do hardware surgery, I don’t much care whether a resistor is an 0402 or 0804; but I do care whether it’s 10K or 10M. I don’t care whether an IC is ceramic or plastic, SOIC or SSOP; I do care what the basic part number is so I can find the datasheet.
I also do electronic design as a hobby. I don’t have a database of pre-qualified parts. After my schematics are complete I go through a component selection process, and add information to the schematic like manufacturer name and part number, vendor name and part number, and links to the datasheets. This is pretty much the workflow I see for small companies. KiCad supports this currently, and the roadmap suggests that support will improve.
It sounds to me like the OP needs to stop using the standard libraries and create their own libraries of pre-qualified parts containing their required metadata. That would solve their problem without forcing the rest of us to adopt their preferred workflow.
5 Likes
Having been reading this thread for several days, it is refreshing to read your answer. I never speak of myself, but being my age I’ve been doing this longer than most here have been alive. And seeing your message gives hope. Thank you.
1 Like
I would be just fine with that with one twist. Newbies and students need a sensible starting point. This starting point makes the software usable and it also teaches them something.
Because of this it should not come out of the box without libraries and without a sensible set of fields that can actually take a new user from installation to a board you can actually make.
What does this mean?
You need a GUID for technical reasons. The user does not need to interact with this value at the GUI level. It’s there, in the file, if manipulation is necessary.
You need a part number you can order. Remember, this is about being able to actually build a board out of the gate, without having to muck with KiCad in any way and do anything special. The part number is essential.
You need a manufacturer. This can be blank in most cases, but there are parts that have the same part number and multiple sources. In the real world, where you have to actually buy parts, the part number and manufacturer name are the two items you must have before you can even get a quote (the latter only being a must in some cases).
You need a value field. This only applies to a certain class of components, but it is important. Leave it blank for IC’s and other components or use it for some kind of a relevant note.
You need a footprint. No PCB without a footprint.
That’s it. You don’t need a “Datasheet” field. It would be nice to add it for convenience, but it isn’t a must. This could more universally be called “link” so you can link to anything, something on the web or locally in your file system.
And so, if you wanted to actually ship KiCad with a simple set of fields that actually allow someone to go from installation to making a board you need:
- Part number
- Manufacturer
- Value
- Footprint
- Link
Again, we are talking about the out of the box experience for a new user, not the configuration for a sophisticated user with coding capabilities or an organization.
I have been arguing this point for THAT user, not for me. I can deal with just about anything. I have a sense that this much has not been clear here.
When a new user launches into KiCad today, as is, and thinks they have a design they can build they are met with a cold bucket of water experience when they realize the BOM is useless and they cannot/did-not capture orderable part numbers in their design. The software, by design choice, out of the box, is made to be this way. I think this is wrong.
The scenario for professional users is very different. We are all used to the hoop-jumping that EDA can be. It’s just the way it is. This has not changed in decades.
However, you still run into a problem. These four mandatory fields are baked into the software and there are things like this linking of the value field to the symbol name, which I don’t fully understand yet. The KiCad team obviously thought this was important enough to have a strong opinion on these fields, yet no opinion on actually providing a place to store a part number you can order out of the box.
When I realized that a newbie or student cannot actually build a board with what KiCad provides out of the gate I was truly astounded. Such a simple common-sense design decision and it wasn’t made for fear of not making everyone happy? I don’t get it.
Does anyone think people would be up in arms if the stock install and libraries has “Part Number” and “Manufacturer” and the software gave these fields some importance? The only complaints you might get would be silly, like the name of the fields, other than that, everyone would use them. Because they have to if they want to make a board.