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