Have we got a way to cut/paste between schematics?

I was not successful upon trying to cut/paste some group of components between two instances of eeschema.
Is there a way to do that?

2 Likes

In KiCad V5.1.x schematic contents can be copied / pasted only in the same instance of Eeschema.

There is an: Eeschema / File / Append Schematic Sheet Content, but this has the *&^%$#@! that it places the content of that other sheet directly over the current sheet.

For a full workaround it becomes a bit more complicated, but here is a method that works:

  1. Open a project in KiCad and start Eeschema.
  2. **Eeschema / Place / Hierarchical sheet. [Shift + S].
  3. Draw a box. This is the representation of the hierarchical sheet.
  4. Ignore the generated file name & Sheet name. Just accept the defaults and pres [ OK ].
  5. Press [ Esc ] to stop the “Place Hierarchical sheet” function, then double click in the rectangle of the created sheet.
  6. You have now an empty drawing sheet.
  7. Eeschema / File / Append Schematic Sheet Content and browse to the file you want to cop stuff from.
  8. Drag a block around the stuff you want to copy, then press the Right Mouse Button and select: Copy Block from the popup menu. (Or just press: [ Ctrl + C ]
  9. Eeschema / View / Leave Sheet to go back to the main sheet.
  10. Now you can paste the block in the original sheet.
  11. Delete the Hierarchical sheet when you’re done.

And unfortunately it is even worse. When you Append Schematic Sheet Content in step 7). you break library links for any custom library symbols, and you have to fix those in a separate step.

It’s a long explanation, and a complex workaround, but once you’ve done it a few times it’s mostly a handful of mouse clicks and does not need much time.


The good news though is that it has all been fixed in KiCad-nightly V5.99. In that KiCad version copy & paste works as expected between different instances of Eeschema. There is also no library issue anymore because schematic symbols are cached in the schematic file itself.

3 Likes

Unless you want a sane workflow going forward? “Caching” symbols was such a boneheaded design choice.

Can you elaborate on that?
The way schematic symbols are handled in KiCad-nightly V5.99 is a huge improvement over KiCad V5.1.x.

Maybe “cached” was the wrong term to use for KiCd-nightly V5.99. I just did an experiment with a schematic in V5.99. I have two identical connectors in a schematic, hovered over one of them and press [Ctrl + e] to edit it in the schematic symbol editor, then changed some trivial thing and put it back in the schematic. The two connectors are now different. This works very similar to footprints in Pcbnew V5.1.x. It’s also easy to revert back to the library defaults by re-loading it from an external library if needed.

“Embedded”. -----------

1 Like

Hi, you should use v5.99 nightly, it supports usual “CTRL+ C / X” -> “CTRL + V” as other applications do. I use nightly on daily basis, it is far more efficient than v5.1 branch. Make backups of your projects together with the installer.exe to be safe (you cannot usually cannot re-open design files, saved with newer builds of kicad).

1 Like

I wouldn’t say “should”. It’s still an unstable development version, in the middle of testing and bugfixing, although it’s in a pretty good shape nowadays.

2 Likes

This sounds like a nightmare to me. I want my symbols/footprints to ALWAYS reflect what’s in the library file. Anything else is a recipe for disaster unless you remember NEVER to use the update function…

3 Likes

I already mentioned:

Bugs still pop up quite often in KiCad-nightly V5.99. I do not know how often, as I only use it for small tests.
If you want to try V5.99, you have to be aware that once you save a project in V5.99, it can not be opened with KiCad V5.1.x anymore.

2 Likes

The answers you got seem too complicated to me. I didn’t tried to follow them. May be I didn’t understood the key in the subject but according to my understanding the answer to your question is as follows.
With KiCad 5.1.10 (Windows 7) to copy some part of one schematic to another I:

  • run the eeschema not from KiCad, but directly - double click at eeschema.exe in KiCad\bin directory,
  • File-Open the source schematic,
  • rectangle select the interested part of schematic (it starts to move, but I press right-click to get context menu) and select ‘Copy Block’ from context menu,
  • File-Open the destination schematic,
  • Ctrl+V allows me to place copied schematic part whenever I need.
3 Likes

I don’t understand your reasoning. What happens if the library items are always automatically updated to all opened projects? For example, you change half of the symbols, change pin locations etc. and half of the footprints. When you open a project, say after one year, to make some small changes, you suddenly get automatically different schematic and layout and need to redo them. For layout redoing may even be impossible if it’s tight and depends on certain pad size, location etc.

The only professional option is to control what you want and get.

There’s no logic in this. On the contrary, automatic update is a disaster. How do you get a disaster if you can control when you update? Why do you suppose you should NEVER update to not get a disaster? I have used manual updating for boards many times. No disasters.

3 Likes

I can understand his concerns completely. (background on my case: ~25years working with eagle. There is this flexible library-indepent-editing approach not possible. And I know in the meantime: kicad!=eagle).
the disaster-scenario is the following:
-build a schematic/board with standard-symbols/footprints

  • edit some of them inplace with edit symbol/edit footprint without saving into librarie ( for instance make some pads bigger for better soldering)
  • build the board, project runs, forget the project
  • one year later: next board revision:
  • make all necessary changes to schematic/layout
  • normally I update all footprints to get the advantage from the development / bugfixes from the last year work and development (corrected/adapted silkscreen, solder mask, whatever) in the libraries (sometimes only the self-used-libraries)
  • the normal tool for this would be the “update all from library”-command
  • and at this pont the “disaster” happens: if I don’t remember that I have made some special tweaks to 1…2…3 footprints/symbols (it’s one year ago - who knows all little tricks he made?) then these modifications will be lost with the “update all from library”-command

So for now I try to avoid the kicad-flexibility.

But to reassure halachal: nobody is forced to modify symbols/footprints directly in the schematic. And there are some protection measures so that unintentially modifications don’t happen.

2 Likes

Nice find Piotr:

I tried this and it also works for me.
@rin67630 The “standalone” mode of the KiCad programs (Eeschema, Pcbnew) means that the program is opened directly from your OS, and not from the KiCad project manager. This has a few extra options such as opening schematics directly. For Pcbnew it a way to put multiple PCB’s on the drawing area, for example for making a panel (although functionality is limited in this regard).

For halachal & mf_ibfeew about the “disaster” scenario’s.
In the older KiCad version (V4.x) schematic symbols were not cached, and only in the libraries. The schematic only had a link to the library symbols. This was a real disaster scenario, unless you added a lot of overhead. In those days I copied any used symbol from external libraries to a project specific library, just to ensure they do not change. Without those measures, any change to the KiCad libraries could wreck your project.

In KiCad V5.1.x it’s pretty much similar, with the addition of the [project]-cache.lib file.

With KiCad V5.99 the situation is much better. You take parts from a library and put them in your schematic, and they are automatically embedded in the schematic. And they stay there, unless you deliberately change them.

Why do this:

If you have a working, and checked / verified schematic or project, and want do do some revision, then don’t go changing random things. Any change you make has to be verified separately.

Resetting everything to the default library parts can be a step in some situations. For example you find an open source project, and you want to make something similar, but the project is a bit of a mess. Then in an early stage of starting to work on that project, you can choose to reset to the library defaults. But even then, doing so breaks compatibility with that project, and makes it more difficult to give back.

2 Likes

I know both approaches:

  1. never touch anything that works
  2. 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.

1 Like

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.

2 Likes

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.

Did not work for me…

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

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:

image

While the project mode only works with the (Hierarchical) sheets in the same project:

image

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

2 Likes

The user experience of KiCad 5.x today:

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

4 Likes

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.