But I have a related question.
First of all, IMHO a jumper can be used as a switch/assembly option or to jump over tracks or both. Why constrain it?
My real question is: in the case where I am jumping over tracks, I might know that the jumper will always be installed. Sometimes it would be nice to have the same netname at both ends. But I do not think I can do this in KiCad. Why does that jumper connection need to be any less solid connection than a track, if I will always install it?
But how do you convey that information to KiCad? Maybe you can use a net tie symbol there and assign it a jumper footprint?
Oooh. Aren’t we really discussing a
?
A net tie looks physically like one net but is intended to be two.
This jumper looks like two nets but is intended to be one.
Ok I got mixed up, you want the converse of a net tie then, maybe a net untie, or an unnet tie? No idea if such a beast can be concocted.
LOL. You have me thinking about a track in the shape of a (real tied) bow tie.
This might be where things have gone wrong. What do you suppose would be nice about it? Because I think it might break the ability to route the PCB, in the traditional way. To wit:
Imaging you have a net that goes from plug P1 through jumper J1 to plug P2. What normally happens is two nets are created, one from P1 to one pin of J1 and another from the other pin of J1 to P2. To satisfy the netlist, you must create tracks that form the two routes. Pretty straight-forward so far.
Now imagine J1 is the proposed “untie”. This time there is only one net, which is connected to P1, both pins of J1 and to P2. When it comes time to route you must draw a track between P1 and J1, and between P2 and J2, and then… a track between the pins of J1! Of course, if that were possible then you wouldn’t have J1 in the first place.
So perhaps there is no converse of a net tie, because it would cancel itself out…
I do not see it that way. If J1 is a net untie, why can’t KiCad treat it the same way it treats a section of track? Normally you might have a one-net track with several angles joining P1 and J1. Now you remove one section of that track and replace it with J1. Now (in theory) why can’t this work the same? Similar to going through vias to a section of track on another layer. The air wire is another layer. Maybe both ends of the jumper need the same pin number?
And…maybe we are discussing the esrevnoc of a net tie? 
Oh yes, I see. As if the footprint has copper between two pins with the same number, except that the copper does not appear on any board copper layer. As you say, in a “air” layer.
Funny, it reminds me of this footprint:
As is often the case, the shield/mechanical “pins” have been given the pin number “0”, which is fine, except even though I’ve marked the pin as “no connect” in the schematic, I’m still required to run a track between them to satisfy the rats nest. In fact, the “connection” is already satisfied through the air, via the part itself
Maybe: File > Board Setup > Physical Stackup > Copper Layers should also have Air Layers?
Maybe what you want is a jumper symbol where both pins are 1. Then KiCad will insist on them being connected together, but by some hackery or special casing, this is forced to happen through an unused layer thus satisfying ERC but will not result in an actual track.
A net eit perhaps? 
The question also arises from time to time for instance regarding 4-pin tactile switches (where most often 1+2 and 3+4 are already internally connected). There is currently no solution for this case.
A open gitlab-issue is #2558, but there was not much progress.
Seems like someone must make a fundamental decision (how to implement this feature against what disadvantages shows this feature).
One possible workaround: What about a layer that does not output to the gerbers? Then it will look like a track but it will not be fabbed. And maybe some other constraints like SMT or through hole pads on top or bottom layer?
Maybe ten of them?
The “converse” of a net tie, as meant in this thread, is called a jumper.
There’s a feature request to support jumpers: Support virtual jumper connections (off-board connections) between pads (#2558) · Issues · KiCad / KiCad Source Code / kicad · GitLab
It is not possible today.
Note that if this gets implemented, it’s much more likely it will be done through a description “in data” of the jumper connections (just like net tie pad groups works today), rather than as a drawing layer where you draw graphical jumpers.
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.