Folk conceptions of the pin electrical types are often erroneous. Power Input/Output are not based on current flow direction. Transformer windings should be Power Output even though AC. Bidirectional is for digital logic. Output is mostly for digital logic.
It’s totally possible to create even a large non-trivial schematic without using ERC. The situation is very different with the layout where DRC is critical for success. I don’t outright recommend ignoring ERC, but at least those pin types are so pesky that I’m tempted to tell you to turn the Map green if you have even slightest difficulty with those pin type errors/warnings.
There are two big problems with the pin type check. First, you have to understand the types (and I don’t). Second, you have to have clean libraries, built from the beginning using correct pin types for everything. Mostly you can’t use any 3rd party libraries, or at least you have to fix everything manually which takes more time than creating from scratch, even when a symbol would otherwise be OK.
That’s what I thought, but most of the transformers in the library have ALL passive pins.
I set the CT to passive to clear the PWR_FlAG error.
I’m down to 1 nonsense error and 1 nonsense warning and just clear them.
Thanks for all the help. 
ERC finds silly errors like open pins.
But if there are too many nonsense errors, people won’t use it.
You should mark pins left open intentionally with a No Connect Flag from the toolbar on the right.
1 Like
Here is a slightly modified copy of your schematic and libraries modified so all ERC checks pass.
M-125_ieLogical (fiixed).zip (383.5 KB)
1 Like
I prefer Passive.
There is a case for secondaries being Power Output, but what about AC power primaries and audio transformers?
Making secondaries Power Outputs also gets you in trouble if you have a centre tap to GND.
Valve heaters should also be passive - there are cases where you wire them in series.
No single pin type will be correct for all cases. You may have to adapt the symbol to suit your design. It depends on which errors you want to catch. Internet libraries usually chicken out and declare everything passive, or worse, unspecified.
My opinion is that ERC is mainly useful for catching the frequent novice mistake of power symbols connected by wires across capacitor terminals.
It doesn’t understand the function of the components, so it will not check the circuit.
There are many attitudes to ERC. Some people avoid it. “I know what I’m doing”, “It’ll cost me more time to get it correct than it’s worth”. Some peole grudgingly use it but are tripped up by the pin types.
My opinion is that to get the best out of ERC you have to be willing to edit pin types. There are only generic symbols for transformers so you may get by with passive for al pins but then you will miss a class of errors for power transformers.
For example say the transformer feeds a 5U4GT rectifier. So you assign Power Output to the transformer pins and Power Input to the 5U4GT anodes since it’s always a power rectifier. Now you replace the tube with a pair of Si diodes. There is only a generic symbol for diode. Diodes can be signal, power, etc. So either you assign Power Input to the anodes, or you go back Passive.
The main thing is to understand what the checks mean and decide whether you want them. There are some checks that are not represented in the compatibility table, such as Net with Power Input needs exactly one Power Output pin.
I was sure that OP’s sentence tells about capacitor pins being changed from passive to bidirectional.
KiCad can’t know what do you think.
Except if KiCad understands it as a single mistake and is defined to report it only once pointing one of occurences.
Reading forum since 2017 I don’t remember anyone who chose the path of changing pin types of elements. One can assume that this only deepens the mess.
And you could not touch ERC 
I’m happy with not running it at all.
As I said earlier, the changes to the transformer were made to get rid of 300 errors and warnings.
IF the v8 Pin Conflicts Map had been in the documentation AND there were more than a 4 line blurb about symbol changes, this thread would likely never have started.
Valve heaters in series is a sure way to have problems, especially as tubes age.
It was done in TVs & radios to drive them directly from a 110v line.
Agreed.
However, when I’ve used KiCad for nearly five years [and contribute $] without need for support, get slammed with 300 errors, and the same old Pin Conflict Table and a four line blip about power pins and symbols there’s something rotten in the state of Denmark. Definitely not fond of being a Retail Beta Tester.
Pin type errors are definitely the most frequently asked questions about KiCad schematics. If you want to opt out from the Retail Beta Tester program, you can file an issue to the gitlab issue database about this usability problem and tell that it wouldn’t hurt to make these pin type tests opt-in, i.e. silenced by default, and whoever is willing to learn and fix all their symbols can turn them on.
Personally I really think that these test are problematic in many ways and I would vote for that issue. (There are other ERC tests which are actually helpful for anyone, only the pin type tests are the usability problem IMO.)
Will do.
Designing matrices for error checking is no picnic.
Currently, a valve heater as Power Input is fine connected to either other valves or a resistor Passive. But no-can-do parallel Power Input to Passive.
From the manual: Power input: …“The default Pin Conflicts settings allow power input pins to connect to most other pin types. However, power input pins that are not connected to a power output pin generate an ERC violation.”
Seems contradictory. Any time anyone puts a resistor or inductor in a power line, there’s going to be an ERC violation.
A useful feature would be to allow passives it ‘inherit’ so that inline devices don’t generate ERC violations.
My two cents on ERC - Overall it’s a necessary nuisance, but there will be the time it catches a subtle error that crept in when you’re moving or dragging circuit blocks to Tetris in another part or section…
1 Like
It’s in this section:
This has been suggested before for fuses, 0 ohm resistors, jumpers, filtering inductors, but ERC is not intended to analyse circults. Sometimes, human judgement is necessary.
2 Likes
I must have double tapped Next in Acrobat 
It’s not analysis, it’s a quite simple decision that goes a step farther than just comparing just the connected pins type:
Net Termination Pins: Power Input. → Net Origin: Passive. → Origin Device: Two pin. → Driving Net: Power Out. → PASS.
Any failure generates an error.
As it is now ERC will discourage people from using it and thus make scrap.
Yes, but you then have to manually decide when an inductor is an inductor and when it’s acting as a power filter.
ERC is more useful for digital circuits where the types are more standard, and needs less tweaking, This tends to be most of the circuits nowadays, for better than worse, IMO.
¿QUE?
An inductor is always an inductor. It passes DC and affects AC.
A resistor passes both.
We have spice to analyze performance if we’re making filters.
ERC should be able to handle passing current.