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.
In Eeschem from KiCad 4.0.7 it is easy: Just make sure you do not loose the project-cache.lib, and put that lib on top of your library list.
For KiCad 5 I do not know, never used it. The most logical way to me seems to keep the functionality to generate the project-cache.lib file, and make all the schematic symbols point to that file as their origin.
There could be an extra button in EEschem, maybe under EEschem -> Tools under EEschem -> Files
4.0.7 and before:
-Symbols: I duplicate the project-cache.lib and rename it project.lib
-Footprints: I just copy and paste the footprints to project.pretty as I need them.
It can also be done with File->Archive Footprints ->Create new library and archive footprints, but I prefer to add the footprints as I need them because the library name is part of the footprint name.
-3D models: same as footprints, copy and paste at a folder called Modules3D
Let’s say I have a myproject folder with some folders inside:
-Project (With schematic, netlist and layout files inside)
-Gerbers
-Libraries (with project.lib project.pretty Modules3D inside)
-Doc
…
Paths to the libraries: ${KIPRJMOD}/…/libraries/project.pretty for the footprints and so on.
V5.0.0-rc2
-Symbols: Same as footprints. I copy the symbols to project.lib as I add them in the schematic.
But instead of copy-paste with the file-explorer, I use the version 5 built-in libray manager since symbols are not independent files yet.
(Don’t take the following comments as a “correction”. It’s more my personal interpretation of the distinction between “archived” and “portable”.)
When I create an “archive” of a KiCAD project, I imagine it’s primarily for future reference. That is, at some future time (weeks, years or decades from now) it will probably be opened and viewed but probably not be modified or added to. The archive will probably be opened or viewed on a different computer than where it was created. For an archive I expect all of the footprints and symbols to be “frozen in time”, as they were at the time the archive was created. (Yes, even if there is an error in a symbol or footprint I want to preserve that error.)
The exception would be when the archive becomes the basis for a new project. In that case, I’d like the capability to clone the archived project into a completely new project. At that time I’d probably want to bring all the symbols and footprints up to their most recent revision, and work with the current libraries as I develop the new project. However, I’d like to have an option (on a case-by-case basis) to keep the footprints and symbols at the revision preserved in the archive.
“Portability”, on the other hand, implies that the project information will be transferred to another computer, and modified in the near future. I want the transferred project to open and display as it did on the original computer. Subsequent work should have the option of drawing on the same library files as the original project, if they are accessible; or drawing from the libraries accessible from the new computer. More importantly, the user should be alerted regarding which libraries are being used.
Dale
@dchisolm.
Yep mostly on the same level as what I think of archive versus portable.
Except maybe that archived projects could be more often revived for changes then you think.
A design that has been used for several years can easily go through several revisions with long times in between. Some rare hardware bugs get found and need to be fixed. Electronic components get obsolete, or replaced by cheaper versions. Processors get updates because more flash is needed for better algoritms. ADC’s swapped for better accuracy. Loads of reasons to make small changes to existing projects.
For archiving I also tend to include the gerber files and export the schematic to a pdf. These are a 2nd backup for if the software changes in the meantime, or a library got missed or lost.
When I was young I used to be less scrupulous about this. For some of my oldest project I have a nice .arj file of the project. Schematic and pcb, but no hope of finding software that can read those (text based) files. The software was DOS based and from a local dutch company (“ultiboard”) which was later taken over by … I forgot, to old.
For some other projects the only readable archive I have is because I made copies of the schematic in png format to share them on my website. For some other projects a piece of paper with spots, wrinkles and torn corners in a multomap is the only readable copy left.
I have also seen this happen in companies, where a piece of paper is the only remaining readable archive of an electronics project. And such a schematic might be good enough if you only need it for some fault finding in a unique piece of equipment.
Altogether: People are sloppy and forget things. Shit happens (earthquakes, tornado’s, etc) There are a lot of things that can go wrong over the course of 20 years. The best way to give an electronics (or any other) project a good chance to survive is to use standarized file formats. With an pdf svg or png of the schematic you can read it, and that is a big help if it has to be reacreated. If you save the gerbers you can order more pcb’s even after your (usually proprieaty) software stops working. Yet another good reason for using Open Source software, although that is no guarantee against obsolence.
The impact of “small changes” on a “project” depends on the configuration control system in effect. Personally, I create an archive for each Revision level of a KiCAD project. That generally means that an archive would get “revived” only once - when it is cloned, to become the starting point for the next revision level. Problems arise with situations such as you describe, where configuration control permits drawing changes that do not increment the Revision level. In the prehistoric days of hand-inked drawings, green eye-shades and sleeve garters, there was justification for this. In the current world of “drawings” as electronic files, and cheap mass storage, I advocate incrementing Rev levels (and creating a whole new archive) for even minor changes.
Even so, some of us can remember when *.ZIP and *.PDF file formats were viewed with suspicion, afraid that they would be a passing fad, and the only usable reference materials for a project would be the wrinkled, coffee-stained photocopies found in the bottom of a desk drawer formerly used by somebody who was fired 5 years ago.
Would your backup, human-readable, archives look something like the files attached to the post “SWOPA Thru-Hole Build Package Rev B” ?
Dale
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.