EEschema using OLD symbol that is not in library anymore

I am using latest stable build for Windows 2013-07-07 BZR 4022

Downloaded symbol SP3481/SP3485 but it had mistake the Vcc pin was numbered 7. I changed it to 8 and saved library.

But when I add the symbol to schematic, it finds old symbol somwhere and uses the one with Vcc pin = 7. Even if I insert by Select by Browser, it shows correct in the browser and then inserts old one to schematic.

I deleted library cache file, closed program. Same. Not sure where this symbol comes from Eeschema insists on. I even search all files in my project directory for SP3481, they are text files after all. It is nowhere. Where in the world does KiCad get the old symbol ?

:frowning:

I found out it uses SP3481 symbol from Kicad’s own interface.lib, which is incorrect and has Vcc pin numbered 7.

I have been banging my head and the problem is I specifically selected symbol from project local library called SP485.lib in the project\lib folder. No warning of symbol duplication, it let me select it from my library and then quietly used symbol from another library. The only way to find out which library symbol comes from is to edit and look at the window title.

This is partly caused by the fact that the list of libraries is parsed top to bottom. The first match is used, no matter where it comes from.

Create a custom library and make sure it is on the top of the list.

As far as I’ve “heard”, this issue will be fixed after the next stable release, in a similar manner as with the footprints. The schematic symbols will be incorporated into the schematic file as well.

2 Likes

Hi, Worm!
I had the same problem! But fortunately I found your post and wuala! It worked!

I just ran into this issue. I see this is an old thread so I’m curious if the issue is being tracked as a bug that I can follow.
@madworm, do you know?

I think this may have been reported before, at least once :grin:. As eeschema is currently being reworked, this will probably be fixed at some point: “when it’s done”.

1 Like

I just checked from 4.0.4 and the part in Interface.lib has the correct pin 8

Thanks for looking into this, @davidsrsb. I was referring to the issue where a library part is not updated unless the new library where the update is stored is listed above the old one in the library list.

We need library tests for duplicate symbols and footprints in the paths. Depending on the order in the list is asking for the kind of problems that you have had

Sorry, @davidsrsb, I didn’t quite catch your meaning. Are you asking for test libraries?

No, the problem is that there is no warning that a symbol or footprint name is duplicated in two libraries in the path. This makes it easy to edit the wrong one