KiCad v6 has four obligatory (non-removable) fields in each symbol we create:
Is there a technical reason why none of them can be removed?
For example, in my library flow “Value” and “Datasheet” are of no use at all, and “Footprint” is not needed for some symbols.
Hello, these four fields are required for technical reasons.
As in any database, the reference is a clear point of reference.
The value is important for components that can have different values
You need the footprint to make a printed circuit board.
The data sheet provides the background information on the component, since there are also different manufacturers who produce the same components and can still have different characteristics.
You don’t need to fill out the fields if you don’t need them.
I’m guessing that part of it is for “historical reasons”
I once asked a question on gitlab about the Reference Designators (a.k.a “Reference” in KiCad).
KiCad has used “timestamps” for a long time to match schematic symbols to footprints, and now uses UUID’s as the primary method to match these. The RefDes is just easier for humans to read as an identifier, and yet quite some operations (Footprint assignment tool, ERC) do not work without the annotation of the RefDes fields.
The answer was that it would be a lot of work to remove reliance on the RefDes, and not much gain for users, so it is just left as is.
I remember that in an old KiCad version (V3 or V4) the “Value” field had to be the same as the symbol name in the library itself. The “Value” field is also a bit weird, in that it has the IC name for IC’s, but a text string with a “value” for parts like resistors, capacitors and inductors.
I am guessing that some prehistorical version of KiCad had those 4 fields for every schematic symbol, and that later the ability to add custom fields was added, and those first 4 fields were kept for simplicity.
If you do not change the code, it does not have to be debugged either, and there are plenty more important issues in KiCad.
Yes, I agree on not needing to debug the unchanged code, just was curious on the actual reasoning and, as in most cases, it seems to be just a historical convention.
@Lutz_Muller, you’re describing just one of the library workflows, not everybody is using the same workflow (e.g. mine is very different). And whilst “Reference” field should probably be kept mandatory it would be nice to be able to get rid of the other three as I see fit. Just a though 
I am not initmitely familiar with the KiCad source code, so I am just guessing, so keep that in mind.
Have you found: File Formats | Developer Documentation | KiCad
With KiCad V6 lots of file formats have changed.
It’s quite possible that you can just omit the datasheet and footprint entries if you don’t need them, and KiCad will add them if it thinks it needs them.
But I do advise to tread carefully here.
How much (and why) do those few default links bother you in the first place?
As I create my own generic libraries, fields “Value”, “Footprint”, “Datasheet” are always empty in the library. For most components “Footprint” will get its value from a database using KiField (and many more fields will be added to symbols in schematic as well), but “Value” and “Datasheet” are never filled and are always empty.
Generally speaking, it’s not an problem to have them in symbols, it’s just my preference to keep as least unused data as possible
FYI; I have found a lot of information in standard libraries is absoletely obsolute. (some of this may have been updated.) For example some bipolar transistors linking to a Fairchild semiconductor datasheet. So the link is broken. In my own library, will often put other information in there which is not a datasheet link.
Recently I have begun adding a new value field for resistors and capacitors. One value field contains the value that appears on the schematic “10.0K” for example. The added value field puts it in engineering notation; “10.0E+3” so I can easily sort the BOM values in a Libre Office Calc spreadsheet.
This seems a very bad idea.
Data should be stored in a single unambibuous location.
What if you change the value in the schematic,but not in your extra field?
Then they get out of sync and this may lead to real errors, or a lot of wasted time.
KiCad’s spice emulation (ngSpice) understands if you use 4k7 as a value for a resistor.
I think you are better off in the long run if you modify your BOM script to translate between different value strings if needed. It becomes more complicated if lyou also want to storre presicion and tolerances for the value. Then it’s going towards a database oriented approach.
Setting aside the Reasons, the Appropriateness, good Programming, the ‘Why’ we want to do what we do/want…
A curious user could look into the (user’s Text editable) Python code and see Seven (7) lines (in pcbnew) relating to “Reference” labels. Setting aside what a user does with them, that could break the code, they are there for a user’s ‘What If Tweaking’. I’m not saying these are all that’s involved but, could be starting point (for the curious user).
Where is Python code located? A curious User is only a few click’s away from finding it… I found them in 15 seconds.
I think that you are inventing problems.
First of all, a disagreement between the usual nomenclature (such as 4K7 or 4.7K) and the engineering notation (4.7E+3) will be obvious.
Secondly, it required only a few minutes to add/edit the additional information using tools>edit symbol fields (with symbols grouped) given that many of the component values are used in multiple locations. This is a quick and easy process! For the same reason, checking it is also quick and easy.
Third, I have the “usual nomenclature” appearing on the schematic in the usual way, but not the engineering notation. The “usual nomenclature” can always be the deciding value in case of any disagreement. The engineering notation is used only for BOM sorting.
I do. The data is stored in the schematic diagram (although not all of the fields need be visible.)
This sounds like programming. I do not do programming or scripts for KiCad or anything else. It is very easy to copy the BOM information from Tools>Edit symbol fields into my BOM spreadsheet. This method had been posted (probably in FAQ) once upon a time.
Finally, I am certain that my method does not suit everyone. But it is an approach which some other KiCad users might find helpful.
Hi, can you take a picture as the translation on Google is ambiguous, so I can’t figure out how you do it. Any suggestion new to me is welcome.
Do a context menu (left click for most people) twice. First “Select all” and then “copy”. (My trackball buttons are reversed so for me it is a left click.)
EDIT: I have replaced my earlier images with images from a different project showing columns “Value” and “Value2”. When you look at the schematic, you see only “Value” and not “Value2”.
Seems rather prone to errors and needs careful checking in a separate view. If you are fault finding you would need both BOM table and schematic to make sure all agree.
The view you see above is the controlling source for all the information. Is it possible for visible “value” in the schematic to differ from “value” shown in the screen shot? “Value” can control in case of any conflict. And for someone like me who thinks in engineering notation, this is a “no brainer.” I just do not see any potential issue here. Anyone choosing a 47K resistor value is thinking in engineering notation whether they are aware of it or not.
In a recent consulting gig, my client was using Altium. Their BOM (output from Altium) had many columns. (maybe 10?) Don’t ask me why they needed so many. That needed more care but IMO what I have in my situation is a “piece of cake.”
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
