IMPORTANT: Symbol Library Table Merged into Development Branch

Exactly, it was a problem with a MCP (Microchip) and in the older library, before 10/Nov/2017, they used “_” instead “/”.

About the script, yes, could be made. Even step 4 tp 5 is just to create the file “sym-lib-table” in the content:
(sym_lib_table
(lib (name Project)(type Legacy)(uri ${KIPRJMOD}/myName-rescue.lib)(options “”)(descr “”))
)

Yes. You can test this by simply creating a new project from KiCad.
Open the project (.pro) file of the newly created project with a text
editor and go the end of the file. You should see a section entry:

[eeschema/libraries]

There should be no “LibName1=some_lib_name” entries after this section. This will only be an issue if you use a custom default “kicad.pro” file from a non-standard installation path using the KICAD_PTEMPLATES environment variable.

If you followed step 1, then this step wont be necessary. I fixed an issue with the rescuer which should mitigate this issue but this step is the safest way to do it. I was trying to make sure that there are minimal issues with the remapping. I would rather the remapping be accurate as possible. The remapping will only add one additional entry into the project symbol library table in this case since nothing should require rescuing.

1 Like

Thanks for the clarification and confirmation Wayne.

As I make heavy use of custom libraries, and for my own libraries have used a mostly one symbol per library approach, all residing in a folder “own_libs” under my home directory (I also use a custom location for the official Kicad Libraries all stored locally etc.), I am interested in what to expect forward with respect to how things will be organised when also the new symbol format will be introduced in ver. 6 (if that has been decided yet). Can we expect the equivalent of the “pretty” format for the footprints where each library is a folder, and each symbol is a different file?

(My number of custom libraries and projects are still at a level manageable for manual reorganization, so this might be a good time to think about how things will end up. If a one symbol per file approach is expected in ver. 6 then my current strategy might be redundant and create unnecessary overhead.)

[In the official KiCad library there is a “symbols” folder with files having a .sym extension. I wonder if this is related to a new file format, or what they are?]

1 Like

This has nothing to do with the new lib format.
As far as i can tell these are just exported graphics. (Symbol editor right toolbar has an export button. This button exports sym files.)

Thanks for the information, Rene, no need to wonder about that one any more.

I’m trying to follow and understand this thread and the whole library system, to no avail. I have a couple of small projects and finally I had to fix them manually by opening the symbols from eeschema using right click on symbol -> Properties -> Edit Properties -> Component Name. I found out that when the automatic rescuing succeeded the name is in the form library_name:component_name instead of just component_name. And both the lib name and component name are “rescue”-something. That works but doesn’t look nice so I changed them manually even for the components which worked after the automatic process (and mostly they didn’t work). First I of course had to fix the project-specific libraries in Manage Symbol Library (Schematic Library Tables).

Then I started to wonder why this two-stage (or three-stage, or four-stage, depending on how you look at it) process at all in such a way. Basically what I want to have is libraries I have used previously in my project to be used in a new way, and the components I had to be prepended with the new library names. So that intead of having

/path/to/my/library/folder

in the symbol library manager I would have

/path/to/my/library/folder/libname.lib

And in the schematics instead of

symbol_name

I would have

library_name:symbol_name

And I wonder why that can’t be automatic and why there are two dialogs which then convert my symbol libraries and names to the form which has “rescue” in them instead of just having one dialog and automatically changing old symbol names to new library:symbol names.

But I never understood the library system to begin with and didn’t get it to work like I wanted. In the new system it seems to be easier with new projects. Previously I ended up adding new libraries in the old Component Libraries dialog directly by adding a User defined search path, instead of first adding library folders in the Manage Symbol Library (Schematic Library Tables) dialog. Maybe that messed up the migration system so that rescuing didn’t work well.

And if you didn’t notice it already, I didn’t understand almost a word about the directions given in the blog post.

Anyways, KiCad is going into a good direction, it’s exciting to learn to use it and to follow where it’s going and I wish I can help development in the future.

1 Like

Thanks a lot for the user friendly Remap Symbols tool. This is making this transition very smooth even with a non standard configuration user case! :smiley:

1 Like

Yes, the new symbol library file format will be similar in design to the current footprint file format. Symbols will be one symbol per file for the most part. There may be some exceptions.

1 Like

Rescuing is not remapping. Rescuing occurs when the symbol in the cache is different from the same symbol found in the library or the symbol in the cache cannot be found in any library. Remapping maps the library symbol links of the schematic symbols to the new library table.

Prior to my commits on Friday, the symbol library table dialog had no effect. It was just part of an incremental development path.

2 Likes

Windows nightlies are fixed.

4 Likes

Are more than one path to symbol libs respected?
(In other words more than the standard KICAD_SYMBOL_DIR path?)

You can use any environment variable you want for legacy plugin entries in the symbol library table as long as it is a valid absolute file path. The legacy schematic plugin only supports file paths, not urls.

After spending some time to reorganize my custom libaries the last weeks, I finally got to test this in a VM. I cannot say I got hildogjr’s manual method above to work. What did work very well for me is (two distinct strategies):

  1. If all links to the symbol libraries are up to date in the project (typically for the latest version of a recent project), make sure only the libraries in use are are defined for the project in the old version so that the correct libraries get linked. Edit references to these libraries manually into the global sym-lib-table. Then open the schematic in the new version and when loading the project use the remap symbols tool , which then works beautifully. Make sure to save the schematic after the conversion, otherwise one gets into trouble.

  2. For archival purposes of older projects and/or where the the link to the original libraries may be broken (this refers to point 5 in the blog post),
    a) while still using the old version, copy and rename the copied *-cache.lib file for the project to “project.lib” (or a name of your choice).
    b) Copy a sym._lib-table file with the following content into the project folder (assuming you named the library “project.lib”):

(sym_lib_table
(lib (name project)(type Legacy)(uri ${KIPRJMOD}/project.lib)(options “”)(descr “Legacy Project lib.”))
)

c) Still in the old version with the project open in Eeschema (do not perform any rescue when opening), delete all the links to the libraries under preferences- component libraries. Add a local reference to “project.lib”. [It is also possible to execute the step a) above in the file dialog]. Upon pressing OK in the component libraries dialog, if there were any broken links to libraries, this will now appear to be fixed (provided that the *-cache.lib file was up to date). Close the schematics (no save needed).
d) Open the schematic in the new version and use the remap symbols tool upon opening. This should now work flawlessly. Make sure to save the schematic.

A further comment: I tested this with the Nov. 25 nightly (pretending to be patiently waiting for the Windows nightly to get updated again :wink: ). With this version if getting into the rescue dialog when opening the old schematics, the rescue will not automatically cause the rescue library to be added to the project. It is then important to skip the remap upon opening the project, then add the rescue library as a local library at the top under Manage Symbol Library Tables, and finally use the remapping tool from the tools menu before saving the schematics.

Late edit: Note that paragraph c) belongs under 2. above, the quotation messed up the formatting

1 Like

When will I be able to force an update of all symbols in a design from library?

Propagate changes made in symbols/part library like text properties added/changed for example.

In layout you can force refresh of a footprint and also all footprints when reading the netlist.

Eeschema also need this functionality.
Libraries constantly gets maintained and bug corrected etc.
This must be able to push into old schematics.

A global refresh would perhaps be somewhat risky? But an equivalent to the Exchange Footprint function of PCBnew could be very useful. Already now, a number of features are updated in the schematics when the corresponding symbol in the referenced library is updated. Metadata remains though. However once symbols will be stored together with the project in ver.6, there will be more need for these kind of functions.

In pcb_new the footprints are really stored within the pcb file. This is not the case for eeschemas symbols.
They are cached in the so called cache lib.
If a symbol changes in the library, kicad will ask you if you want to rescue the symbol or use the symbol that is currently in the lib. (If kicad detects a change between the cached symbol and the library symbol)
This dialog should pop up as soon as you open the schematic.

But remember in kicad v4 symbol names need to be unique over all libs. Kicad will take the symbol with the specified name from the lib having the highest priority. So if you change a symbol from the official lib and safe it in your own lib, kicad might still take the other official symbol. To go around this make sure your personal lib is near the top in the component libs dialog.

yes,

this wording “rescue” is a very confusing one, i wish that could be changed one day.

on to the topic.

metadata is not updated.

you will manually need to add same part again from lib, give it the same refdes as the old one,
given that you know which ones has changed and can keep track of that , and being willing to repeat over and over again.

of course its completely unacceptable.

this is actually a very important feature, not lacking in any other e-cad tool i have worked with.
(cadence, orcad / mentor, design capture / dx design )

? if i change a symbol in the lib and don’t rescue it (unselect the tick mark for that symbol in the rescue dialog) -> it is updated in the schematic. (Behavior of a 2 year old nightly. And of 4.0.6 under fedora)

My test documented. After i change the symbol in the lib and save it the rescue dialog opens automatically. (You can also start it from the menu if it does not open)


I then tell it not to rescue my symbol which results in then new library symbol in my schematic

(Note that the pin CANL did indeed move in the schematic.)

including your metadata fields ?

the text fields you add to the symbol/part ?
footprint being one of the fields
and much more you can add, like manufacturer, tolerance, rating etc etc

i doubt kicad even will notice you have done any changes to them.

so the refresh/reload of symbols should not be a pop-up question from kicad about rescuing, it should be an option in tools or somewhere to refresh design lib so you can do it at will, not when kicad thinks he found something.

ps
I never rescue.
ds

also most if the time when you edit a symbol and keep schematics open at the same time kicad will just refresh the symbol in schematics without any questions about rescue.

but text fields will not be updated and for some of us that metadata/text in the library is mighty important.