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.
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.