I have power supply designs that use very low Ohms current sense resistors.
These need a 4 wire connection.
As pins 1 and 2 and also pins 3 and 4 are DC shorts, DRC complains.
What I need logically is a double net-tie
How does KiCad treat Net-Ties specially?
Ideal case is the footprint editor would permit creating a 4wire part: 2 high current, 2 kelvin. However… every time I tried to place copper and resist within the footprint area the DRC for the footprint complained about tracking within the footprint…
I settled for just using a 2wire part and using net-ties to create the 4-wire
Then I place the net-ties where they should go and track differentially away
Not the nicest way but with the help of replicate layout, this becomes repeatable across all instance - they need to be matched after all 
ideally this limitation is resolved somehow so a true 4wire sense resistor like this can be formed
3 Likes
Raised on the issue tracker
1 Like
nice! I just posted a quick info about the type of violation
I think right solution is to build a nettie into your resistor footprint. Look at nettie in fp editor to see how it’s done, essentially two pads connected by a copper polygon.
This is the underlying question, how do Net-Ties work without triggering DRC
Just open a Net-Tie in the Footprint Editor:
In KiCad V5.1 a Net-tie consists of 2 SMT pads that are wide enough apart to not cause DRC errors but close enough so nothing can be routed accidentally between them, and a polygon on the same copper layer to connect the two pad. This is a hackish “intermediate” solution, and according to BobZ (below) already changed in V5.99.
What is the physical size of the resistor? One method which I have seen is to create 3 pads (left, right, and center) to mate with each resistor terminal. The center one is the Kelvin sense. It is narrower and can exit through a via or towards the center as you are doing in your example. So the symbol and footprint would have 6 terminals even though the component has only two. Really the (3 pads per component terminal) assumes that symmetry is worthwhile (it may be so) but if that is not needed you could try 2 pads per terminal. I am not sure about 0805; I think the 6 pad method would work best with 1206 and larger.
See the Kelvin sensing recommendation for this datasheet.
What does that mean to software dummies like me?
In 5.99 netties are hardcoded 
@BobZ
that means they are special case with an exception in drc code that just ignores them when calculating copper clearance.
If I am not mistaken in 5.1.9 drc ignored all in footprint polygons so this exception was not needed.
Ergo building nettie into resistor will work for 5.1 but not 5.99.
Well an easy way to trick 5.99 is to add “net tie” prefix to keywords of the footprint so the trick still works.
Just looked at a Net-Tie in V5.99 and it looks pretty much the same as in V5.1.x. Two SMT pads and a Polygon.
The text qu1ck links to:
// A bit of a hack until net ties are supported as first class citizens
bool IsNetTie() const { return GetKeywords().StartsWith( wxT( "net tie" ) ); }
I do not like messin’ with footprints in this way, and therefore would prefer Naibs method of just adding net ties as separate entities in the schematic, until it is fixed in a proper way.
So Net_ties in 5.1 allow illegal tracks
This proof of concept allows me to route a track straight though the Net-Tie and DRC incorrectly complains about the Net-Tie pad not being connected to the zone, while not detecting the short
That would explain this:
–> https://gitlab.com/gkeeth/kicad/-/commit/9b82fd8b176d6e2a64d500fa7b9f8daf6f0b505a
We really need to do first-class net ties…
It’s a hack before something more versatile exist. The part I don’t like is it is an actual copper part and thus can only go on TOP/BOTTOM.
1 Like
So the 5.99 hack is a change that breaks backwards compatibility without solving any of the problems?
We did not intentionally change any net-tie behavior in 5.99 – if there are things broken, please open issues. We originally planned to have better net tie support for 6.0 but this got delayed to 7.0, so net ties should be just as hacky in 6.0 as they are in 5.x
Not so much, the report I linked looked like something about net-ties was removed but this broke old designs so it was re-introduced until something better comes along.
Some form of net alias is required where nets can have different names and then be part of different constraint groups.
Think about why net-ties are used? its because when it comes to layout something extra is needed to help influence the design - Two or more electrically connected nodes (sense resistor, reference point…) require different physical implementations
The plan for 7.0 is to allow footprints to specify that certain pads are allowed to be shorted to each other as net ties, but not others. This would solve this 4-wire current sense resistor case and also various others. Unfortunately this change is fairly complicated and there was not time to do it properly for 6.0
that sounds good and solves one part of the reason net-ties are used.
What about alias netnames?
Two cases I have dealt with recently
-
Sense resistor (see my screenshots above). I require the sense pins to be tracked as diff pairs and thus the _N and _P suffix
-
clock fanout to multiple ADC are driven from a buffer and thus net-ties are used to identify different ones
In the case 1, you can give the net names whatever names you want in the schematic. Your schematic symbol will still have 4 pins so you can give the sense nets your diff pair names as needed.
Edit to be clear: What I mean is that a current-sense resistor can be drawn as in davidsrb’s first screenshot at the top: a 4-pin device (not a two-pin device with separate net ties as in your reply). You will be able to say in the symbol editor that pins 1 and 2 should be shorted as a net-tie, and pins 3 and 4, but those two sets of pins cannot short to each other.
Can you say more about case 2 / post a picture?
Consider this
NOTE: it might be OTT to give each one a label but this is one example.
Another one is with Hierarchical blocks where without such a net-tie, whatever netname is connected to a hierarchical connection will propagate
This one was quite important because DCN had 2mm clearance (its 270V). Without the net-tie aspects of that constraint would have propagated to the sense circuit and well … try tracking a SOIC8 on 0.127mm pad spacing with a 2mm constraint - a violation at the tie was a small price to pay : NOTE this was done in v5.1.x and the newer constrain manager might make this easier, but there is still a need to label different parts of a net differently