Well, I was seeing things from my point of view. I keep my own libraries, I’m the only one that make changes. And I never update my libraries from github. I download the offiial libraries as a starting point to make my ones.
I had not thought about “automatic” update. I see the current behaviour is potentially dangerous.
KiCad has always done this, it does not store copies of the symbols in the schematic. It is planned to rewrite eeschema file format, so in future it probably will, and then will be consistent with pcbnew, which stores copies of footprints in the pcb file.
When you save a schematic, the symbols used in the schematic are copied into the -cache file, and I think the idea is that it is then a project specific reference copy for the schematic.
If you move the cache lib higher up the library, then symbols will be loaded from there in preference to other libraries. Unfortunately, you then can’t refresh the cached symbol from the original library unless you re-order the libraries again.
Yes, KiCad library management leaves a lot to be desired. Other projects starting from scratch can implement a clean architecture, but with KiCad you have all the legacy files to support. So, no easy way forward but incremental improvements.
This was possible in V4 and I grew accustomed to it. V5 does not support this anymore.
As I understood it the “-cache” library (in KiCad 4.0.7) is meant to be able to make backups or use your project on a system where no libraries are available.
I find changing library symbols pretty annoying, especially when opening an old project and I very much prefer all symbols to be part of a project.
What I usually do (for each KiCad project).
Remove the “-cache” part from the cache library.
EEschem -> Preferences -> Component Libraries -> (single) Click topmost lib in: “Component Library files” -> Insert Button -> Browse & ad your project lib (without the cache part).
Libraries are searched in the order they are listed that list, so this will make all your existing symbols (copies from other libs and modified symbols) the default.
If you add a new symbol to your project the “-cache” lib will re-appear when the schematic is saved.
You can then delete the old project.lib and remove the -cache from the newly made project-cache.lib.
It is a bit of a kludge, but it is reasonably easy to work with after you’ve done it a few times.
I have just been experimenting a bit with the way BobC-s suggestion of just adding the project-cache.lib to the top of the included libs.
It also seems to work, and there seems to be no need for the renaming of the -cache part.
I actually quite like the idea of the project-cache.lib file
As an alternative for reverting a (modified) symbol back to the default you can:
EEschem -> Right click on component -> Edit Component -> Edit with Library editor -> Garbage bin Icon.
This removes a single component from the library and then EEschem will search the default libs for a replacement.
You are right, my mistake! In v5 KiCad keeps the lib name in the schematic, so the order of libraries does not matter. That is a deliberate change to avoid the problem of symbols with the same name in different libraries.
I’ve practised this while I was on V4 and the only trick was if you wanted to update the symbol, you had to delete every instance of it in the schematics and save the project. This caused the symbol to be removed from the -cache.lib and you could then insert updated version of it. Of course you could not have old and updated version present at the same time.
I don’t know how I’ll make my projects portable under V5, so any ideas are welcome.
Perhaps a script to rename symbols to cache lib, and also to refresh symbols if they have changed.
KiCad had an “Archive project” function, which zips up all the project files. It might be useful to have a “Make portable” function, which creates a standalone project.
Yes scripting seems the only way to go. the trouble with scripting is that in general it is not portable, as you can not count on anybody else having the same scripting tools. As I need to support also less tech savvy user this is a bit of a conundrum how to implement it.
The easiest way would be to have an action plugin in pcbnew. Installing it is just a copy operation, which most users can do and then they only have to deal with GUI. Though it is strange to have a function to archive a project available in pcbnew, not in KiCad manager, but I think it is the only way that is portable across users and platforms.
Does kicad really update the symbol without asking first? I thought if kicad detects a change, the rescue dialog comes up and asks if you want to update the file or copy the one from the cache lib into a rescue lib. (Does this not work in v5 anymore?)
At least Kicad updates the schematic without asking if you modify the lib while you are working on a project.
I have not checked waht happens to toher projects using the same library.
Yes if you use “edit symbol in the symbol editor” from within eeschema then it is updated automatically. (This does not happen in my older nightly when i start the symbol editor from the kicad main window. If it does, you might want to create a bug report.)
But lets be honest if you launch it from within eeschema. You tell kicad to edit this one instance that is currently in use in the schematic so i would expect this behavior. (You might not expect that this updates the lib. But that is a different story. Related to the lack of symbol storage within the schematic file format.)
Something similar happens to footprints when you use edit footprint from “within” a footprint placed in pcb_new. (For footprints at least the original lib is not activated. It requires additional user input to change the lib in this case. There is also a clear “update in pcb” button.)
Yes, this is the behaviour I expect. So far, so good.
True, it is a different story. The fact is the library is really updated.
I have just checked with other project. The library is updated and the next project I have opened has also been updated without asking.
This is potentially dangerous, but knowing how it works the danger is reduced.
Let’s hope the new symbol management of v6 will be like the pcbnew one.
I do not use KiCad much, but I’ve grown quite attached to the -cache library after I discovered I could put it at the top of the library list.
The library symbols from -cache are also easily editable with the library editor (In 4.0.7).
I tend to find a symbol in some library that is often quite close, but not exactly right. put it in the schematic (-chache) and edit it with the library editor to my liking.
To me the integrity of a working and correct schematic / pcb is much more important than some general library with symbols which gets updated randomly.
I would really hate it if the libary name of a symbol becomes a part in the schematic and that has precedence.
In my world, at the moment a symbol is drawn in the schematic it becomes a part of the schematic.
After that it should never ever change without manual intervention.
Can you imagine writing a C / C++ (or other language) program and on some day you noticed that some script changed your source code because a library changed?
On my linux box the default libraries are read-only. What happens when I want to edit a schematic symbol with the library editor?
I also prefer the -cache library above integrating the symbols into the schematic. Keeping those separated keeps the file structures simpler.
A KiCad project already is a bunch of files. Project, schematic, pcb, possibly netlist, gerbers, etc. I see no advantage in reducing the file count by one.
I can see some logic into archiving a whole project into a single file, like .epub books (zipped html with some changes) or like LibreOffice does, where files are also openable in an archive manager.
[quote=“pedro, post:15, topic:10058”]This is potentially dangerous, but knowing … [/quote] you can remove the “potentially” for me. Integrity of a schematic / pcb should ALWAYS have precedence over some library.
Yes the schematics symbols handling has room for much improvement.
This is exactly how the V5 will change the schematics and the -cache.lib, so the workflow you describe will not be directly possible any more. From my perspective (as I used somewhat different workflow than you) the biggest downsize is that this will make harder to make project portable. I am working on it, so if you are interested watch the Kicad V5 portable project thread.
But V6 is promised to behave as one would expect it to. Can’t wait though.
Potentially dangerous for a former project using the same library
Yes exactly. You tried to be carefull and double checked if your schematic was ok. You archive it on some backup media, and 4 years later you discover that half of the library symbols you depend on do not exist anymore.
[quote=“MitjaN, post:17, topic:10058”] the biggest downsize is that this will make harder to make project portable[/quote] I think archivability is a more important factor than portability. (Opinions may/will vary). If you have a portability issue you can often solve it, by re-creating an e-mail or updating a github repository.
If you have an archive problem it may take a lot of time and effort to re-create your work.
Just imagine the schematic symbol for a single 700 pin BGA “missing” in your schematic.
Automatic symbol updates may seem convenient while working on a project but are a real danger to the integrity of a circuit. So I am definately interested in the “Kicad V5 portable project” and keep an eye on it.
But I have to finish some KiCad 4.0.7 projects first before I even dare to install KiCad 5, even if the official version is released today.
Good choice.
By the way, I have a copy of 4.0.7 and a copy of nightly 5.0.0-rc2-dev running in the same machine.
I always do portable versions of my projects even if I’m not going to send the project to anyone. Every finished project has a folder called libraries with a single symbol library, a single footprint library and a single folder with 3D models. They contain only the stuff related to this project. No chance to unwanted update.
We should define those words, as I really do not see much distinction.
If project is portable, this means that anyone using same KiCad version can open the project regardless of their library setup. Which can be even the same person who created the project in the feature, where they have changed, rearranged and partially deleted libraries. So archived and portable are semantically very close (at least to me, but anybody can correct me if I have this wrong).
How do you get KiCAD to create those libraries, and then how do you get the schematic and layout to point to them? (I can do those tasks via a text editor, and some folks can probably write scripts that do the job, but I’m looking for an easier way to create such a self-contained archive.)
Dale
Depending on how you look at it portability and archivability can have a big overlap or be very different.
I wonder if git would be a viable option for “portability”. Would it be a good idea if multiple people are working on a KiCad project and synchronize their changes via github?
If certainly seems doable to push your home project to github in the evening and continue working on it in the boss’ time. (or the other way around).
For “portability” you can simply make an agreement to use a recent version of some lib. If a library symbol changes, the effects are often minor, because you have most of the project in your head anyway.
For “archivability” you have to make sure the needed libraries, in the correct form, are available when needed. If any problem arises, there might be nothing to fall back on. The original designer might be enyoying his pension or working for a competitor.
The main difference between “portability” and “archivability” is the time factor.
If you e-mail a “portable” project to a friend and it is not complete, he mails back and you send him a better version. If an “archived” project gets revived you may have to start with finding a KiCad version that can still read it’s ( maybe many years old) file structure. If such an old project depends on external libraries at all you are very likely out of luch and almost have to start from scratch to re-create the project.
A brother of mine works in the aircraft industry. If I remember well they do not only archive the projects (strength calculations) and the software, but also the hardware. They have a warehouse somewhere with up to 40 year old computers just to be able to guarantee that if some important unknown problem arises, they have the opportunity to examine it. It is a part of the reasons aircrafts are expensive.