PIN NOT CONNECTED 8.0.8 Errors that never occurred since v6.x.x

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 :face_with_open_eyes_and_hand_over_mouth:

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.

But then what’s the difference between an inductor with high resistance and a power filter of milliohms resistance? It seems you still don’t understand that Power Input/Output types isn’t about current flow, but rather providers and consumers of power, and the kinds of errors these types are intended to catch. If everything that passes current including megaohn resistor passes on the type to the other pin, this error check loses value.

But by all means put in a Feature Request at Gitlab. Good luck! Bye!

1 Like

I used to try to use it but gave up on it a few years ago. Not worth the trouble. My new board works well so I was not hurt by ignoring ERC.

I wonder whether anyone finds it useful??

Good Bye! Luck! :crazy_face:

And if that is not available, grab the nearest cat.

You would have to flag these bridging components as power transfer parts. The time it would take to do this accurately would take longer than just understanding and ignoring the ERC warnings

I think it was useful in times when circuits containing many, many TTLs were designed. ERC could find not driven inputs or outputs connected together what in big mess could happen.
In 1981 using TTLs I have made chronocomparator (device to measure electronic watch speed without even opening it) and in 1984 I have made TTL digital frequency counter. But then I didn’t had access to any PCB design software so didn’t used ERC. But if we imagine someone designing computer made from TTLs…
Nowadays when my schematic contains processor having all pins bidirectional and just some discrete elements around it there is practically nothing ERC could check as it can’t check if there in software pins will be set according to how they were used at schematic.

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.

3 Likes

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 :neutral_face:
:mouse:

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.

3 Likes

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

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.

:smiley: :zipper_mouth_face: But what would be fun now is to take you latest board with know errors (cos you don’t make them :smirk:) and run the ERC/DRC and just see how many errors Kicad thinks you have made :face_with_monocle: 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 :smiley:
:mouse: