Continuing with the EEschema symbol library management disarray

Schematic
1

Continuing discussion of the issue I’m having. See the previous thread here

Ok, installed a new nightly build - no change. Well some change, but the same result. There is no Rescue Helper dialog that used to pop up first, but I still get a bunch of warning messages in the remapping dialog. Not all of the symbols turn into squares with question mark either. One sheet got probably around 20% of missing symbols, the next one - 100%. If I open the schematic by canceling the remapping process - all symbols are there but they all are opened from the project cache. If I open it with remapping, the symbols that open properly are still opened from project cache. Those symbols still have the old names, not the names which the remapping dialog claimed it would be. In other words +5V is still +5V not +5V-RESCUE_Project_Name. Again, if I reinstall the old stable version, everything works just fine, all the symbols are present and are opened from the proper libraries (my local libraries). When I install the nightly - all goes haywire (not to use the m word again)

So based on that may be somebody can answer the following questions for me:

  1. When you open an old schematic without remapping, is it expected behavior for the symbols to be opened from the project cache?

  2. What exactly should be done with environmental variables? Should I just delete all of them and install stable version to get them back to the previous known state? I should be able to edit them directly from KiCad or no? My understanding is that if I go into library management and there all my local libraries are present, then the symbols should load from those libraries, regardless of other environmental variables… or I’m just being naive here.

  3. Where do those new rescued symbols are supposed to be saved to?

2

To be fair, you ask some interesting questions which I am not 100% sure on, and it appears a lot of other experienced users are not entirely sure either, the remapping process adds a straw that tips easy understanding into the brink. (As a developer (but not on KiCad) this raises flags about the UX which I would try to address if it was my code, but it isn’t).

Firstly, some sensible, practical advice that doesn’t imply any moral judgment, pointing of fingers or anything : for people who just want to get stuff done but still with latest features without having to understand in-depth KiCad internal behaviour, the sensible thing is to use a recent nightly build that predates the new symbol library table. Wait until the code has been fixed, tested and polished some more and come back to it when a) it works better b) there is a wider understanding of the features and how to use them.

Short answer : “It depends”.

Long answer: * (as I understand it)

To recap, the project cache lib is written when the schematic is saved. A copy of the symbols which can be found from the libraries that are on the library search list are written to the project cache lib. Note: the project cache can be incomplete or empty if symbols were not found.

The project cache lib is automatically added to the library search path when you open a project, if the project cache library file exists. The project cache lib is a sort of automatic, behind the scenes backup, but it can get broken. In particular, the project cache lib is overwritten with the current schematic symbols every time you save the schematic.

In the case where the cache symbol is not the same as the symbol found by library search, then the symbol rescue kicks in. The symbol rescue creates a new separate project rescue library which contains copies of the symbols in the cache lib (if selected by the user).

I think the fundamental historic issue is that the schematic can get easily detached from the original source libraries, without the user realising. There is no quick and easy fix, the symbol library table is a step on the way to an ultimate fix. 

Really before remapping, you need to start with a project in a good state: the remapper can't really guess what to do if data is absent. I did think about writing a "schematic health checker", but never got around to it.

It took me several tries to get a good method of upgrading pre-v4 projects to v4, including library symbol changes and the switch to footprint library tables. It's quite a long manual process which would be difficult to automate. I expect the same to be true for the symbol library tables, I am not at all surprised there are teething problems with the new code and that people are having problems.
3

Thank you for the info. Just to clarify something - when I go back to the release version of KiCad the schematic opens just fine, all the components open form the corresponding libraries (not from project cache) and everything looks fine. All the symbol libraries that I use are local. I don’t add to my project any standard KiCad symbol libraries.

4

This being a bit of a charlie foxtrot is a known issue — I would suggest waiting a bit as there are still more fixes for this in the works.

5

How do you know that?

6

Ok. I think I figured it out. I kept simplifying the test setup and by the end there nightly would do really weird stuff. It would literally open the schematic with a few warnings and just one missing symbol, then I would exit without saving and open the same schematics again and it would give me a whole mess of warnings and every single symbol would be a question mark. At this point if I exit without saving and open the schematic with the release version KiCad all the symbol libraries would be missing in the list and I would have to add them again! That’s with not a single save of anything!

I finally managed to open the original project with a nightly build and convert all the components properly. To do that I went into the project folder and manually deleted ALL the files and folders except for the schematics, board file and the project file. After that everything worked. If I was a betting man I’d say it was something to do with the cache and rescue folder that the new version was creating and accessing.

7

Yes of course, if the remapping fails and leaves the project in a mess, you need to clean up the project to its original state before running the remap again. Otherwise you are recycling bad data. That’s why I said you need to start from a good state.

8

I guess my definition of a project in a good state was making sure that all the symbols open and are assigned properly in the previous version of the software and all the required libraries are added. I guess between that and editing schematics files with a notepad, deleting files manually is a glass half full (…or empty, depending on your point of view) :slight_smile:

9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.