Hi, Piotr.
FWIW in the early 1980’s the my employer in USA also was doing pcb layout on a light table with tape. I worked for a relatively small company. I am not sure when big American companies might have had access to the first computerized PCB layout. But I think my employer started using pcb design software on IBM PCs in the early 1990s. If I remember correctly (maybe not??) it was called Chancellor and later became Aptos. Later the company used PADS.
ERC checks a lot more than just the pin-to-pin map. I use it all the time, and it’s definitely picked up things that I would have missed on manual review. But you need to understand it, and draw schematics / symbols with ERC in mind.
Thanks. Good counter-recommendation. So I guess it is a matter of “Know thy own work” or something along those lines.
I TOTALLY understand ERC should be about connectivity. Simulation is about performance.
If I put 1MΩ where I need 1Ω that’s a design flaw, not a connectivity issue.
Ditto connecting 120VAC to a 5VDC power input.
Currently ERC will fail the first and pass the second. Not too clever.
I use it all the time as a quick and easy check for ‘sillys or school boy mistakes’ It is in no way forced on you and if you don’t want to use it then don’t, but as it’s there why would you not ? you can ignore it. What happens if something dumb gets manufactured and you know damn well in your heart ERC would have caught it. Honestly I don’t get it but each to their own I say 
Did you look at the schematic I posted in ieLogical with ERC Fixed ?
I corrected your 0vA symbol and M-125 Power Trans symbols to use the proper pin types. I then updated the symbols on the schematic from the revised library. I added a No Connect flag at M-125 OPT1 pin 7 and removed your ERC exclusion. I added three PWR_FLAG symbols; at 0vA, C303, and pin 2 of SW2.
With these modifications your schematic remains largely unchanged, but it now passes all the standard KiCad ERC checks with no exclusions.
KiCad’s ERC can be useful if you work with what it does rather than expecting it do things the way you think it should work.
Maybe we think differently. Maybe there is a difference between power supply designers such as myself and someone who designs microcontroller-based systems for example. When I tried to use it I found a long list of counter-intuitive decisions to be made. They did not seem to help me avoid errors. I do not seem to make the sort of errors which ERC is likely to catch. In fact I do not make erorirs at all. 
Of the KiCad boards which I have made, the only error which I made and which KiCad could have (and probably did) catch was when two adjacent pins of a multi-pin TO-220 were supposed to be connected together on the PCB but I missed that. (The schematic was correct.) The ratsnest line was very short and I did not notice it. DRC (not ERC) would have caught that. It was the easiest sort of rework to bridge two adjacent pins on the board when it did not work initially. But it is a flaw in the result and I wished I had caught that.
My latest board is complicated-er than that other one but runs as designed. Apparently no schematic or pcb errors and no cut traces or kluge rework, even though I did not bother with ERC.
That’s probably it. A lot of the checks are relevant to digital logic and not so much use for analog circuits.
I use ERC because it’s cheap, and easy to correct errors once you’ve grokked the rules. I seldom get any errors first go, and warnings are things like: You haven’t connected up all units. Yeah, ok, I’ll get around to NCing those pins.
But what would be fun now is to take you latest board with know errors (cos you don’t make them 
) and run the ERC/DRC and just see how many errors Kicad thinks you have made 
just for a laugh.Regarding different ways of thinking in various engineering disciplines, you are probably right, and age has a little bit to do with it too, suffice to say with time we do become less flexible
Here we are…
BTW I do use DRC. The biggest thing is the smallest reason; moving all of my silkscreen text off of pads. I do get a lot of overlapping silkscreen component outlines. I use a small-ish 0805 footprint for 0603 chips. Allowing the silkscreen outlines to overlap does not seem to be a real problem.
Awesome now how long to isolate and ignore them so you had a clean sheet of all green ? I’m sure not long, then you would expect a clean bill of health every time. So if an error did occur its one you haven’t seen before and can fix or add to the list of ignores. A cumulative advantage I see but thanks for playing along, you’re a good sport 
My cousin worked at Litton and they had it in the 70’s
I first used PC CAD and PCB software in the early to mid '80s
Getting nearly 300 error where there were none on 7.x.x on a board that’s been working flawlessly for a couple of years says “This software is screwed up!” when no other CAE package in 40 years has ever come close to requiring hours to negate.
IF this was known - and I can’t see how it wouldn’t be - there should be a LARGE warning in the docs and installer that ERC is radically different AND documentation provided listing the changes implemented.
More likely that your original schematic was riddled with errors that the earlier version didn’t catch.
Now that the newer version is more strict, it seems like it’s “creating” errors, when it really is just catching a bunch of poor design decisions.
This is extremely common in software development, where code that used to compile perfectly suddenly generates scads of errors in a newer complier.
Me thinks not.
It’s a Valve [Tube] Tester, it’s worked flawlessly for two years and errors @ 450VDC tend to make things go POOF PDQ 
Sometimes it’s riddled with just a few types of errors and the hundreds of reports are just multiple instances.
I had a circuit that was last worked on in v7 I think and when I opened it up, I got tens of errors and warnings. But it boiled down two really. One was connections off grid. Ctrl-A followed by Align to Grid fixed that. The others were symbol different from library. Since there were all standard symbols, I elected to update symbols from library. And just like that everything came clean.
I imagine a faulty power symbol could cause hundreds of errors. Dennisch has already posted fixes but reading that is not as much “fun” as whinging, I guess.
There are similar situations in software. For example if you were to hand a C program with classic function declaration symtax, it would elicit heaps of errors from an ANSI-C compiler. Running the program to convert the function prototypes will fix that in one go.
Hi @IEales ,
I’ve just been re-reading this thread. Wayyyyy up top you write:
Then a couple of posts down , you state:
If you are using symbols created maybe six years ago (Kicad 4 era?), it is not at all surprising that they fail the current ERC.
I’d already fixed the schematic by the time the fix was returned. While I appreciate the effort, a list of fault causes rather than a ‘fixed’ schematic would have been be far more instructive. I diffed the out and returned text files to see what was done.
That being said, some of the rules are nonsense for other than a limited scope and the ‘fixes’ are bandaids that could fail in the next iteration.
Some of the additional requirements for an ‘error free’ schematic fly in the face of “Keep It Simple, Sonny”
V5 in early 2019.
V8 installer could have had a dialog stating major changes to symbols, power rules and DEI silliness scotching every _Male / _Female symbol in existence.
Had I ever done something like that, at the very least the installer would have a list of obsoleted parts and if I had the resources, a utility to update them!
Since the files are text, bog simple for most cases w RegEx.
A handful of faults is easier to rectify than hundreds x the user base!
That being said, some of the rules are nonsense for other than a limited scope and the ‘fixes’ are bandaids that could fail in the next iteration.
You as a designer are responsible for adjusting the violation severity for all ERC checks. You can’t delegate this task and simply blame kicad. While you find some ERC checks nonsense there are other users who find them useful. Most of these checks were implemented because someone had a usecase and asked for the check.
So if you find some ERC checks nonsense, just disable the relevant check (File->schematic setup–>Electrical rules–>violation severity). Or don’t run the ERC at all.
As development goes on you will find enhancements to the ERC/DRC on every major kicad version. If you don’t like the new checks: switch them off.