My latest PCB uses several Bridged links, streight from the Library, specifically :- < Jumper:SolderJumper-2_P1.3mm_Bridged_RoundedPad1.0x1.5mm >
I tried also tried a few others from the default library and they all seem to give the same error.
I even did a fresh download of these footprints from GITLAB today incase something had changed in the Library. These links do contain the < net tie > magic words, so I thnk shey should work OK?.
I use the latest Kicad 7.0.7 upgraded today because the prior version was giving this error but the error is still present, I don’t recall this error in prior versions but perhaps i didn’t do a DRC then? I tried excluding these violations as it doesn’t seem to affect the PCB output so far as I can tell, but the errors come back one or two at a time over a number of checks.
Found 1 DRC violations
[clearance]: Clearance violation (netclass ‘Default’ clearance 0.2000 mm; actual 0.0000 mm)
Rule: netclass ‘Default’; Severity: error
@(0.2500 mm, 0.3000 mm): Polygon on B.Cu
@(75.1250 mm, 75.1000 mm): Zone [GND] on F.Cu and 2 more
The funny thing is I use a number of these bridged links but only those that connect to the top or bottom filled planes (both GND) give this error.
I even made a simple circuit with just one leg of the link connected to the a pcb Plain on the top surface and nothing else, it also gives this error.
Any clues? Does anyone else get this error under simular circumstances.?
I think my board is OK but it would be comforting to get the opinion of fellow users.
I can confirm the behavior with v7.99, it seems to be some kind of bug. A small one because it doesn’t prevent zone filling or routing, but a bug nonetheless. The DRC shouldn’t take this as a violation because the filling and routing algorithms don’t do that, either.
Isn’t it all to do with the polygon that links the 2 pads ? it’s not a SMD pad so it’s not got an associated net. I tested by replacing it with a SMD pad of the same size (and set to pad 1) and the violations went away.
At least in 7.99 the error is only about the already filled zone. If I modify the footprint, a track doesn’t trigger a violation for the same polygon, but the zone does.
KiCad’s internals have been aware on graphical items on copper layers for a while (Maybe since V6.0?) so if it’s not consistent in this, it smells like a bug.
Thanks for your input, everyone.
It is a comfort that I am not doing anything wrong and I am fairly sure that if I ignore the error my board will be fine. eelik Mentioned:- “KiCad official nettie footprints are implemented with non-pad copper polygons, so they should work.”
I am not familiar with these “Nettie” footprints but the ones I used are direct from the offical ones on GITLAB download, so i am guessing they are not the same?
Should I report this to someone / somehow?
I am not sure how I would go about doing that, hints anyone?
The footprint you used, bridge which is connected with copper by default, is technically a net tie, i.e. it ties more than one nets together electrically. The difference is in some (here) insignificant details.
Opps, sorry, I didn’t read that as “NET TIE” which I do know about, and do give this error.
I actually thought that was a reference to another way of doing it, like “nettie” was a specific user or group or something.
I confirm the same behavior than lab.ges in v7.0.8
Please could anyone clarify if this is a bug (to ignore the error) or not?
In previous v6 there was no DRC error using the same footprint (2 pads linked by a polygon)
I have treated it as a bug, after the comments made above and those boards are now in production. The gerbers look ok so hopefully it is just a checking error.
Weard thing about these errors though is even though I mark them ignore" the errors keep coming back, so it may be error free today, but tomorrow will give more errors, very odd.
