Multi unit parts redundant power and ground pins in Eeschema


What’s the Kicad way to handle using multi unit parts (i.e. a quad op amp) power pins?. I have placed a few different quad op amp types they all show the power pins ( 4 and 11 ) on each unit. Do I need route power and ground to all 4 units? Should I just do one and *place not connected" on the other 3? It would be nice if it just showed up on one of them. Am I missing something basic about how multi unit parts work?

The project is just a 4 channel unity gain buffer for the ADC input’s on a Teensy that is breadboard friendly. SOIC-14 op amp, some caps, and a 10 pin header. Thanks for any help in advance.
Kicad 4.0.6/ Windows 10.


There is no standard way of doing this, and I suppose that whoever designs the library part gets to choose.

One way to do it is to put the power pins on one of the four units of your quad op-amp. If you do this, and you decide you want to swap gates, then you’ll have to fix up the schematic to connect the power pins again. (FWIW, I do this.)

A second way to do it is to create a five-unit symbol, with the first four being the op-amps and the last having a box with just the power pins. Automatic renumbering of reference designators might require some fixup if it swaps one of the op-amps with the power pins unit.

A third way to do this is to hide the power pins. But I didn’t suggest this. This is a bad idea. Very dangerous.


Thanks for the reply. I just assumed there would be a standard way to use the multi unit parts in the standard libraries. I found a YouTube video that shows how to edit it to have 5 units with power only on the 5th. I will just edit the standard one into my personal library of parts that way and also a version with the power pins only on unit A. I might as well do a dual op amp version while I’m at it. A few hundred hours more of using Kicad and I might even get past new user level😀


Yes there is. At least for the official kicad library. (See the KLC and version 2 of the KLC will be published within the next weeks or so.)

This is the preferred method for the official library under klc 2.0. Old symbols will still have the old way of producing power pins for quite a while. (The worst offenders are in the logic family library)


If that’s the preferred way I will delete my other versions and just dit them that way going forward. I might as well learn it the right (ok preferred) way.


Rene, if the 5 unit version of doing this will be the standard, how will the unit-swapping issue be dealt with? Are we getting support for ‘exceptional units’ which are not swappable with the others? That would seem a reasonable way to go to me.


You are correct we will loose this feature until the new format comes out. I (and i think others aswell) think that this is currently the option which is least likely to cause errors. (Sometimes you loose features to gain something else. In this case we gain the possibility to work with multiple supplies.)

There is a workaround for exchanging units:
One simply needs to delete the current symbol and input the unit one wants to exchange the unit with. It is not pretty but it works at least.
(If both units are placed in the same hierarchical sheet one can simply move them around such that the result is the same as exchanging them.)

Having visible power pins on all units would also be an option. (Could cause errors if the user connects more than one unit to a power symbol. I bet this would happen within a week if we change all symbols to look like this.)
Having invisible power pins is not an option going forward. (Does not work at all if one has more than one supply. Or if one wants to turn off parts of the circuit. Or …)

The new library format will support partly exchangeable symbols. (you can have units 1 to 4 exchangeable when having a 5 unit symbol.)
But this format will not come out until next year. (Can even be longer)


Personally I don’t like the idea of a 5 unit symbol with the 5th unit being just a power block.

In my opinion hidden pins are fine so long as that is all they are, they should not be connectable by any means.

As for power pins we already have the ability to have pins that are common to all units and so long as they are visible everything is fine. Sure it adds a little clutter to the schematic so I think all that is needed is the ability to make them visible either on one unit only or all units. When one unit only is selected then the user can choose which unit. If a unit that doesn’t have common pins visible is exchanged for one that does then this “visibility” flag should also be swapped. The default could be visible on unit A only.

I think this would be flexible enough to keep everyone happy yet require only trivial changes to the code. And maybe we could have such a solution sooner than version 5.x.


I know that I’m still a newb here, but I don’t like the idea of a 5th power block myself. That would have confused me and caused quite a bit of frustration.

Since a power pin is only one physical pin, why not write code to make the pin VISIBLE in ALL blocks if that pin is currently NOT connected. Then, once the pin is actually connected in ONE block, have the software automatically disable the visibility in all the other blocks.

The only issue is that there are normally at least 2, sometimes 3, physical power pins on parts. One could assign V+ on block 1, V- on block 2, and GND on block 4. I’d suggest that the power pins be connected in all the same block, but if a user has some crazy reason to want it like I just mentioned, I don’t see any problem.

As simple, or as difficult, as the user wants to make for themselves!


Before KiCAD I worked with Eagle (very old, still DOS), Ultimate (bit newer, already Win3.1) and finally Target3001! and if I remeber correctly the 5-symbol-solution was the standard. Often the 5th symbol is made in a way that you CAN overlay it with one of the actual units to form one compund with all pins. But especially for larger logic schematics with several gates ahving the pins on the gates gets tedious at some point as they get in the way (I know such schematics are maybe not so common today anymore). the same goes for larger combinations of several OPAMPS.

Currently the trend in KLC2 goes towards a 5th symbol!



@Spring: Your solution seems good at the surface but the programmer in me shudders by the thought of implementing it.
A few problems that might arise:

  • What happens if a user changes the annotation of one unit of the symbol?
    • just suppose there is a curcuit containing two ic’s of the same type. One is connected with unit a (IC1a) to power, the other with unit b (IC2b). Now suppose the user changes the anotation of IC2b to IC1b. What should happen.
  • What about hierarchical sheets?
  • Lets suppose this is implemented in the future what should be done in the meantime?

I think the solution by @jkriege2 is the best that can be achieved with the current software.
Especially if the power unit is designed well and can be placed on top of other units. This gives you all the flexibility you need.


Don’t expect any significant code changes for version 5, it must be nearing a code freeze. Any changes required to file format will not happen until version 6. Any changes that require change to current behavior (specifically, affecting the netlist generation) will likely never happen while KiCad keeps a strict “backward compatible” policy.

Given that, the “additional power unit” option seems simplest and can be adopted right away.


Well let’s take @jkriege2’s solution and apply your hypothetical example.

We have IC1a with an overlaid power block and IC2a also with an overlaid power block, now we re-annotate IC2a to IC1b. What should happen?

What about when we move IC1a and part of it (the overlaid power block) stays behind?

What about them?


You will always have the problem of also swapping (somehow) the power-suuply when you have split power-lines!

  1. Say all logic is powered from VCC+GND, then there is no problem, as you can freely swap around … maybe the power-pins are wrongly placed then, but it will not harm functionality.
  2. Say you power some logic from 3V3+GND and some from 5V+GND: Then you are anyways not free to swap around … If you do with power-pins on each symbol you might end up connecting VCC of an IC to 3V3 and 5V thus shorting the two out. So I would say: swapping should be done by hand and minding such problems!

Usually, I would place all power-symbols on a separate sheet or part of the schamtic together with the required decoupling caps and filter RCs/LCs for OPAMPs, when you have more than one such IC-package on the schematic. This way they don’t get in the way of other schematic components. Obviously this does not solve problem 2, but then I cannot imagin any automated/algorithmic solution to that, UNLESS the software e.g. takes into account that a certain symbol-part IS declared POWER-symbol and then only swaps inside a single package or between packages that ahve the SAME connections on the power-part …



Yes, of course, if all of the packages are not powered from the same supply then you need to pay careful attention to how you re-annotate things.

@Rene_Poschl used the example of swapping units between packages to suggest the 5th unit power symbol as a more ideal approach.

My suggestion above is already 75% or more implemented. If you want to suggest making it a more complex mess than it already is then perhaps it should just be left alone. But get rid of the hidden power pins of course.


Unfortunately the remaining 25% requires a change to file format, so that is unlikely to be implemented before v6.


Does it? Of the flags currently saved with a component there isn’t one bit available for common pins visibility flag?


I don’t see one. KiCad records the unit number and text fields for each instance of a symbol/unit. All the other attributes are fixed in the library.


I do a little programming myself, and while not an expert, note that I used the terms related to visibility, and not hidden.

I would hope that there is an ( relatively) easy way to just redraw the extra power pins, and draw it the same color as the background color. KiCad already checks for connectivity at the ends of connections and adds, or removes, visual items based on the status of connectivity.

Anyways, it was just a thought, from someone that is not acclimated to the current quirks. Ask me again in another six months and I might have different thoughts.