KiCad nightly (v5.99): New schematic and symbol library file formats are now the default

So the plan is that you must keep with the latest Kicad version if you want future library support. That’s reasonable.

I noticed that you are adding symbol extensions (which are great) but only support extending the current library. The real power of extensions comes when you can extend any part from any library.

I would also suggest that since you are regenerating the entire library that you throw in fields for vendor name,library name and version. You may not use them now but they could be real handy in the future

Not with our current amount of recources. We need at least 2 or 3 more librarians before we can even think about investing in a second platform.

github has everything that we need. gilab really does not give us any benefit for our workflow as these two platforms are basically equivalent in feature set. (But different enough that we need to invest quite a lot of work to get it running)

1 Like

We don’t even come close to having the resources to maintain this stuff.

Plus the library info must be valid all over the world, and we can really not show bias to some vendor (So we can not have order info of digikey or any other such vendor in there and am really not certain what else you request)

1 Like

@Wayne, you mention that this also includes “new schematic library file format”, but when I create a new library and save it, I get a .lib file and the legacy content. Is this intentional, and just temporary?

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.

1 Like

OK, I created it and assigned you. https://gitlab.com/kicad/code/kicad/-/issues/4346

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.

3 Likes

@stambaughw
Thanks for the information. That’s good news, looking forward to it.