Yes this is correct. Fields added via eeschema are not pushed to the library you need to add them to the symbol using the library editor and save the changes to the library.
The fields are not stored as part of the symbol but as part of the schematic. (On first placement they are copied from the symbol to the schematic after that they are independent.)
More detail: They are not connected to the symbol library reference but to the unique id of the placed symbol (otherwise you would not be able to have different field values for different instances of the same symbol. Meaning you would not be able to place two resistors and give one of them 100R and the other 1k as the value.)
I am sure in theory it should be possible to extract the current symbol fields on opening the editor but i think right now the editor takes the original library symbol not the one of the schematic. (The correct behavior could be argued in either direction depending on your current requirement. So maybe a request for being able to select which of the two?)
The fields are stored in the meta section of the symbol.
That’s true for the schematic file as it is true for the symbol library file.
Dropping additional fields, besides the hard coded ones is rather arbitrary.
Footprint or datasheet is on the same level as other custom fields like manufacturer or part number or house number…
I think I have to write a bugreport/wishlist entry for this.
It makes no sense to drop a fully defined parts meta information when it’s backported into the library by artificially deciding that footprint + datasheet information is different than the other stuff.
It makes sense to scrub the reference, but all else should stay with the part when it goes into the library from the schematic.
Another point is that there is no official way to curate the complete library to find parts that deviate from the majority setting.
If I create a custom library or several of them I would want to have a system in place that allows me to get all symbols up to the same status and find the ones who deviate with their meta information. @devbisme had written that import/export script to do this outside of KiCAD with a spreadsheet tool afai-remember… but that should reside within KiCAD.
PS: and yes, I know you’re not the right person to lay this onto
Especially as my field of expertise is the footprint side of the library not really the schematic side. Which explains why i do not know everything about that and can have misconceptions like anyone else.
I’m not sure what you mean by “with the caveat that the additional fields have to be created manually for each and every part that you create, not just the entries, but the full field description”
If I create a symbol with custom fields in my private library, then if I will duplicate the symbol to have another similar entry (like mulitple resistors with different resistance values), the custom fields are copied to the duplicate (in both 5.0.2 and 5.1.2).
I understand that when adding custom fields after placing the symbol in EESCHEMA, these custom fields will not be automatically added to the library symbol (kind of, in the schematic you edit only a particular instance of the symbol, and not the library item). But once these are added in the library, it seems to work for me.
That is actually a good workaround for a missing system wide symbol field templating system. Simply have a special lib that holds an empty symbol that only holds your field templates.
It might however really be cool to have eagle be able to give you the fields you desire for every new symbol added.
And of course to extract it from the schematic.
In v4 this only worked if the fields are being filled with something, they can’t be empty, or they get wiped when you save/reload the lib.
I used ‘_’ (underscore).
Now imagine… sometime down the road you want to add another field to those symbols, that you didn’t think of when you started your custom library.
Been there, done that twice
The third time I started to edit the libraries with a text editor, as this was before the script/tool by @devbisme had been available.
That is what scripts are for. Or even a moderatly powerful text editor.
Not saying that a feature like that would not be useful. but what should the field be filled with? If you fill it in eeschema anyways then i would not define it in the symbol but use the eeschema tool set for that. And if you want it filled in the symbol then you will need to do the legwork anyways.
Lets say I want to add a field called ‘optn’.
Right now I have to edit every symbol in the lib manually, add that field and fill it with something like ‘_’, so that it isn’t being removed when I save the lib.
Or I create script to go through the parts in the lib and add the field that way, also non-empty, as otherwise they are being wiped once loaded.
Or I use Dave’s script and do that stuff in a spreadsheet and import it back into the libraries.
But you have to admit that the editor above would be most convenient, as adding or removing a field is clicking on a button and adding the info is a breeze.
I’m sure this is what will happen anyway. The Devs are smart and some will want to use this themselves…
I get the wish for wanting to get filled out fields from the schematic into the library.
What i do not quite understand is why one would define fields in the library that are not filled out in the library. (That only hold a placeholder)
I would assume a better place to put such fields would be in the project template as they do not add any additional information when contained in the lib. (or is this not possible?)
Edit: I also split this part of the discussion away from the other one as it is kind of off topic over there.
The empty placeholder is only needed now, when you add those fields via external means, so that ALL symbols have that field with the correct Field descriptor (to avoid errors) when you want to populate it.
Once there is an Editor in the SE, there is no need for that at all, yes.
Well, I used this technique (adding new fields to symbols) with version 2013-4022 and both cache.lib and cache.dcm were generated correctly.
No datasheet information was lost. For aliases I didn’t mind since it weren’t anyone as it was an atomic library.
Came here looking for an answer to this topic.
You could define custom default fields in Eeschema and have them carried over when you create a new symbol in 5.0.2.
The custom default fields don’t even appear in the Library Symbol Properties. You need to exit out, go back to Eeschema, copy the names some where and paste them back in the Library Symbol Properties. Tiresome and open to mistakes.
In Library Symbol Properties, custom fields could at least appear in a separate listbox under the default fields and the user can add the custom fields by ticking and hitting add … or something of those lines
Current implementation seems to not take into account creating atomic part libraries
Atomic is the wrong word as it implies a single file or at least a 1:1 interaction between symbols and footprints. Use fully specified symbol library as i am sure you intent to have generic footprints. (symbol includes BOM information plus points directly to a generic footprint already in the library) Especially for things that come in standardized (JEDEC) packages. (Far more than half of all parts available)
Perhaps a little off-topic, but concerning the meta-data fields in the schematic mentioned above: I went through three field names before I settled on the one I want to keep. Is there some way to remove the old unwanted field names from continuing to show up in future generated Netlist files? I’m having a problem with my BOM under iBOM that I’m trying to troubleshoot and want to be sure those obsolete fields aren’t a contributor to my problem. (The iBOM problem is that at least one entire component doesn’t appear in my final .html iBOM result)
Edit - Just now see that the components shown in iBOM list seems to depend on which board layer is selected in that .html view (not helpful to my customers), so the urgency to my question is gone.
You can use KiField to extract fields from a schematic file into a spreadsheet, delete certain fields, and then re-insert the spreadsheet into the schematic.
