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.
jenschr, What a cool script you describe! It sounds as if it might save me work. I think this is the impetus I need to learn Python. Would you be so kind as to post a hypertext link from which to download your project files so I can run your script on it and see if I can duplicate your board file, just as a test case? I haven’t looked to see if you already saved them onto the github account you mentioned in your first post.
Jenschr
This is a terrific improvement. I’d like to see the feature implemented as part of KiCad and not be just a plugin. You deserve recognition for this.
I’ve taught classes and people ask how to start a pcb layout. I always say “make it look like the schematic”. Lots of folks have had that thought but you took the step of creating a script. I’m kicking myself for not taking the step.
We all each owe you a beer!
For this to be useful one would need to violate a few principles of abstraction. Mainly the one of separated knowledge domains. While i see this as useful advice for small projects, teaching it without a massive disclaimer might lead people to think they need to make the schematic such that it represent where the component is on the board (students often extend a tip for their current project into a general rule if no deliberate action is taken to counteract this).
A schematic should however only concern itself to convey the function of the system (Even better if the schematic itself has then multiple abstraction layers but well this way of thinking is not for everyone). Of course the importance of working this way scales with project complexity.
This depends on the workflow. I have insider knowledge that in one BIG well known company they tended to use physical positioning because it’s easier to debug and make the mental connection between the schematic and the layout. This works well with smallish designs if you have the same people working on the schematic and the layout. It’s of course different if you have a schematic guy who gives a large design to the second guy for inspection and then to the third guy for layout and they don’t interact later.
It’s part of the internet. Usually the ones who complain are the first ones to speak up. Those who find posted contributions useful usually remain silent. The whole debate reminds me of designing layout without schematics. While I can agree that it is not smart (from my perspective), I can and do appreciate third party solutions to this problem such as WireIt action plugin. The only problem I see with third party solutions (especially ones supporting different workflow) is that they are not really maintained. With KiCad python API always changing maintenance requires an effort.
And as other have already said, you’re contribution is great as it supports slightly different workflow. The only thing I would ask you is to put it in its own repo and maintain it. If possible make it work with V6 schematics file format.
@jenschr, re-reading my first post I also see (now) it could be taken as as negative critic of the plugin.
The “right way” is the way you feel at ease with. If my team and I understand the schematic and the layout, with our conventions, it is the right way no matter what others can think.
Kind of both, if mixed. It seemed to me you were reinventing the wheel “for this particular circuit” because with the hierarchical sheets the footprints are grouped by sheet. I didn’t explain myself too clearly.
I can’t understand people despising anybody’s script. They can always ignore the script without saying anything.
I can maintain it, but that would require a bit of learning for me? That’s why I suggested that Ian could take it over as he has basically written a new (and much better) script based on my idea 
We’ll see what he thinks?
Sure, I can maintain it. I’ve put my version of the plugin in a repo at https://github.com/ian-ross/kicad-plugins
@MitjaN As for supporting the V6 schematic file format, I’m happy to do that (not immediately, but definitely when it’s getting closer to release). Is there going to be a Python API available to handle the new schematic files in the same way as the pcbnew package does for layout files?
Hi Russ. Any Kicad project will work. Use whatever you have and start from a copy of you project? Pick up a copy here: https://github.com/ian-ross/kicad-plugins and install it as other Kicad plugins 
The best way to do this is to start a new thread. Give some details and a link. We will then turn the first post into WIKI format so it can be edited past the usual cutoff. Thank you.
Thank you Jens
This feature is something I once added as a “blueprint” / request.
It happens sometimes that the physical layout closely relates to the schematic. Also, sometimes I choose pins to faciliate easy physical inter-connection.
Great idea Jens and wonderfully polished off by Ian. Thank you. 
This will be a huge time saver on every design.
The plugin got a nice update from @ian-ross last weekend when I followed @pedro and @eelik’s advice for my next board. It had two major sections repeating on the board, so I designed it using hierarchical sheets. I found an edge-case bug, so I can verify that the plugin supports hierarchical sheets too
The plugin solves hierarchical sheets by laying these out underneath the main sheet.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.