Thank you, Paulvdh & Craftyjon. It seems to me that the net tie is more or less of a “bugaboo” for all of EDA and I wonder whether it should be its own “thing”. So in other words, not a track or a component or a graphic line but a separate entity. It is not used so often so it would not need to be a top level menu item unless there is no “other” category in which to fit it.
Part of the reason for my post is that I wanted to add my vote for net ties on internal layers…
Separately from pads on internal layers, net ties are getting a refresh in V7 (but I don’t think they are going to be a separate “thing”, rather we just want to remove some of the restrictions and make them more flexible than the current implementation).
Right now a net tie requires multiple pads, but in the future it will be possible to have single-pad net ties (on any layer). It will also be possible to create footprints that include multiple independent net ties.
The current implementation of a net-tie is a quick & dirty improvement that builds on previous “hacks”. A real solution has been pushed into the future because of more important features, and because KiCad developers are volunteers and (mostly?) free to work on parts that interest them personally.
Older versions of KiCad did not recognize graphics on copper layers at all, and would route tracks through them as if they did not exist. Later, code was implemented to recognize (and flag) DRC errors for clearance violations of graphics on copper layers, and this necessitated to implement a way to make net ties pass DRC, and that is probably where the “net tie” keyword was added. (Quite unfortunate to use two words with a space as a “special keyword”.)
The current solution is not optimal, but it’s workable.
It’s also flexible. You can quite easily create a net tie footprint with multiple pads and use it for a one-off star grounding point.
I once had a proposal to be able to flag a track segment as a connection between nets, but that Idea apparently did not fit well into KiCad’s code. It has to fit with DRC checks, the Interactive router, and with the connection between Eeschema and Pcbnew, which normally uses footprints and pins for this.
The new net ties will be able to flag a single pad as a tie, so if you wanted to make that pad the shape of a track, you could do so
I don’t understand your question. A net tie does not need to involve a polygon, but it can if desired.
ATM the net tie footprint are all based on a fp_poly graphic element to trick with the DRC
It will be possible to create different types of net ties in the future – they won’t all have to look like the ones in the current KiCad libraries with two pads connected by a polygon. However, they will still need to involve footprints or pads – it won’t be possible to select a track segment and make it a net tie.
I thought the plan was to make them “first-class citizens”, i.e. a “thing”. It would be a separate entity in the schematic, but a track or a via could work as a net tie in the layout: https://gitlab.com/kicad/code/kicad/-/issues/2018. Or do you mean just that?
Well, first of all that issue needs to be split and updated, as it covers a bunch of different concepts, and these days we want issues to be more narrow in scope. So, I won’t cover star routing and decoupling capacitors.
A track or via is not a good candidate to be a net tie in KiCad architecturally, as Paul said. Technically it would be possible with a standalone via, so we could look at adding that at some point.
The “first-class citizens” thing is about defining net tie behavior more formally rather than looking for the net tie keyword in a footprint and then changing how that footprint is treated. The current plan is still that net ties are defined around pads (one or more pads that are allowed to form shorts between nets). The implementation detail of how this will be handled in the schematic is still being figured out, but at the end of the day, they will still be symbols and footprints, not some new kind of object. Net ties will just make use of some new features added to symbols/footprints (kind of like how alternate pin functions were added in V6).
Is the “Group” thing in KiCad-nightly a good candidate for formalizing net ties?
Something like a footprint with some pads and a polygon inside a group, and when you enter the group, you can move the pads and modify the polygon to suit a particular situation.
For me it does not matter much. I am used to managing my own libraries when needed and modifying footprints to fit particular situations.
I don’t think the formal implementation will be related to groups. You could certainly make a group inside the footprint if you wanted to, but the formal net tie specification (Pad 1 and 2 form a net tie, for example) will not involve groups. We want to support “single-point” net ties, but it’s not yet clear if we will do that using a single pad, or multiple pads stacked on top of each other.
RIght now it’s a limitation of the current system that the net tie footprints have to use two pads connected by a polygon. When we remove that limitation, if you wanted a specific shape for your net tie that is specific to a design (rather than being stored in a library) it would probably make sense to use a minimal-size net tie (like, a single pad that is the same size as the track width you are using) and create any “extra shape” on the board rather than in the footprint.
So does that mean that I am missing the polygon? I used a “line” and not a polygon. A week or two ago I searched FAQ for how to implement a net tie and did not find it.
One quirk of mine is that I pretty much use only my own footprints. “NIH” (That is not the National institute of health) is the rule! 
Being able to join nets at a single point is a good idea, but I hope it will not be the only solution.
I like the separate pads + polygon in the aspect that it adds physical separation in a way that is specified in the footprint itself.
For example, the feedback point of current sense resistors can not sprout off in a random direction. If that has to be done by locking track segments it will be a step backwards.
Also related to this, are footprints that consist of copper tracks, such as printed inductors, antenna’s and RF things such as in the “microwave toolbar”.
In the latest Ucamco Gerber specification, I read that such items can have their own layers and definition in Gerber files.
A line should work also. You just need net tie at the start of the footprint keywords field.
I am talking about additional ways to do net ties, not getting rid of the current way.
Sounds good; thanks.
Could you please let me know what for practically are net ties used.
I have never used any.
Later in thread the RFID antenna is mentioned. When I needed to do one I just had no time for experiments and I have done it as one net (routing tracks as I needed). I think tracks are not allowed in footprint so I thought it will be simpler just to route it and not try to define footprint. But from reuse point of view it would be better to have footprint for it.
I am in 5.1.10.
NET Tie user’s case:
Hi, Piotr
I do not want to compete with the Altium documentation but it seems to be pretty Altium specific. I think that the net tie is very useful but not essential. My argument is my opinion and is somewhat complicated:
1a) This could be done with a 0 ohm jumper but the net tie is more versatile and avoids needing a physical component.
1b) Defining separate grounds is not essential but it is the BKM (best known method) of describing the interconnection of grounds when you want to separate noise generators from noise sensitive parts of a system. A pcb layout person could keep all of this in her/his head and do it manually with only one ground, but then the requirement is not documented and errors seem more likely.
2a) Net ties are also useful where you need to control connection points and net classes. Many times I have seen a “silver box” power supply which produces 100 - 200 Amps of output current. The output connectors are large (1 cm?) diameter brass or copper machine screw stud. But also connected to those studs are suitable large diameter ring terminals crimped to small gauge wires (such as AWG24?) which is the output sense wire. Whereas the main output current is >100 Amps, the sense wire might handle 1 mA or less. The output and sense wire are both connected together; should they be the same net? Will you use a 100 Amp net class rule for a sense wire which is carrying 1 mA? Placing a net tie between the output and the sense wire resolves that question by allowing the interconnection of an output power net to a sense net.
Net-ties are a hack in every single eCAD I have ever use and the fact they are a footprint limits their placement to F.Cu or B.Cu. being able to place on any layer would be ideal.
Now Mentor do have a net Alias where you do something like foo|bar to provide the alternative name at a junction (main branch is foo)
Likewise Mentor does have this nice thing called “net ordering” which can help in identifying what part of a stub is where, handy if you fork a signal and you need equal lengths (IE clock distribution)