Hi Pedro,
I know about that feature, but this script solves the problem for anyone not using hierarchical sheets and it will also lay out anything that is not in a hierarchical sheet. This script basically solves a different “use case” than the one you would use for large projects.
Also: only experienced users know what a hierarchical sheet is. This makes it much easier for beginners to get going.
Hierarchical sheet is a basic feature for any largish design or repetitive design, even for beginners. It should be learned when need arises, and your design is probably exactly something which needs it.
@eelik I do not disagree with that, but to me it’s just as easy to do a cut/paste? Using hierarchy is just a preference.
Anyway - I just posted it here since I found it useful and I’m sure others will also. It’s obvious to me that you guys don’t see the purpose and I’m fine with that 
I didn’t mean it’s not useful. I like it. But it’s better to first know how to use KiCad’s capabilities and then decide.
Thanks for your script! I added it to the list of KiCad 3rd-party tools.
In the future, maybe you could partition some of your work into separate repositories. For example, this script is clumped together with some part libraries in the same repo. That makes it just a little bit harder for people to install the script or offer modifications.
This is a fantastic idea, thank you for sharing. It will be very useful to me.
I don’t really see what hierarchical sheets have to do with the usefulness of this script, which is useful whether you use hierarchical sheets or not - it auto-places components roughly in their schematic positions instead in a big blob that you then have to untangle. Yes, hierarchical sheets can make each blob smaller, but you still have to untangle them, and the script will reduce the time it takes to do that.
Assuming the script can fully deal with multi layered multi instantiated hierarchical designs. I still argue that the option build into KiCad is already more than just sufficient to deal with the layout process.
A well-made hierarchical design has very few components in each sheet as this is a core principle of hierarchical design similar to how limiting functional complexity per method is a core principle of object-oriented programming. And as components are grouped by sheet and can even be selected by sheet this will already take care of every usecase the presented script can help with.
This is the main reason why i think it will be very hard for the script to compete for this usecase. Worse, if it is not implemented very carefully its use could even be counterproductive for such a design.
However, it can easily be of use in a flat design. Simply because this design principle has much less focus on reducing per sheet complexity and might even go into the opposite direction to improve readability of printouts (which are useless in hierarchical design). This still applies if that flat design is spread over multiple sheets. Again assuming the script can deal with such a design.
And this is ok! Any given software does not need to fit every possible usecase. It is better to choose ones battles and make something that works well in a given environment than to try to force a solution to fit every usecase.
I’ll put it in a separate repository and message you
There’s someone better at Pyhon than me that said he’d extend it to multi-sheets this weekend.
Yep, agree. This is the beauty of an extensible system like the python scripting. It allows @jenschr to spin up a new tool and share it with others.
I find myself doing a lot of flat designs these days, so I’ll be giving it a shot!
Ha, I have apparently signed in using a social account instead of my normal one
Sure, Jens. I find it very useful for flat designs while for repetitive subcircuits pcbnew spreads the footprints one step further with hierarchical design.
As I told you in my first post, thanks again for sharing this script.
Not strictly with the usefulness of the script.
The repetitive subcircuit example shown by the O.P. is the paradigm of the hierarchical circuit design.
No. When hierarchical sheets are used, pcbnew spreads the footprints by hierarchical sheets by default. So they are directly “untagled”. That was the point of my post.
Furthermore, and I concede this comment has nothing to do with the script by Jens, the repetitive hierarchical design allows placing and routing one of the subcircuits and transfer the result to the other twin subcircits.
Hi all!
Ian over at the Contextual Electronics forum improved the script immensely over the weekend. It is now a fully working Kicad plugin and it can handle hierarchical sheets. Very smooth!
Download here: https://github.com/jenschr/KiCad-parts/tree/master/plugins
JuliaTruchsess
(https://forum.contextualelectronics.com/t/kicad-board-layout-question/3017/16)
I think it’s a fantastic idea, can’t believe the scornful response it got on the KiCad forum
I don’t see anything scornful here. People (including me) reminded that hierarchical sheets are important in KiCad. The plugin looks useful - I could use it myself. Sometimes I have expressed my opinion that there are good reasons to make the schematic reflect less or more the physical design, and this script is very handy for that.
EDIT:
ian: I don’t know why, but I went to have a look at the KiCad forum discussion about it. It made me sigh. Certainly doesn’t inspire me to join the forums there…
I don’t understand the whole discussion. Looks like people don’t want to understand other people. It doesn’t inspire me to join the forums there. But I can’t spread my free time all over the places, anyways, and I try to help people here using KiCad. That’s why I also commented on hierarchical sheets - it’s an important part of KiCad.
@eelik I (now) understand that you and @pedro meant this as advice regarding the specific project I used as an example for my plugin. I understand (and know) that using hierarchical sheets is “the right way” to do this kind of repetitive circuit, but I’m not a fan of this. I understand that this was posted as good advice.
If you read my post - I made the script to solve a very different problem, so when the first comment is “Kicad has a built-in feature to deal with this kind of circuit” and that “When pcbnew imports the schematic for first time, the footprints are placed grouped by their hierarchical sheet” it just seems like this is a critic of the plugin - not the circuit (since it points to the placement of footprints).
I understand that you guys only meant to tell that this was a board that could benefit from using hierarchical sheets, so no worries. I agree that it generally is good advice, but I really dislike jumping between sheets. I feel that I loose the overview
To make case for reflecting the physical design in the schematic, using both hierarchical sheets and this plugin, and Mitja’s Replicate Layout plugin… See this post.
I started with more “functional” schematic design. But trying to find routes (with board size restrictions) was a mess. I redraw the schematic with physical pin order of the ICs and with rough physical positions, of course using hierarchical sheets for the connector parts and the 3 ICs. Then I started redesigning the PCB.
Here this script would have been extremely useful. It could have saved much valuable time. Every “select all footprints from same hierarchical sheet, find the place for them, move them” step would have been unnecessary. And it was difficult manually because I had to find the correspondence between each group and its sheet instance in the schematic to find the place for it. KiCad doesn’t offer any powerful help.
Then, if Mitja’s plugin would have been in its current state I would have used it and saved several hours. Each small change in the layout meant going through all “channels” - with the replicate plugin it would have been a breeze.
This all shows the power of Open Source and collaboration.
You’re right. “Dismissive” would have been a better choice of word. Guy posts a cool and useful script and in return gets a condescending lecture as to why it’s useless because hierarchical schematics (not strictly true).
Exactly. All of my schematics are designed to convey function; I’m not a fan of “just draw a box for every IC and put net labels on all the pins”.
@jenschr Are you planning on maintaining this script/plugin? We maintain a simple index of sorts. You said it was someone else that did lots of work on it over the weekend. If it turns out to be stable and useful as is, then it doesn’t matter much. Just looking for input here. Yours or others.
