eeschema prefers to use changed components from libs rather than using the cache

[Sven]

I just opened a schematic in eeschema and since the size of the capacitor component changed in the official library since I created the schematic, they all got disconnected: https://i.imgur.com/7cVBneA.png
eeschema should probably prefer using the components from the cache file rather than reloading the component from the library, potentially doing serious damage to the the schematic.

[Chris Pavlina (pavlina-chris)]

I agree. It's really annoying when you open an old project, the schematic libs have changed, and everything is wrong all of a sudden. eeschema really ought to prefer the project's local copy unless told to do otherwise.

Changing this requires adding a mechanism to force an update from library, of course.

I'll have a chance to work on this around Wednesday - will handle it if nobody else takes it by then.

[Callisto Pili (callisto-pili)]

It should good if one button one the file menu as the archive project does
tries to export the entire locally schematic, the pcb footprint and the 3d
libraries can be saved in a local project folder.
the problem arises when you have done different boards with NO changes at
the footprints even for the sch. the pcb and for the 3d libraries.

the right point is that when you have done a board with a standard
footprint a change of the global mainstream libraries in the future will be
a disaster when we try to load a old design.

an export libraries button AND an automatic reload if it exists on the
project folder would be the solution.
the exported components are only the components used.
.. a three folders should be enough to maintain a safe place for it.
:project folder
- lib_sch
- lib_pcb
- lib_3d

at least.

Callisto.
Il 23/Mar/2015 14:00 "Chris Pavlina" <email address hidden> ha scritto:

> I agree. It's really annoying when you open an old project, the
> schematic libs have changed, and everything is wrong all of a sudden.
> eeschema really ought to prefer the project's local copy unless told to
> do otherwise.
>
> Changing this requires adding a mechanism to force an update from
> library, of course.
>
> I'll have a chance to work on this around Wednesday - will handle it if
> nobody else takes it by then.
>
> ** Tags added: eeschema libraries
>
> ** Changed in: kicad
> Importance: Undecided => Low
>
> ** Changed in: kicad
> Status: New => Confirmed
>
> --
> You received this bug notification because you are subscribed to KiCad.
> Matching subscriptions: callisto
> https://bugs.launchpad.net/bugs/1435338
>
> Title:
> eeschema prefers to use changed components from libs rather than using
> the cache
>
> Status in KiCad EDA Software Suite:
> Confirmed
>
> Bug description:
> I just opened a schematic in eeschema and since the size of the
> capacitor component changed in the official library since I created the
> schematic, they all got disconnected: https://i.imgur.com/7cVBneA.png
> eeschema should probably prefer using the components from the cache file
> rather than reloading the component from the library, potentially doing
> serious damage to the the schematic.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/kicad/+bug/1435338/+subscriptions
>

[Wayne Stambaugh (stambaughw)]

Please do *not* attempt to fix this. This requires a change to how
schematic libraries are handled and/or a change to the schematic file
format both of which will be completely replaced during the next
development cycle. I will not allow any changes to the existing file
format before the next stable release. See my answer to this question
for a simple fix to the problem.

https://answers.launchpad.net/kicad/+question/263700

Please grep the developers mailing list for more information on the
upcoming schematic and component library file format changes. The new
schematic library management code will look very much like the footprint
library management code. Please do not reopen the discussion yet. I
will reopen it with a revised schematic and component library file
format document when we are ready to start on that. This will not
happen until after the next stable release and after I have rewritten
the schematic model code in Eeschema.

On 3/23/2015 9:53 AM, Chris Pavlina wrote:
> I agree. It's really annoying when you open an old project, the
> schematic libs have changed, and everything is wrong all of a sudden.
> eeschema really ought to prefer the project's local copy unless told to
> do otherwise.
>
> Changing this requires adding a mechanism to force an update from
> library, of course.
>
> I'll have a chance to work on this around Wednesday - will handle it if
> nobody else takes it by then.
>
> ** Tags added: eeschema libraries
>
> ** Changed in: kicad
> Importance: Undecided => Low
>
> ** Changed in: kicad
> Status: New => Confirmed
>

[Chris Pavlina (pavlina-chris)]

Well, this wouldn't be a file format change, it'd just be changing eeschema to prefer to load out of -cache when there is a component that appears in both libraries (and adding a command somewhere to push the libraries to the cache).

But fair enough.

[Chris Pavlina (pavlina-chris)]

What if eeschema were to test at startup whether the components in the two libraries differ significantly (in particular, have their pins in different locations), and then ask the user what to do? Seems better than silently preferring one over the other, and would be a small change.

[Sven (mail-sw)]

Good to hear this will be fixed long-term. I didn't really understand why the simple solution of just changing the preference order requires any significant changes anywhere, but I'll take your word for it if you say it does.

[Moses McKnight (mozmck)]

Wayne, don't you think a stop-gap measure such as one being proposed would be far superior to have in the next stable release than the current bug? Especially since the libraries keep getting changed (component sizes, locations, etc) and breaking existing schematics?

[Wayne Stambaugh (stambaughw)]

You are assuming that is what the user intended. I'm not sure that's a
safe assumption. There are times when I change a library component
because it's incorrect and I want to use the new component. Not the
version in the cache. If you always want to use the components in the
cache for historical reasons, you can manually insert the cache library
at the top of the library list or make a copy of the cache library and
use that instead.

On 3/23/2015 10:27 AM, Chris Pavlina wrote:
> Well, this wouldn't be a file format change, it'd just be changing
> eeschema to prefer to load out of -cache when there is a component that
> appears in both libraries (and adding a command somewhere to push the
> libraries to the cache).
>
> But fair enough.
>

[Chris Pavlina (pavlina-chris)]

No, I said that it'd be necessary to add a way to push library changes to the schematic. This is how most other EDA packages implement this.

My second proposal was to test for conflicts and then *ask* the user at startup. Your solution (copying the cache library or manually inserting it) isn't obvious if the user isn't familiar with how the libraries work, so it can and should take the time to explain what's going on to the confused user and possibly offer to do this for him.

[Wayne Stambaugh (stambaughw)]

Even this may not work. The problem is always going to be the library
search order. Even if user chooses the correct component and you load
that component from the correct library, you will have to manipulate the
library search order to guarantee the correct component is loaded the
next time the schematic is opened. Otherwise, you're right back where
you started. Changing the library search order will potentially create
it's own set issues if the user already has established a know working
search order. This problem is like trying to cut one head of Hydra, two
more grow back and now your worse of than when you started. There is
nothing that we haven't discussed or attempted before to resolve this
issue. We've known for a long time that the only way forward is a
complete rewrite. I do appreciate your enthusiasm to get this issue
resolved and no one will argue that the problem is not a PITA. However,
the short term solution is very simple and doesn't create any additional
unknown or unexpected component loading behavior.

On 3/23/2015 10:30 AM, Chris Pavlina wrote:
> What if eeschema were to test at startup whether the components in the
> two libraries differ significantly (in particular, have their pins in
> different locations), and then ask the user what to do? Seems better
> than silently preferring one over the other, and would be a small
> change.
>

[Sven (mail-sw)]

As a user, I agree with comment #7. My primary interest is that I can open a schematic and have it not break. Having to replace an outdated component from the library by hand is a far smaller issue (I even find it debatable whether that is an issue) than what currently happens.

[Chris Pavlina (pavlina-chris)]

Something like this:

"This project appears to use different versions of some components from what is installed locally. What would you like to do?

[] Update this project to use the new components. There may be parts that no longer fit correctly, and you will have to fix this.
[] Create a new library containing the versions of the components used in this project, and add it to the project.
[] Choose manually for each conflicting component
"

[Wayne Stambaugh (stambaughw)]

You still have a potential path search order issue even if you create a
new library from the existing cache library and make it the first
library in the search order. I'm not opposed to your changes it's just
that it may cause as much confusion as it resolves. While your solution
may work, it hides the underlying issue which may come back and bite the
user and you will have spent a lot of time for little net gain. As with
any behavioral changes to kicad, they must first be discussed on the
developers list. Not everyone follows the bug tracker. I can tell you
from experience that a lot of developers and users do not like nag-ware.
 Expect the response to your proposal to not be well received by these
folks unless you add a never show this message again option.

On 3/23/2015 11:02 AM, Chris Pavlina wrote:
> Something like this:
>
> "This project appears to use different versions of some components from
> what is installed locally. What would you like to do?
>
> [] Update this project to use the new components. There may be parts that no longer fit correctly, and you will have to fix this.
> [] Create a new library containing the versions of the components used in this project, and add it to the project.
> [] Choose manually for each conflicting component
> "
>

[Chris Pavlina (pavlina-chris)]

Okay, fair enough. Thank you for considering.

[DavidCary (d-cary+launchpad-ubuntu-com)]

Often I print out a schematic and verify that it shows a functional circuit. The next day I can't find that printout, so I make a fresh printout -- on a different computer, with more recent versions of the libraries installed.

As a user, I agree with Sven (#10): When nothing has changed inside the project folder, when I open the schematic file and print it out, the software MUST NOT make today's printout show a non-functional collection of isolated parts, as shown in Sven's original bug report.

[Wayne Stambaugh (stambaughw)]

A fix for this problem has been committed in the product branch r5623. While it is not the final solution, it gives the user a chance to recover the components in the library catch so the schematic does not unexpectedly change due to component library changes.