I have seen another post where (I think?) somebody else did this…I remembered seeing it and now I have done the same.
I wanted to put a net tie onto an internal layer, but the KiCad footprint editor did not allow me to put a copper graphic line on a layer other than front or back. So I edited the footprint with a text editor. I also needed to use the text editor to put pads on the internal layer.
My earlier post was resolved by the recommendation to include the words “net tie” in the footprint keywords field.
Am I going about this all worng…missing something?
You probably missed that I consider it a bug in KiCad that footprints can only be placed on the two outer layers.
Some people are working on “3D” PCB’s, where parts actually get embedded inside the PCB, and there are PCB’ which are combination of Flex and rigid and not all layers have the same size.
But those are all pretty much niche applications and only interests a very few users. I think it’s also already on the radar of developers, and it may be (guessing here) that a better solution may be part of the implementation of full pad stacks. Maybe for KiCad V7. At the moment getting KiCad V6 ready has priority.
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.
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.
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.
