Sometimes I find my self on the need of placing a bunch of components in parallel, like Diodes, Capacitors, MOSFETs, etc. This is sometimes hard to do while trying to make everything fit within the schematic’s limited space. Example:
Thinking about this problem, it could be possible to introduce a feature where users would specify the amount of instances of the component to be placed in parallel. This has the following advantages:
Schematic real-state is saved.
More efficient to render, since there is a single symbol.
Designator consistency: all components in parallel will always be annotated consecutively.
Improved maintainability: updating the design to include extra parallel units becomes effortless.
The designator should update to something like C1…10 to indicate, for example, ten capacitors in parallel. At the ends of the pins, the usual dot indicating multiple nets connecting at that point should be displayed. Maybe there is another way of highlithing such components so that other people reading the schematic is aware of the components in parallel.
My opinion is that, although it is always possible to do something similar manually, it is cumbersome and hard to maintain. This could be one of those features that gives the impression KiCad is a well rounded tool.
Any comments? If I see that other users will find and use for it, I will open a feature request in Gitlab, and post it here.
I have a related “want” for references for paralleled components.
There are circuits like RIAA preamplifiers, where you need two paralled capacitors to total some non standard value. Its nice then to have references like C123 and C123a
Just put the paralleled components into a hierarchical sheet and label as such. It would be nice to have a more explicit way of representing these components on a root sheet, though.
One of the feature requests around the design blocks is the ability to be able to attach a schematic file to a schematic symbol, instead of only to a hierarchical sheet placeholder.
Similar look and feel, but a different implementation would be to add custom graphics (I.e. graphics of a schematic sheet symbol) to the current schematic sheet placeholder. But I am not aware whether this is mentioned in the feature requests.
I would say the goal of Design Blocks is reusing functional blocks (circuits), like DCDC converters, gate drivers, etc. which have been already tested and are used in other designs. Repeat subcircuits is aimed at making copies of the same design block multiple times (why draw the same thing 20 times instead of one?), maybe even replicating the layout.
My proposal is to introduce a simple feature that allows one symbol on the schematic to represent multiple parallel instances of the same component. Instead copying/placing the same component N times, this feature would let users specify that the symbol corresponds to N identical components connected in parallel.
I think this could be implemented together with my proposal. There should be a checkbox or something where one can decide if a string is added pre or post to the desginator, or if the designator is just ordinarily incremented.
Exactly!
The problem I see with hierarchical sheet is scalability: say, there are 5 different places on a design where we would like to have X amounts parallel components. That would result in having 5 additional pages on the schematic just to show parallelized components. I’m glad you see it as a useful feature!
I will try to give it some extra thought at how this could be implemented, and how ir could be represented in the schematic to make it easy to understand.
No, that would be a single sheet for the capacitor bank, provided that each capacitor bank has the same “form”, but values of parts can be manipulated via local variables, and you can probably even add a few “not on the PCB” attributes this way.
Your idea of having multiple symbols in parallel is simple and probably effective in some situations, but it is a very small niche between just drawing some separate symbols, and going to a hierarchical sheet. Introducing “yet-another-way-of-doing-things” for such a niche is not very appealing to me.
Circuit doesn’t need to be that complex. It can be a small subcircuit that behaves like a single symbol but has internal connections and generates several entries in the bom.
Your application of parallel capacitors is narrow. Should one be created for series resistors also? Or even parallel-series combinations?
And what about parallel combinations of different sized capacitors? Maybe some electrolytics, and tantalums, or ceramic decoupling capacitors with different capacitance’s and sizes get a low impedance over a broad frequency range?
What about snubbers (usually RC combinations), or other protection devices? Add a TVS? Audio amplifiers (and linear power supplies) relatively often have transistors in parallel too, but each transistor usually also needs a balancing resistor in it’s emitter.
When you start thinking about details, then there are just too many situations where “put some devices in parallel” does not work well.
Yes, it is a narrow feature. I would say that is its beauty: it is simple. It is meant to solve a specific problem.
Implementation could be as easy as allowing to write designators like:
{C101,…,C110}
{C101, C102, C103}
{C100a, C100b, C100c}
C100 + {a,…,d} // Maybe a bit crazy
This could also be used to parallel resistors, MOSFETs and other components that would not require ballasts.
I feel like there are no better alternatives for this specific case, or they target different problems. Would something like I propose above “pollute” too much the interface? I believe it to be quite transparent.
The problem with the cases you mention is that they generate new nodes (nets) while simple parallelization does not.
I’m sure there could be several ways to preserve backannotation.
I want to thank everyone so far for your constructive feedback!
The problem with narrow features is that the RoC (return on coding )is low. And what seems to be a “simple” feature to you may turn out to touch a lot of code. Worse still it may impede future features because once something is implemented it’s hard to remove it because it’s in use. Better to thoughtfully design more general and powerful features.
Indeed.
There is a bit of a hidden problem that is uses the RefDes for things it should not. I once proposed to to make the RefDes thing for humans only, so that for example during Update PCB form Schematic [F8] it does not matter whether the Refdes is filled in. KiCad uses UUID’s to match schematic symbols with PCB footprints, and it should also use those during the update, ERC, DRC etc. But for now the idea was rejected because there are historical inconsistencies and it is likely to require a lot of development time to debug, while the gains are very moderate.
There are over 1000 feature requests on gitlab, and there is only a limited amount of development time available, and choices have to be made. Emphasis is on functions that extend KiCad’s capability, and that are useful for a broader amount of KiCad users. This is a very small thing with a narrow application, and it does not add anything new. It’s just a slightly different way of drawing the schematic.
In my opinion the best solution, as far as new features go, would be to allow using symbol-like graphics for a hierarchical sheet. That would be a general feature with more applications than just this one. The only problem after that would be how the reference designators are represented. And even this could be easy to solve using sheet property fields and text variables: for example, by introducing a new variable ${REFERENCE_LIST} which would have the list in some condenced form like C101…C110 or whatever.
For this feature is already a gitlab issue opened as feature/wishlist item. For all users who like the idea: upvote the gitlab issue (don’t answer in the issue, just click the thumbs-up button below the original opening post).
