if you have newer parts -> definitely update everything, theres must be a reason for the new parts
In reality it’s a compromise between these two extremes. (it may sound arrogant, but after so many years experience I think I have a reasonable working model to deal with difficulties and decisions)
The reason I update footprints from my libraries on board-revisions:
my libraries evolve over time and (hopefully) get better. My self-made footprints mostly work already with the first version. But normally this version has some drawbacks, for instance:
THT-Pad-holes to small for good desoldering (hinders reparing)
THT-Pad-holes to big - parts falling out from board on soldering
SMD-Pads for power-mosfet: increase-pad-size outside from mosfet to better hand-solder on big copper-zones
generally improve silkscreen
Although the first version already works I need sometimes 3…4 revisions until I’m satisfied.
So if I do a board-revision for a project there can be a long time since I last worked on that board. In the meantime I made corrections on some parts/footprints, and all corrections where meaningful (for me, otherwise I had not done them).
So yes, like you said, the working board doesn’t need the footprint updates (it had worked before), but on the other hand it could benefit from the evolving libraries. For me I have decided to mostly update the self-made footprints/libraries and leave the parts from the original CAD-parts unchanged. But it also depends on the project itself: if the board already has seen some revisions and production-runs and there are no known problems, I tend more in the direction “don’t touch”.
Nonetheless you are right, a good and thorough overview and checking about all changes from “library update” remains essential.
remark: don’t get me wrong, I appreciate the embedding of symbols+footprints into the kicad-files. Together with many user-interface-changes it made the v5.99 the first kicad-version which convinced me to work with (I have tried v4 and v5 and got both times frustrated). The developers and supporters deliver superb work.
Did I understand well?
If any change in library is automatically updated in your project files - it is OK.
If you can do it only manually, when needed, then you have to remember to never do it.
It is inconsistent with each other.
This is why I never use KiCad global libraries. Every kicad_mod and schlib used is copied to the project folder and archived alongside it. Sounds similar to how you envision these “embedded” symbols/footprints are used, except without hiding their existence inside the board files.
The most likely cause for this “not working” (Do you have a better description?) is that you did not open Eeschema in “Standalone Mode”.
The difference is quite subtle, but important, and there hardly is any visual indication that it is in “Standalone Mode”.
Compare the icons in this screenshot. The top window is from a project, the bottom window is in “standalone mode”.
Icons in normal (project) mode:
Save, Edit Page Settings, Print, Plot.
Icons in “standalone mode”:
New Schematic, Open Schematic, Save (all sheets), Edit Page Settings, Print, Plot.
Similar for the Eeschema / File menu. The Standalone mode has options to create a new file and to open and save a file:
While the project mode only works with the (Hierarchical) sheets in the same project:
And the only way I know of to trigger this change is in the way Eeschema is started. If it’s started from a project, then it is in project mode. If it it started from your operating system, then it starts in “standalone mode”.
A user downloads a project from somewhere and the libraries aren’t there.
A user’s libraries get shuffled and now their entire project is broken.
A user opens up a schematic and it’s in a “crashed” state where KiCad has no idea what to do and prompts the user with a frustrating procedure to reconstruct/reload their missing symbols.
KiCad 5.99 fixes all this.
Your use case seems like a rare need? Once a symbol is accurately created from a datasheet, it should go in a global library on your PC which all projects can pull from. Why would it change later unless there was a mistake? And if symbols have frequent mistakes, I refer back to the suggestion that it is recommended to verify all symbols against datasheets on first use.
I’ve been using v5.99 for some time now with no symbol/footprint issues. I regularly use the update function. My good luck may be due to the face that I use all my own symbols so I have control over the libraries and know when they change.
However if you aren’t comfortable with it you can update from library every time you change a device detail.
I do similar…but that does not mean that I might not forget something…
Back to the original question. I had recently discovered “groups” in 5.99 and was thinking a group could be saved outside a project (can it?) but then I saw that groups are in pcbnew only and not in eeschema. Is there any way that groups as a feature added to eeschema could be a way out of this problem? Saving portions of a design for a different design would be really useful.
I think you do something not exactly as I.
It is not my idea working only at my PC and with my KiCad version. I was told here to do it that way about year ago and it worked in those time version and now it also works.
A user downloads a project from somewhere and the libraries aren’t there.
Because they’re downloading a crap project where the designer didn’t include the libraries
A user’s libraries get shuffled and now their entire project is broken.
Dunno, never experienced this
A user opens up a schematic and it’s in a “crashed” state where KiCad has no idea what to do and prompts the user with a frustrating procedure to reconstruct/reload their missing symbols.
This would be a whole lot simpler if KiCad didn’t try to “rescue” shit and just gave you a list of missing files to track down.
Once a symbol is accurately created from a datasheet, it should go in a global library on your PC which all projects can pull from. Why would it change later unless there was a mistake
NO. Maybe there’s a mistake, maybe I want to rearrange pins to make my schematic flow easier, maybe I want to group/disperse GND pins. What I absolutely DO NOT WANT is for a change in one project to propagate GLOBALLY so I need to update a hundred other projects, maybe some of which haven’t been touched in years. THAT is how you end up with broken projects.
@moderators OP had a question about cut & paste, and this thread has been hijacked by a library management discussion. Can this be split off in a separate thread?
Yes, I actually use my (local) libraries in what seems very similar to the new nightly flow. Except I keep them “cached” inside my project directory structures instead of within the schematic/pcb files themselves.
It still seems like a recipe for confusion to me to have these multiple levels of storage/association.
This is a very valid concern, not only for eeschema but pcbnew.
If you use an incorrect symbol/footprint and you RTM then however wrong it is, it reflects the design at that moment in time and and such “correction” should not be applied to the design.
PCBnew embedded the footprint into the design and you have to explicitly request an update from the library. I hope eeschema has this as well as the symbols are now embedded.
This way a revision can utilise the updated symbol. IDEALLY some revision number is included (by default not an added field by the user) to provide an indication of what “version” of a symbol is in-use. Again ideally this number is auto-incremented by the symbol and footprint editor
The way KiCad V4 worked, with only references to some external libraries for all schematic symbols was very much *&^%$#@! Back then the only decent workaround was to make a project specific library for schematic symbols, and force all schematic symbols to point to that library.
Later the -cache.lib and the “rescue” systems were added as a (I assume) temporary and partial fix.
With KiCad-nightly V5.99 there is no need anymore for any of that. Schematic symbols become part of the schematic, and they stay there, unless the user does some specific action (such as update from library).
I understand this can be confusing, especially when you work with different versions of KiCad (I’ve been doing some small tests with KiCad-nightly V5.99, but no serious work).
In KiCad-nightly V5.99 there is no need anymore to do library management. With the embedded symbols the schematic has finally become robust and you will (should?) never see the [??] schematic symbols anymore.
If you wish so, you can add project specific libraries with parts, but it does not add much usefulness to a KiCad-nightly V5.99 project. I’d say that having the symbols both in a project specific library and in the schematic would even be counterproductive as it just adds more room for errors and outdated schematic symbol variants and thus leads to more confusion.
Indeed. In KiCad-nightly V5.99 Eeschema handles schematic symbols very similar to the way Pcbnew V5.1.x handles Footprints.
But also with the added function of viewing and changing library links with Eeschema / Tools / Edit Schematic Library Links (This is already present in KiCad V5.1.x)
Below a screenshot from this window in KiCad-nightly V5.99. The project is an old one which I started in a KiCad-nightly years ago (2015?), then got stuck because of bugs, later finished in KiCad V5, and now use in KiCad-nightly V5.99 for testing. Because of this history, all schematic symbols point to the project specific library “mumar_base_stm32”. For new projects I do not have to perform these library management steps anymore.
I just noticed the [ Map Orphans ] button in the Eeschema / Tools / Edit Schematic Library Links window. This may very well be that functionality, but I have not used it myself. At the very least that window has an overview of the libraries for the schematic symbols that are used (and has the functions to change them).
Also, just for completeness, a link to a description of how the -cache and -rescue files actually work:
In addition to deleting the Hierarchical sheet you must also delete the file i(with the same same as the Hierarchical sheet ) n the project’s folder because it is NOT deleted. Only the project’s reference to the Hierarchical sheet is deleted.
