Proposal for adding virtual fields to schematic symbols

[paulvdh]

Edit (again) / Prequel.
I just noticed this is already implemented in KiCad:
Schematic Editor / Preferences / References / Schematic Editor / Field Name Templates
I became aware of this feature via: Fields defined in Field Name Templates not usable in Symbol Editor (lp:#1824471) (#2382) · Issues · KiCad / KiCad Source Code / kicad · GitLab

---

The Idea is to have a list of field names for schematic symbols, and when you view the properties of a schematic symbol, these fields are always present, so you can easily fill them in with data such as for example part numbers, price info, personal notes.

KiCad would then add those fields to schematic symbols if the data is filled in, and this data is persistent when you export the schematic symbols to a personal library.

It is a bit similar to adding a new column in Schematic Editor / Tools / Edit Symbol Fields / Add Field, but with a few differences:

• KiCad will have a few pre-defined names and a method to edit / modify that list.
• Those fields are always visible in the symbol properties of each symbol.

Because KiCad would then also have a list of these pre-defined names as defaults, it encourages use of these field names and it is easier for BOM scripts and such to extract data from these standardized field names, and this would make the BOM scripts more efficient.

This method is also very flexible and is future proof.
There is work being done on Database integration for KiCad V7. Especially bigger companies have databases with carefully vetted atomic parts (schematic symbol + footprint + Other meta data) and such a database is very valuable to them. With this proposal you can modify the list of “virtual fields” to match the database keys, and this eases integration of KiCad with such a database. It would allow to fill in the database fields directly from KiCad’s Symbol Editor.

This is a bit similar to the idea in the thread below, but it does not need any modification to KiCad’s libraries, and it’s much more flexible then just fixed field names.

Semantic problem with KiCad component treatment?

@dennischi wrote: an example about different field-values for a multi-unit-symbol where all fields should have the same value. … This is clearly not right… The current situation arises because the software does not attach any semantic meaning to the part number added by the user. two point from this quotation: “This is clearly not right” —> agree. but the conclusion is false. This situation is not caused by the use of user-setable fields. This is a simple bug. You can provoke this situatio…

---

As an extension, a method to (batch) rename the field names in libraries can be added. For example, Digikey has released a library, and this has manufacturer part numbers. If Mouser, RS, Ti, Yageo, etc, wants to release a similar KiCad library, then it’s quite possible they use different field names for the same data. Batch-renaming of the field names will also make it easier for people who have their own vetted and trusted database and want to use KiCad to add new parts to it. In an Ideal word, everybody would use the same semantics, but the next best thing is to have translation tools in place.

Edit:
This fits also perfectly with this gitlab issue:

Make it possible to mandate a symbol property (#9550) · Issues · KiCad /...

[jmk]

@paulvdh

• KiCad will have a few pre-defined names and a method to edit / modify that list.
• Those fields are always visible in the symbol properties of each symbol.

Because KiCad would then also have a list of these pre-defined names as defaults, it encourages use of these field names and it is easier for BOM scripts and such to extract data from these standardized field names, and this would make the BOM scripts more efficient.

So, is this correct:
You are suggesting Kicad be shipped with a number of extra pre-named Fields with an “include / don’t include” box to go with, or instead of, the existing “view” and “URL” boxes?

Do you still want the ability to make your own Fields also, or will this become redundant?

[paulvdh]

@jmk

So, is this correct:
You are suggesting Kicad be shipped with a number of extra pre-named Fields

Yes, A standardized name (for example for a part number) can help with the BOM scripts, because most users will use these names and just fill in the value field. I think KiCad already comes pre-configured with one name in the Field Name Templates section, but I am not sure, because I modified the list.

@jmk

an “include / don’t include” box to go with, or instead of, the existing “view” and “URL” boxes?

Currently these Field Name Templates are global and exist for all projects. If this list becomes longer, then a per- project setting of whether a global field template name is visible in a project seems sensible.

Currently there is a "Visible" and an “URL” column in the Field Name Templates:

I’m not sure yet of the details of how these work.

@jmk

Do you still want the ability to make your own Fields also, or will this become redundant?

Yes.
KiCad must be able to adapt to the workflow that the user wants.
By default it could have names that work with the BOM scripts.

If a user wants to use other names (for example for database integration) then he can use other names in the Field Name Templates. As a consequence this will then break the BOM scripts, but it’s his choice, and if he uses a database, the simple BOM scripsts probably are not of much use to him anyway.

[jmk]

Sounds good @paulvdh

To me, it then seems a very short step to make at least one of these Field Name Templates (say, Part No.) linkable to an external spreadsheet (or existing data base)… whatever would suit the particular user.