I went to update a design done with a V4 nightly. After doing a modification in Eeschema to the design, then updating the Pcb, with the “Update PCB from Schematic…” tool my design ended up with all sorts of items out of place and most of the 3D models went AWOL.
First, some (maybe most) of the issues are entirely due to my learning curve with KiCad. However, I think that part of the problem is the fact that KiCad does change quite rapidly over a fairly short period of time; when compared to other software.
However, I am finding that “fixing” even simple issues are taking quite a bit of time. The point of this thread is an attempt to reduce this duplicated people-hours in the future.
My computer has two library folders, one for Symbols and a seperate folder for Footprints. At the moment I am considering adding a third folder just for 3D Models. As I do not yet make my own 3D Models I would have to move/copy a KiCad named 3D Model from the existing KiCad folder any time I made a Footprint to Model link.
But, I also notice that KiCad development chose to put the 3D Models inside the Footprint library. At the moment I do not understand the reasoning behind this decision as it did not avert the problems that I have recently experienced in the above mentioned design.
On a side thought, “Would it be possible for the Footprint to “absorb” the 3D model associated with it?” Or, at least make this a possible option?
To extend that further, how about having the Symbol being able to “absorb” a Footprint and the 3D model that the Footprint has “absorbed”?
One Atomic file for a 555 that is 100% complete containing Symbol, Footprint, and 3D Model for one part number; not just links to other file paths that may change in the future.
Your fully atomic file format is a bit against the current design philosophy of kicad. Wayne just recently made that clear for a similar question on the mailing list. (The question there was about including the spice model into the symbol. )
Eagle uses such a highly integrated file format. It comes with its own destinctive downsides. One can by definition not easily share the same footprint for multiple parts library files. (Eagle has multiple parts per file so there you can share footprints at least within the same library. If you have one part per file than you can not share footprimts at all)
If I have the same qfp package for multiple parts then I either need to put them into the same library (no matter if their function is at all similar or not.) Or I nerd to. Accept the duplication of the same footprint increasing the chance of an error. (Later changes to footprints are a lot of work or I need to accept that the same physical package uses different footprints in my libraries.)
I would refrain from introducing a separate file format for atomic parts. That will only increase kicads complexity. ( Both for the users and the defs)
Maybe a better solution would be to have a proper export archive option that generates a fully stand alone project.
One thing still missing to do this easily would be to introduce a 3d model library table and use lib names plus file names instead of a system file path within the footprint definition. ( Would allow the exporter to easily copy the needed models into the archive and add an entry to the local lib table.)
V6 will solve part of this problem by including symbol definitions inside the schematic file.
Your response is nearly unreadable in its current state. Could you at least format it such that we can differentiate between your responses and the parts you quote? (You seem to have put my text into some translation service and then translated it back. I would guess that you added some remarks of your own but i can not really find them in the current state of your text. )
This impresses me as the preferred solution, since most users create and maintain their own libraries and I suspect that no two sets of user libraries have the same structure.
This solution does, however, concede that an exported project (whether exported for purposes of sharing, archiving, or some other purpose) will not map directly into the library structure of the KiCAD installation that opens the project in the future. If the exported project is opened for a “read only” purpose - such as creating plots or prints for reference or comparisons - this shouldn’t be a problem. If it’s desirable to integrate the exported project into the KiCAD installation that opens it - perhaps to serve as the basis for the product’s next design revision - then some tedious manual intervention may be required, though software tools to minimize the tedium would probably appear over time. (Similar to the way BOM-formating tools and footprint-generating scripts have appeared.)
That great. What the though about the use case like me as descried following:
A repository A (SVN/GIT…) of customize library for company
A repository B of another customize library for not yet validated
A repository C for project C use A as external/submodule
A repository D for project D use B and A as external/submodule
…
What would be easy way to allow open any C, D project without configuration for environment paths or project lib tables? I think “relative path” with the project, and “relative path” using within library to reference files would be it one of solution I would think of.
I would not setup exported projects to easily integrate into the openers global setup. The whole reason for exporting is to have it standalone. If you want to integrate it then you need to share all the design files.
If you use custom libraries then all your libs need to be shared to effectively share a project in this manner. (You do not need to share official libraries in that case. But you will need to state at least the major the version of it.)
The user would then need to install the libs you shipped with your project in the normal manner. For this to be effective one would need to think about this usecase when setting up ones library system. Unique library names are a must for this to work easily. (Prefix it with some unique name. Example the name of your company, team, …)
I believe we are in agreement. “Integrate” was probably a poor word choice - perhaps I should have said “map”?
My idea is that the exported project would arrive at the new KiCAD installation with no information about the libraries from which the symbols and footprints were taken, except possibly the file name of the symbol or footprint (in its original library structure). No information about paths, directory structures, who drafted the original symbol, whether the footprint is for manual soldering or autoinsertion, etc.
At the destination, the user could look at the symbols/footprints individually and (for example) notice, “This looks like the symbol we call ‘BJT_NPN_TypC’ in our local libraries. I want KiCAD to use our local symbol instead of this one from the exported project.”. Then, with one easy clickey-click, Kicad would make the substitution in both EESchema and PCBNew. Same concept with footprints - the independent, stand-alone, footprints could be replaced by footprints from the local library structure. The items from the local libraries may, or may not, exactly match the items arriving in the exported project. That’s where the user must exercise his judgement as he tediously compares exported footprints to the contents of his libraries. And if the user doesn’t have a corresponding local item? Then the symbol or footprint arriving in the exported project could be extracted, named, and placed into the local libraries. In the extreme case, every symbol and footprint from the exported project could be extracted into separate library folders (named something like “ProjXXXNN_All_SymLib” or “ProjXXXNN_All_FPLib”) and placed within the local library structure.
That’s what I meant by “integrating” an incoming, exported, project with the local library structure. I admit, the 3-D models and SPICE files are still unsolved problems, but I hope my vision of “portability” is clear.
This is almost what my plugin does. It takes schematics -cache.lib and re-formats it saves it as a -archive.lib and ads it to project sym-lib-table via KIPRJMOD variable. It also modifies the schematics symbols to point to symbols in -archive.lib. With footprints, there is nothing needed to do, as they are already stored in .kicad_pcb. As for the 3D models, the plugin looks for them, copies them under shapes3D subfolder within the project folder, and changes the modifies the .kicad_pcb so that the models are referenced to the copied models via KIPRJMOD variable.
