The EDeA project is happy to release version 0.6.0. This release includes a command line tool to add one KiCad project as a sub-circuit to another project, inserting both schematic and layout.
If you are familiar with Python tooling you should be able to do:
pip install edea
And in any KiCad project:
edea add ../another-kicad-project/
Then re-open KiCad and run “update PCB from schematic” and “assign reference designators”.
I’m not sure what to think of this. Sub circuits is already on the horizon for KiCad for quite a while
This generic search:
Puts this issue, (created in 2015) on top:
Having the ability to work with subcircuits would be really nice, but I view it as a temporary stop gap method to put this functionality in some external plugin. My eyebrows also frown a bit at the 6 seconds runtime of this cli program. It is a very small schematic / pcb fraction to merge, and all it has to do is copy some text from one KiCad project to another, and fiddle a bit with References (RefDes) to keep schematic and PCB synchronized.
Overall, I would much rather see this natively implemented in the KiCad GUI itself. I assume that the merging itself would be quite trivial, but handling the GUI would take the most programming effort. Some database like structure which contains the sub circuits, maybe a way to select such from a bigger database or pull them from external git repositories (Git integration is not a goal of the KiCad team as far as I know). I have not put much brainpower into working out details.
Well, this is here now and we worked hard on it. Feel free to use it or not. Maybe we could discuss this tool here and make new threads or go to KiCad Gitlab issues for alternative solutions?
It is a stop gap for sure but it was easier to implement than adding it to KiCad. It’s also implemented in Python for that reason, has not been optimized and needs 6 seconds to process the files.
Yes, that is a common excuse. You’re also getting plenty of “likes” in this thread, so apparently there are lots of people agreeing with you.
Maybe I’m a minority here, but my view is that when you had put the same effort into KiCad itself, it would live along for many years, while this stop-gap method is likely to be deprecated within one to tree years.
I have (very unfortunately) seen far to many well intended open source projects whither and die after some time because of lack of support from a wider community. After some time (which can be 10 years or more) the original creator looses interest, or lacks time (maybe stared a family or a new job, emigrated, whatever) and if it has not picked up enough interest form other programmers by that time, then bit rot starts accumulating, and a bit later it becomes unusable for people without skills to modify the software themselves.
Edit: I agree with Eelik’s post below
Sometimes I get carried away to far by my idealism, even though I (should) know it is not always realistic.
I totally agree with you both. The preferred solution is to implement it in the main app. But sometimes there are good reasons for a quicker and possibly not that dirty implementation via API, add-on or somehow hacking with the raw document files.
There are plenty of good examples in my own household where some ugly lifehack-like things were installed to avoid some award-winning full solution - just due to time and my personal skill set .
Perhaps we can agree on the common “there’s more than one solution”?
We have waited for native multichannel support for how many years. Great if it will come with v9. Meanwhile the corresponding functionality has been available as a plugin, and I think it has been one of the most popular plugins for KiCad.
Now we are waiting for reusable design blocks, too, but it has not been assigned and is “waiting for spec doc” which means it’s not simple to implement natively. It’s possible that a plugin programmer can cut the corners but couldn’t implement the functionality according to requirements given by other developers. It may be unfair to criticize someone for not implementing something directly to KiCad.
There is also a plugin to cover this functionality. And it shares a lot of the codebase with the multichannel support, as copy pasting a channel within one PCB is quite similar as copy pasting a channel between different PCB’s
I’ve hacked a few projects together to suit my needs and others have contributed to them as they are simple, stand alone hunks of code with a few, easily managed dependencies. The bar to contribution is low.
Setting up a development environment and familiarisation with the KiCad code base is a significant hurdle to native development. You also need familiarity with the coding conventions. Your developments are probably going to be a solo effort until the feature is broadly functional. Your pace of development may not match other developments in the code. It might then never get merged.
I think many authors of side projects develop ideas for their own use and hope they may have greater applicability, gauge the level of interest and possibly interest more experienced developers to take them further or roll them up into KiCad. Plug-ins are a good half way house as they have greater prominence in the KiCad ecosystem but can be written with relatively little knowledge of KiCad internals.
I agree that permanency is likely better served by hacking the codebase but the bar is a lot higher than for a stand alone project.
The number of plugins are indeed growing. A scan though the Plugin & Content Manager brings ups some related plugins:
Save / Restore Layout
This plugin implements footprint modules or snippets feature. The plugin saves partial layout corresponding to footprints from one hirearchical sheet so that it can be restored in other projects. All projects have to use the same hierarchical sheet schematics. If the schematics has been edited, the plugin will refuse to restore the layout. So in projects where you need to change the schematics slightly, first restore the layout and then change the schematics.
Schematic Blocks Plug-In
A plug-in can be used to save circuits as blocks. Then these circuit blocks can be reused in different projects. This plug-in aims to reduce schematic drawing time significantly.
To create a schematic block, first, select the circuit and copy it to the clipboard (Ctrl+C). Then open up the plug-in and give it a name by writing it in the text field at the top. Click the “Save Block” Button to save it in the working directory. If you want to change the working directory, you can click the “Change Working Directory” button. All the blocks are saved in the working directory. Also, all the blocks in that directory will be listed in the List box.
HierarchicalPCB
Define a sub-PCB next to your sub-schematic file, and HierarchicalPCB will propagate that layout to the final PCB. Organize your PCB layouts for maximum reusability!
I guess that starting with a plugin is not such a bad Idea. Partially it is also an experimentation area to try out new Ideas, and to see how useful such Idea’s are. When applicable, parts of a plugin (or the Idea of the plugin) could be (re-) implemented as a native KiCad part in a later stage.
I have moved the bulk of the discussion about the response to this announcement to a new thread, since it is not on-topic for this thread. Please be civil and respectful to everyone when posting on this forum. The remaining discussion on this thread should be about EDeA.
.