I forgot that vendor has more than one meaning.
I was referring to the IP identification scheme from IP-Xact IEEE-1685 known as VLNV.
Vendor is the organization responsible for the IP. Yours would be kicad.org
Library is the library name containing the IP (ex:Logic_74XX)
Name is the symbol name
Version would be 1.0
If you added this to every symbol up front then you would have the infrastructure in place to support:
Versioning
Duplicate Names
Extending symbols to external libraries.
@nickoe This is definitely a bug. I may have missed this. Please file a bug report so I can keep track of getting this fixed.
Hi @stambaughw,
thanks for the work!
With the old library it was mandadorty that symbol name and value are equal which was a big limitation.
Is this still valid for the new format?
@uschmelmer The value is the symbol name in the library so it has to stay the same. Otherwise, it could not be looked up in the symbol library table. Please clarify precisely what you mean by a limitation.
I just pushed a commit (e253862f) to remove automatically updating the legacy time stamps to true unique identifiers. It was obvious that this was causing more confusion than the potential for clashes between shared schematics. If there wasn’t an issue with the time stamp identifiers than converting them to true unique identifiers wouldn’t solve anything. You no longer need to update your board footprint symbol link as they will not be changed. If you already did this, there is no need to make any changes.
For example, I have two different symbols for the same part. They symbol name must of course be in the library, but I don’t like to see the difference - possibly a non-functional one, like “physical_pin_arrangement” vs. “functional_pin_arrangement” - in the schematic.
One idea for people working on migrating scripts is to use this parser: https://sexpdata.readthedocs.io/en/latest/
@stambaughw
I agree with @eelik . Having the same name for the library symbol and value is a big disadvantage.
In my company we use atomic symbols for resistors and capacitors, as the symbols
also contain information like supplier, suppliers order no. etc. So for example a 100 Ohm 1% SMD 0603 resistor, would have the symbol name 100R_1%_0603, but would have the value 100R.
A resistor 100 Ohm 1% SMD 0402 would have the symbol name 100R_1%_0402, but would still have
the value 100R. This kind of organization is not possible with KiCad.
Apart from that, what is the reason then to have two fields with the same content?
A client of mine (they sent me their library) solved the atomic approach with a text in the symbol with 100R. The text is shown in the library as a draw. Then they made the value 100R_1%_0603 not visible, the checkbox of the property “show” unticked.
Of course, I agree the natural approach should be to put 100R in a field, different from the symbol name.
That works as a workaround. There’s a small annoyance that the text color is different.
Surely is a workaround.
I must say that I didn’t notice how the symbol was made while I was making the layout.
I have checked it today, when I read this thread to figure out how it was implemented.
The colour of the text added to a schematic is different but if the text is built-in within the symbol it has the same colour as the body outline of the symbol (since I use the same colour for reference, value and body outline I didn’t notice anything odd).
I already said the natural approach should be a different field.
@pedro
Besides that this is a workaround, it also makes creating a BOM from the schematic more difficult, which
is one of reasons we have atomic symbols.
Sure. I’m not saying the opposite.
In their case creating the BOM was easy because the value was the real manufacturer part number of every single component. Yes, even for smd resistors and caps.
I don’t do that in my own designs because I don’t mind if a 1k 10% smd resistor is made by one vendor or another.
Please do not hijack this thread with discussion about anything other than the new file formats.
@rrascher The new file format will support atomic symbols. It just hasn’t been implemented yet.
What would that mean? KiCad already supports fully specified symbols which kind of already do what most people expect an atomic thing to do but allow the library to be scalable (as the same footprint can serve multiple symbols).
Or do you mean something like a higher abstraction layer. A data container that takes a generic symbol adds BOM info and connects it to a generic footprint and possibly a spice model (I seem to remember @Seth_h suggested something like this, whereas i kind of assumed the inheritance feature would allow for this without needing a separate data container). If so please don’t call this “atomic”. Atomic means one file has all the info in it (it is inseparable).
Edit: A full atomic file format might actually make sense. But not for the local library or even a company library but as an exchange format used to get library assets provided by a manufacturer into KiCad (would be nice if a user would download one file and get symbols, footprints, spice models and 3d models installed by use of only one tool).
Footprints can have a differing value field from the footprint name why should this be different for symbols?
A post was split to a new topic: Update PCB from Schematic warns that zones are not connected in nightly
@stambaughw its exactly what @rrascher mentioned. Having a unique symbol Like R_1K50_1%_0603_100PPM but with value 1k5 for readibility in schematic and layout.
What are the the “atomic” plans?
In Mentor Xpedition Enterprise we have the possibility of a unique “Part” (with unique inhouse partnumber and all values) and we map a generic symbol an layout footprint to it. that would be “THE” feature for kicad as professional tool.
Both uschmelmer and rrascher are writing about an integrated database system, and I’ve seen several discussions about that both here on the KiCad forum, and on the KiCad section on Eevblog. Apparently it is a topic that is very deer to a lot of people, and I’ve several times seen strong language as this would be a “must” for KiCad to be seen as a professional tool.
Personally I do not use this part, maybe I should not write this at all, however.
Why would such a database have to be in KiCad itself? Why not a sort of BOM script, that converts the parts list to any sort of database back-end you prefer. It also does not seem too difficult to extract schematic symbol data with such a script and build automated part libraries from that for “preferred components”. The amount of work for such an interface is peanuts compared to the total effort in KiCad and it’s symbol and footprint libraries.
If it’s of any use, I can spend some time to find some links to this database related stuff.