Hi,
Could anybody explain what technical reason is for such DRC rule? I have drawn lots of parralel tracks on my board, space between tracks is always within DRC limit, but on some random places I got warning about this rule.
depending on your grid size its likely that there is a tiny segment at the end of that trace that is too close, on the left hand bar is a red / green cross called “display traces in outline mode” will likely reveal to you what is going wrong.
It appears the trace avoidance rounds down, while the DRC checks the actual value.
1 Like
Sometimes if it is very close to the limit, the interactive router and the DRC check differ in opinion if it is acceptable. (Might be some sort of rounding error.)
Hi,
I have discovered the root of my problem. Spacing between pins of chip were little random at some digits far after decimal points, so if tracks were anchored at pin, routed in parralel and then bend, only on some tracks showed this error.
But my question is still open, DRC rules ussually comes from some limitations of manufacturing process, in case of this rule, should it be understand as “to small clearance” or something else?
I assume it should be interpreted as too little clearance. Look at the detailed drc message. I assume it talks about two different nets.
HI ! I got this error indication on on occasion. However it was logically correct it turned out to be a bit “missguiding” as to the “expressed cause”. It turned out that the pad to which the wire was wired were of another NET ! (something had gone wrong in some stage, dont ask how or why), so changing the pad to the right (same) net resolved the issue. But then I have also “cracked” the relation between the schematic part and the pcb. so I now only edit the pcb part in pcbnew, never import a new .net file. (too much work to try to correct the relation, and too much work invested in the pcb layout)
If the schematic net differs from the pcb net are you sure it is connected to the correct things on the pcb?
Kicad determines what net belongs to what trace by walking along the trace starting from a pad. (It gets the net of that pad) So if a trace has a different net to the pad it seems to be connected to, it got that net from another pad that has a different net. Normally this would mean these two pads should not be connected. (Or they are not connected according to the schematic.)
Well yes and no. As things went down; I had finished the design, all wiring done, and routed on the pcb (a one layer design, so there was a bit of work put into routinig). Then I wanted to add a componenent, and did that on the schematics layer, however I had also put some footprints directly onto the pcb in pcbnew, and when I applied the new netfile in the pcbnew things got away, so I had to rerert to a somewhat older version of the pcb. When I did check that with DRC I got one single “track too close”. checking it out I saw that it was a wire that was going where it supposed to, but the origin net-name was no longer the net of the target pad. Which of cause is in a way “too close” since they were connected. And NO i have yet not solderd the componentes and tested the pcb, so Im not 100 sure that it was right amendment. BUT essentillay my remark here in the discussions was to point out that this “mysteriously appearring” error text of DRC can be due to differing net on target versus origin of a wire, is is possibly not the immediate think one does getting the error 
Your stuff would be easier to read if you would put in some empty lines.
When importing the netlist you can choose to keep footprints that are not in the schematic.
You can also lock footprints that you wish not to be removed. (I use this for my mounting holes, symbols and for all “stitching via single pad footprints”)
That way you can keep the schematic and pcb in sync and have the support of tools like DRC to ensure that everything is correct.
[quote=“georg, post:8, topic:7790”]…however I had also put some footprints directly onto the pcb in pcbnew, and when I applied the new netfile in the pcbnew things got away…
[/quote]
I hate to say it, but print out the traces on the file that you think worked, and start over with that print in hand as a reference to save you time in the re-work.
The only loosely termed “footprints” that I would put directly on PcbNew are holes.
It does not take that long to start out new with a fresh canvas free of quirks.
Yes thanks, I get that now. It’s kind of learning cost I guess. Btw, thanks Rene, will try keep some air in the text.
And OK, I will do some experimenting, but I think my current design is kind of hard to save the the pcb layout, but for what Sprig says; start over from net, and use a “printout” for handmaking the same pcb routing over once again.
I think my main misstake was to first insert some “for future development” foot prints (unconnected on network); first on the pcb, and then to make it “more correct” tried to include on the network level, things really got out of hand; where annotation re-annotated (at least what I think) some components. So I got a reall spagetti of “wires to make” on the pcb when importing the netlist. I think alls is fine now (however realy test from mounting is still to be).
And the design is lost for the moment on the schematic level. (some day …)
I don’t think you could possibly make as big a mess as I made while learning KiCad. If you did make a bigger mess, you deserve a medal!
I know that right now you are frustrated by the thought of starting over. But, if you know your files are corrupted, you are best to start over.
And, trust me, it won’t take nearly anywhere near the time to re-create problem free files as it did to screw them up the first time!
THanks !
In addition to my messing up on Kicad, In some way my Outlook (yes I dont like that one) has decided to hide my incoming emails (suddenly grouped on “converstaion”) so I have missed a trivial question from pcb-producer in Kina. Now at last finding out why nothing happens (darn xx@@ !!) Kina has an 8 day national holiday where nothing seem to happen …
It does seem a bit bleak just now.
Needed some encouragement
Hi, Rene (and anyone else who might be interested in contributing) I am getting this same error.
When I first ran DRC I had well over 100 DRC errors. Now down to two. But I am getting this error at the intersection of two (what appear to be properly connected) trace segments. I have the same net name on either end of the trace, and if I edit-drag (either free angle or 45 degree modes) the trace the segments move together so remain connected. The only part of this which seems incorrect is the DRC error indication.
Any idea what might be going on?
Thanks
Application: kicad
Version: (5.0.2)-1, release build
Libraries:
wxWidgets 3.0.4
libcurl/7.61.1 OpenSSL/1.1.1 (WinSSL) zlib/1.2.11 brotli/1.0.6 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) nghttp2/1.34.0
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.68.0
OpenCASCADE Community Edition: 6.9.1
Curl: 7.61.1
Compiler: GCC 8.2.0 with C++ ABI 1013
Build settings:
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=ON
KICAD_USE_OCC=OFF
KICAD_SPICE=ON
It wouldn’t hurt to have the project here downloadable, if at all possible. It’s 1’000’000 times easier to find out what’s going on by trying the project than by reading descriptions.
E-load2 April 17 2019a.zip (150.7 KB)
Thank you, eelik
I don’t think I have uploaded my whole project folder previously, but here it is, all zipped. Not huge… By the way, if you are wondering why so many traces are not at 0 or 45 degrees, it is because I like to preload with a few IPAs before working on my pcb design. not
This looks really weird. I can’t find any rational reason for the message. Maybe it’s a bug. The interactive push’n’shove router lets me redraw the tracks so that there should be no error but the DRC error message reappears.
Hi, eelik
Thank you. This means that I am not crazy or perhaps we both are. 
Same with me.
(lelek (not eelik)) probably won’t mind we hiyacked his 2 year old thread.
Edit:
I was utterly confused at first and therefore did some more testing, and found that the 2 errors are clear violations of your design rules.
The +Load net has a clearance of around 1.26mm, with a track of the “U11_Pin1” net below it, while according to the design rules it should should have a clearance of 1.524mm If you change the design rules to a clearance of, for example 1mm, the DRC errors go away.
When you draw the track of the +Load net, the interactive router seems to partially ignore the DRC settings, but that is another subject.
Below this line is mostly nonsence.
I deleted the offending track segment, and the segments on the left and right, and then re-connected the left and right tracks again.
After that I re-ran DRC and the error re-appeared.
I can not see anything that would warrant this DRC error. It is a very simple continuous track and this should not generates DRC errors.
Both “Two track ends too close” DRC errors can only be between track segments of the same net.
I even dragged the 45 degree part a bit to the sides to make sure nothing else can cause the DRC error.
It seems to be a bug in KiCad and it may be worth filing a bug report about this.
Even weirder:
If I delete the tracks from the “U11_pin1” net, (hover above it and press [Del], then both DRC errors dissapear, while If I only delete the closest segment of the “U11_pin1” net and run DRC, then the Top error dissapears, while the bottom error remains, while that net is below of +Load net.
Another note:
You should not ignore the “Drilled holes too close together” DRC errors. These are (both) very serious error and usually result in blunt refusal when you try to have your boards manufactured, and rightly so. The reason behind it is that if holes overlap then the drill breaks when drilling the 2nd hole because it bends to the side, and the Carbide drills used for PCB manufacture are very fragile and break easily (almost certainly) with side loads.
I do not know whether you’re crasy or not, but I see no correlation between this DRC error and you being crasy or not.
Paulvdh…You’ve done it again. Thanks a lot.
I had some difficulty to fine-drag the +Load trace. This gets back to the other (maybe it should be a bug?) that even with a fine grid the trace jumps too far when dragging; difficult to fine-tweak the position. But as I have encountered previously, it seems like switching back and forth between 45 degree and free angle drag modes, eventually I can approach what I want. Now those DRCs are gone.
I don’t think we are hijacking the topic (??). I see what claims to be the same DRC violation…doesn’t it make more sense than putting what sounds like the same topic into a new thread? If it does not, please let me know. I do not know why we close some threads after 6 months, unless software version changes render them irrelevant.
And potato leek soup can be excellent.