Perhaps this can be more easily accomplished when the archives grow up?
I would like to be able to press a button and have the various foot prints and libraries, made available in such a way that I can copy the folder to share with another user. On their side they can either leave the files as they are or press a button and import the foot prints and libraries to their own global files.
Currently while KiCad allows for this function, it requires a user to do this per file. That is, to share files, the simplest way is to include a complete copy of all custom foot prints and libraries in every instance folder. Then if not at import, then after the fact, manually define a full list of the custom footprints and libraries as local non global files. This way all files needed always archive in the master folder for the project. Which right now, by default they do not.
The rescue feature can be helpful. But also a nuisance, as it reassigns foot prints and if files are passed back and fourth, and edited in between now those changes must be manually re imported, and associations manually repaired.
A savy user may create a folder as template with all files added, then copy this as needed, updating the master any time new files are added. Still this requires layers of extra work.
KiCAD at this time is truly most optimal for NEVER SHARE, NEVER COLLABORATE. As the rescue function is most opportune for a one time share, one direction share. Not bidirectional.
++++++
Perhaps the correct choice is to make all imports saved globally, but always archived locally.
That is, on import, the file is copied to a global archive. But also copied to the local archive. If the folder is copied. No rescue is required, the default should be to search the local archive first then the global archive. If the local file is not found in the global archive or their time stamps do not match, user can be prompted to SYNC the entries.
++++++
Well, we use git with libraries as submodules.
To clone a project, git clone --recursive
And yes, the same submodule is copied to all projects. Every time we push a change to the library we must update (pull) that libray into the other local projects. But at github there is only one copy of the libraries.
The paths of our libraries are always related to $KIPRJMOD. They are also poject libraries not global.
For the default libraries, it’s quite easy to collaborate as long as everybody uses the same library setup, and this is quite easy, as KiCad V4 is pretty much obsolete, and the KiCad V5 libraries are pretty much frozen.
A long time ago KiCad grew into a system where schematic symbols have references to external libraries, and depend on them for the graphics of the schematic symbols. (And this is probably the main reason of the static nature of the KiCad V5 libraries). This lead to a lot of problems (Especially when archiving, and restoring old projects, which likely depend on (now nonexistent libraries) As stopgap methods the [projet]-cache.lib and [project]-rescue.lib files were created. But it was quite a mess, and unfortunately still is.
In KiCad-nightly V5.99 this has finally changed. Schematic symbols are cached in the schematic file itself, in much the same way as footprints are cached in the PCB file.
Some time ago it was expected that KiCad V6 (or at least a Release Candidate) would have been released by now, and almost all effort of the developers is going into getting KiCad-nightly V5.99 ready for this. It is very unlikely that anything except direct bug fixes will be changed in KiCad V5.1.x.
The most current stable version of KiCad is V5.1.10, and V5.1.11 is being worked on. For an overview of the changes for V5.1.11 you can have a look at:
It sounds like the plan under 5.99 forward will include the features I am asking for and ease the transfer of files between cooperative editing or review. So I look forward to a Release that includes these functions officially.
Updated from 5.1.8 to 5.1.10 and that was a mistake. Traces in the PCB were locked and I could not diagonal drag many of them even after toggling lock. All connected segments just turned a shade darker and nothing happened. So have had to wipe out most of the work and start over. To say nothing of the Archives. Also fighting with the Netlist import to PCB arguing that the pins are missing when after triple checking, editing, removing and reattaching I can be 100% certain everything I accounted for… Still fighting it.
A big frustration of the archives is and still remains that Footprints and Libraries use two separate applications. They look similar but things are misplaced between the two.
Also when setting up a footprint or library, user cannot initiate an edit from selection, and a user cannot search for a footprint from selection. To find a footprint a user must drop out of choose footprint, drop out of properties, launch foot print editor, find the part, make a hand written note of how to find it, then close editor, go back into properties…
I hope that 3D data base has also been fixed. That is maybe access to it.
So far other than automatic rendered foot prints in 3D, and some predefined foot prints I see no default built in way to attach a 3D to a Footprint or a Library. However I can place one from within the PCB editor… So there is that.
I am always a bit confused why people assume that libraries need to be included inside a project for it to be suitable for collaboration. I personally prefer the centralized library approach (with a clear and strict process for adding assets – example via pull request into a git repo that allows a second engineer to review every added asset). With that approach, of course every new contributor needs to set up the shared libs at the start of their work with the organization at hand (for me an acceptable up front investment that pays of long term).
And for simple read only shares (where this effort might be a bit much) one does not even need libraries as footprints are included in the pcb anyway and symbols come in the cache library (will be even easier once v6 comes out as symbols are then also included in the libs). And a read only 3d share is best done by exporting the board as step as the receiver is then not even required to have kicad installed (any step viewer or 3D MCAD program would do)
And of course there is always the option to use the archive project plugin or setup a project with only local libs from the get go.
The reason is pretty simple and laid out above. We don’t all use the VERY LIMITED default files. Those files also cannot be edited without a deliberate copy out and replication of the archive.
So, inevitably we will also make and generate new libraries and footprints for parts. But since the options are local and global. Global are great for me and all of my projects. Local is great to share. But every time I generate a project I have to re import the files. If my files are global for ease of use I have to manually copy over and add those records before sharing so that they work properly. If I don’t, the shadow copy is used and it generates a RESCUE file which is good for a one way copy but makes a mess if they make edits and send it back and now I have to fix the BROKEN links that do not fix themselves. If any of the RESCUE libraries and footprints are updated they are not reflected in the global records unless manually fixed. Point is RESCUE is like UNEMPLOYMENT. Its a great safety net but no one should be depending on it for any reason, it makes more trouble than it fixes.
Lastly, we all cannot demand or expect that every one else be importing and exporting every file we use, its a pain and and many just wont. I have worked with programmers who own companies. On my side I have all the files. Send over the code with notes that they need to install various libraries. They go silent. After some time they complain it doesn’t work or they cannot find the libraries. Often they just arent looking for the libraries, and never installed them.
So the fix is to NEVER EVER depend on the person on the other side doing their part to install anything. Because we just cannot reasonably expect it to happen no matter how logical it may seem to us in the driver seat. We can assume they will not do what we ask, even if they happen to be better at Engineering or Coding. Smart people can still lazy or minded. So accessory libraries must be included always in some form or another immediately accessible as dependencies to the core code. This also simplifies switching PCs for any reason at all.
I think we all have work arounds. But I dont think it’s hard to code a fix and from the sounds of it 5.99 will introduce one. I look forward to seeing if this headache is patched.
I am surprised and confused by the troubles you experience with your transition from V5.1.8 to V5.1.10.
I’m confused further by your use of “footprint” and “Libraries”.
Every time I create a new library (Either for schematic symbols or for Footprints) KiCad asks me if I want to use that library as a global library or a project specific library. If you want to share a schematic symbol or footprint between different projects, then “global library table” is the best option. If you share such projects with other people, you have to synchronize these libraries also with these people in a separate process.
If the “rescue” system is triggered because the libraries are not synchronized, then you break the project if you continue with the rescue process. The correct way would be to exit KiCad without saving, update your shared libraries, and then open KiCad again.
This is probably explained in the “library setup for sharing and collaboration” link that Rene Poschl posted earlier.
It depends on the companies I work for.
One of them makes open hardware. Every project has its own libraries with only the symbols and footprints used in that particular project.
In another company we use a common folder in a server with all the symbols, footprints and 3d models.
If you really insist on all the assets used on a particular board/project to be in the project folder, you may want to check out the Archive Project plugin by @MitjaN. It will collect any assets (symbols and 3D footprints) referenced outside the project folder and make the appropriate changes to the files to reference the asset copies in the project folder. If this plugin works for you, maybe make it part of your SOP workflow to run this plugin before disseminating project updates to the rest of the team.
AFAIK it is for V5.x, and hasn’t been updated for 5.99/6.0 yet. I also don’t know if it cleans up assets (specifically 3D models) that aren’t used anymore (I suspect not).