Errors I cannot understand - ghost pins

Hello,
Below is a simple circuit I’m working on and the associated run errors.

The errType5 Conflict between Pins is the one that bothers me.

It’s referring to PIN4…which there is no Pin4.

This has me stumped. Thanks for any assistance.

First - green ones: Power port +3.3VA neither GND isn’t valid power source(s). This is only a special global label. You need a component which will act as power source on VI(@U3) pin (has power output pin) or use special PWR_FLAG component.
Second - red one: The VO(@U3) are power output pin and is in conflict with VCC(@U2) also defined as power output. I suppose the ESP-01v090 are bad designed. You have to pass this symbol to library editor and set “Power input” instead of “Power output” for VCC pin.

1 Like

All your pins are defined as a power input or power output. Just by looking at the symbol I don’t think it is the case. I would recommend going to the symbol editor and changing pin definition to reflect actual pin functions. Otherwise stick a power flag on every pin and all those pesky errors will go away. Of course then you effectively disabled your error checking for that particular function. Pin 4 for U1 is probably an invisible pin. Should be able to see it in the symbol editor

2 Likes

Someone add heatsink tab as pad 4 and hide it. KLC political correctness… :slight_smile:

1 Like

Can you explain “U3” ?
I don’t see a U3 on the diagram?

Unfortunately, despite all the well known problems with hidden pins, the KLC allows and even encourages their use (stacked pins) which is a really bad idea IMO.

2 Likes

Since when are hidden pins a problem when they are not defined as power input? (KLC is very clear about the fact that hidden power input pins should not be used. Sadly we don’t have the manpower required to get rid of all hidden power pins in our lib. But we are slowly getting there. Thanks to your effort and to the effort of some other contributors.)

Stacked pins are the only way (in kicad) to assign multiple footprint pads to the same function. (If power pins are stacked the hidden pins are required to by of the type passive.)

1 Like

You carefully crafted your question to exclude the case where they are a problem, I consider that a very disingenuous use of language. You should be a politician!

That is obviously not true.

It does amaze me that despite all the evidence to the contrary, what people still believe. Hidden pins are just a bad idea, there is no gilding that. KiCad does not help by connecting any pin regardless of visibility or if marked no connect.

2 Likes

You also should be a politician. you left out the part of my statement where i stated that hidden power input pins are not allowed.

How would you do it? (Assuming you don’t want to have footprints with multiple pads having the same pin number)

  • THAT IS BECAUSE YOU EDITED YOUR COMMENT AFTER I REPLIED *

Rene, I am not going to argue with people who post in bad faith. Sometimes I think you disagree just for the sake of it.

1 Like

It was not my intention to insult you.
I might be a bit too defensive when it comes to discussions about the KLC.

It is still kind of unfair if people criticize us for allowing stuff that is not allowed under the current version of the KLC. (Hidden power input pins are disallowed at least since KLC v2 [rule 4.7.ii], which came out ~ 1 year ago.)

My first instinct is that everyone is talking about the current version of it.
The reason why i edited my post is because after reading it i remembered that some people might not have read the latest version of the KLC.

Your answer appeared a few minutes after i submitted my edit. That is why i assumed you where picking the part of my post that was convenient to you. But this can be explained by server delays.

I hope this clears up some of the misunderstandings i think we had.

If after reading the current version of the KLC you still think we allow too much please feel free to post criticism about it. But try to give reasons for it and maybe even a suggestion for better wording. (Remember english is not my first language.)

Edit: The KLC does not even allow stacking of (power) output pins. The hidden pins in such cases need to be of type passive. (Otherwise ERC will report multiple output pins to be connected.) This is also true since KLC v2

Again we lack the manpower to get all symbols up to the standard of the KLC. (We don’t even have enough manpower to check all contributions in a timely manner.)

I would really like to point out the following:

Basically the way KiCad handles hidden pins at the moment, makes it possible in schematics to accidentally connect hidden pin. Regardless if it is an “input”, “output”, “bidirectional”, “passive” or even “not connected”. While ERC might catch some (or even all - I have not checked) of these cases, this errors are always a surprise for a designer. Even more so for a beginner or even a sloppy beginner who does not run ERC.

Don’t get me wrong, I am also of the opinion that some pins can and should be hidden. But in my symbols I rotate them so that they have connection point within the symbol.

It looks I was very tired last night, and giving sh…t. :worried:

I’ve heard of giving birth. I suppose sometimes those can be closely related experiences

I’m not arguing in bad faith (not really sure what that means, but I’m confident I’m not:slight_smile :slight_smile: ), I really want to know what other options are there to connect two separate pins on the symbol level? I try to avoid invisible pins as much as I can, but sometimes there is just no way around it.

I REALLY want to thank all those who have given their time to help create this most excellent tool!

KiCAD is an awesome development platform and it’s done without obligation to pay for it.

Where can a donation be made to support the effort?

2 Likes

https://giving.web.cern.ch/civicrm/contribute/transact?reset=1&id=6

1 Like

Hidden pins convey absolutely no information whatsoever on a schematic, especially a printed schematic. I am of the opinion that every pad on the PCB should have a corresponding pin on the schematic, even if only to indicate that it is N/C.

5 Likes

Does everything in the symbol have to convey information though? You have a field that describes electrical type of the pin in a symbol and it is invisible, it doesn’t really convey any visual information. But that’s beside the point Here is an example that describes the issue at hand - let’s say you have a power FET in a multi-pin form factor, which means you have multiple pins connected to source and drain to increase current handling capability. Now we all familiar with FET schematic symbol. It would be just ridiculous to have multiple pins sticking out of the drain and source of the FET. Currently EEschema can’t handle multiple pin number assignment to a single pin. Sooo, what exactly do schematic symbol purist suggest in a situation like that. You can put S and D as a pad number in the footprint editor and they all will be assigned to S and D pins of the schematic symbol, but then you need to have two (or maybe more) versions of the same footprint - one would have all pads numbered and the rest would have different variations of source, drain and gate pads. If I have to choose, I’d rather have invisible pins in the symbols, than multiple confusing versions of the same footprint.

This comes down to individual taste and saying somebody is wrong in his/hers opinion without knowing the full context can lead to flame wars. So I will conclude with De gustibus non est disputandum.

1 Like

[quote=“Andy_P, post:20, topic:8868”]
I agree. The schematic serves two functions. One, it’s the “source code” for the board layout. The second is that it conveys valuable information to the human who did the design and the human who has to build it and the human that has to test and repair it. . . . [/quote]
:heart_eyes: :grinning: :kissing_closed_eyes: :sunglasses:

It would be easier to do this if KiCAD permitted us to simply collect all the power stuff (including fuses, bypass capacitors, ferrite beads, etc) onto a separate sheet without encountering the complexity of hierarchical sheets.

Dale