eEschema not allowing alternate GND nets (such as GNDREF)


#1

Hi,
I have certain components in my design in which I’m trying to have a separate GND, specifically, I chose GNDREF. The reason is, these particular ICs are very small SMT devices and the design rules for the rest of the board don’t allow the narrow trace widths and clearances needed to route power and ground to them. I thought it would be lower risk to keep the more conservative rules for the larger components, and only have the tighter rules for these small components. It worked to begin with, but something has happened, where eEschema will no longer recognize GNDREF. Here’s an example schematic:

And here are examples on the netlist showing that the GNDREF pins were changed to GND.

Does anyone know how I might fix this?

Thanks.


#2

You probably tied together gnd with gndref, and kicad chose to to name it gnd


#3

If there is more than one label on a net, KiCad will pick one arbitrarily. (Power symbols are like global labels).

To use separate GND and GNDREF, use a “net tie”. You can draw a special component, or just use a 0R resistor, or jumper symbol. On the PCB, you can join the pads with a trace (and ignore the DRC error).


#4

Dave (@onedashtwo81), the concept behind “net tie” is to draft the affected nets as distinct and separate nets, but connect them in such a way that KiCAD doesn’t recognize it as a connection. (Or blatantly connect them and, as @bobc says, ignore the DRC squawk.)

There is a discussion about “Net Ties” at Protip #2: net tie . For some reason I thought a “net tie” component and symbol had been recently added to KiCAD but I can’t find it, so I guess not. Perhaps that was a residual thought from a previous incarnation, when I was using P-CAD.

Dale


#5

Hi guys,

Thanks for the replies. Actually, I did take the net tie approach. See the graphic below.

Notice I also have a separate 5V net called +5VL. Initially, both worked fine. +5VL is still intact in the netlist. I had found a video on youtube about making a net tie. Coincidentally (?) it seemed to be after my implementation of the net ties in the PCB design that the GND / GNDREF problem started. To create my net ties, I modified an 0805 resistor footprint by putting a line on the silkscreen layer (or maybe it was the Margin layer) between the two pads. Then I changed it to Front Copper Layer. Maybe I’ve done this wrong, so I’ll take in your suggested reading.

Thanks again.


#6

Go over your schematic with a tooth-comb and check wires for GND/GNDREF… you made a direct connection (net-tie-less) somewhere, that’s for sure - maybe even inadvertently, by using a symbol with hidden pwr pins?
The nightlies would make this easier, as they are able to highlight wires/nets in eeschema…


#7

Joan_Sparky you are very insightful. But can you or anyone else explain the problem to me? Below is the culprit.

I used the stock component for 74LS14. Shown here are two unused inverters, and power applied (using my alternates, +5VL AND GNDREF) to the invisible pins on Unit C inverter. If I remove the wire between GNDREF and Pin 7, GNDREF reappears in my netlist correctly (except for this one missing connection). I put it back, and I’m back to the problem. How can this be?

Thank you so much! Worst case, I make a new component for the 'LS14.


#8

Invisible power pins behave the same as power labels.
This means you connect GNDREF to GND here:

Yes the 74xx lib of kicad would need a bit of work to remove all the power pins. I think @bobc started with it but he has never opened a pull request on the official repo to exchange the symbols.


#9

@onedashtwo81
The good news is, you’ll fall for this only once.
The bad news is, we all fell for it once :slight_smile:


#10

I had the good fortune of reading about the dangers of this here on this forum. So i never had to fall for it.


#11

Oh yes, hidden power pins, I should have guessed :slight_smile:

To be honest, I didn’t get much positive feedback. People who did express an opinion suggested mutually exclusive features, and there seemed to be little interest in building a consensus to resolve a way forward. At least one person said I should just not bother at all… I sort of lost interest and started looking at other things.


#12

I had the same problem when i started with the new connector symbols.
Once i was happy with them i simply created a pull request and they where merged two days later with only some small changes.
I think as long as it is only in an issue people think they can discuss endlessly. As soon as it is a pull request and the symbols can be looked at, the sentiment changes. Suddenly you only get constructive criticism about real problems. (Wrong footprint filters, …) The discussion about the graphical style suddenly stops in such a case.


#13

Ok, I did some more tidying and took your advice…


Let’s see how it goes…

I think I am fairly pleased with the result, it is impossible to satisfy all of the KLC requirements because they are mutually exclusive in some cases, but I got fairly close.

What worries me slightly is that I found several cases where the original symbol is plain wrong, i.e. wrong pin numbers. Tracking every data sheet and checking is a HUGE task, I did quite a few but the majority are unchecked. Many of the older 74xx are obsolete and finding data sheets is a job in itself. Perhaps the fact no one has raised issues suggests very few people are actually using the symbols?

I am wondering about how to cross-check with other data sources, e.g. gEDA or Eagle libraries. If only there was some industry standard database…


#14

Very few new designs using anything except some latches and buffers. Many of the more complex TTL parts were almost custom parts for pre-asic computers


#15

TTL Datasheets


#16

First and most importantly, THANK YOU! This has been niggling me for a while but never to the point of fixing it. So, you are awesome and this is greatly appreciated.

One comment, a few of your pin lengths are odd sizes (e.g. 74LS30) and placed on a 50mil grid (e.g. 74LS21) instead of the standard 100mil. Would you be amenable to a pull request on your branch or were these conscious choices?


#17

You’re welcome :slight_smile:

The 74LS30 (I guess the de Morgan variant you are referring to) suffers a bit, because I use the same symbols for all gates. For the grid spacing, I couldn’t think how to get the 100 mil grid and also meet other KLC requirements.

Sure, no problem.


#18

In my connector commit i decided to “ignore” the center requirement. (@jkriege2 requested it that way.)

So all my connectors with an even number of pins are moved down by 50 mil such that the pins are on 100 mil grid.

I seem to remember there was an issue where we discussed this but i can’t find it anymore. You participated in that particular issue as well and i think you gave the input that center for an engineer does not always mean the exact center. (Sadly i can’t find that discussion any more. I wish github would have a way to show me comments i made.)


#19

Yes, I’ve considered that. That fixes the input pins, but then the output pin is 50 mil off…

There are certain laws of mathematics at play here which I have spent a fair time studying and not found a solution :slight_smile:

We could do this, looks a bit funny:


#20

I’d prefer that to an over sized symbol. I have a resistor size in between ‘normal’ and ‘small’ because it just fits the values in. (That solved the desire to go to the US custom of a zigzag symbol since I now use that space. :wink: )