Your calculation shows that the tracks are too close (closer than the 0.115 allowed clearance, as per the EBI net class), and not that the tracks cross, as KiCAD’s DRC reports!
With that said, I see that my program does round things: I read positions and sizes into double variables (in C++). So, the position of the via in the original file is 93.374023 (i.e., leaving 10 nm more than the required clearance). Since the via is the one that I replace with a track generated in my program, the 93.374023 that was read into my program now gets output as 93.374; however, everything else (including the D6 track) is just read into a string and later output directly from that string, so of course the 92.974013 is output verbatim to the modified file.
Sill, like I mentioned: regardless of the motivation or the “political (in)correctness” in what I’m attempting to do, the fact that KiCAD’s DRC says that tracks cross is a bug. Granted, less “puzzling” than I originally thought.
Some follow-up aspects:
I go to the original file and place a 0.42mm track of 0.001mm length, running parallel to the D6 track,and make its X coordinates 93.374 (instead of 93.374023), and I get error Two parallel track segments too close.
If I make it diagonal (starting at the via’s position and going diagonally to X=93.374, I get error Two track ends too close (which, strictly speaking, is incorrect: what’s happening is that the end of one track is too close to another track).
And finally: if I make it length 0 (and X = 93.374), then I get error Tracks crossing (like in the minimal sample I posted. Which, again, is incorrect: the tracks do not cross; the tracks are too close).
So, I guess the bug goes beyond what I originally posted, but it simply relates to the phrasing used to report an error when two tracks are too close, which additionally depends on the relative arrangement/geometry of the two tracks.
Should I report this bug? (it may or may not be fixed in 5.99, but still, 5.1 or any possible 5.2 may still be around for a while)
Unless you can produce the situation without external help, i.e. without manipulating the file with something else than KiCad itself, I see little chance to get it fixed for v5.1.x unless maybe if it would require only changing description strings. (There won’t be 5.2.) The DRC system in 5.99 has been changed radically. If you want to help KiCad development I suggest you try with 5.99 and report bugs for it.
Fair enough. To be honest, I have been extremely tempted to get 5.99, both from my own selfish purposes (you know, get better functionality, or in any case better features), and from the perspective that you point out: any help in terms of bug reports would be best used in the development going forward.
But then, I’ve been extremely busy with work (which in the past several weeks has involved mostly doing boards layouts and designs), so I cannot risk using the nightly builds for that.
OH, BTW, at first read I sort of missed this detail. No, of course the bug can manifest in KiCAD by itself: the bug description is extremely simple: if two tracks are too close, then for some arrangements/geometries, the DRC error message is incorrect/misleading. Although during the creation/routing of the track (under normal conditions) KiCAD will not allow a “tracks too close” violation, it can happen later as a result of a large number of possible actions (editing tracks, manually moving with M or Ctrl-M, changing a net class, etc.)
The worst-case is perhaps when one track has 0-length, which can be produced by KiCAD, through the properties dialog for the track. Although possibly unlikely, a user may have a similar use-case/motivation as mine, and just try that without going and writing an external program to manipulate the file.
This brings me to perhaps the fundamental / bottom-line aspect: do we have an idea of how close 5.99 is from release, or in any case from “production quality” that one could reasonably consider to use for real-life work?
It’s been already close to three years since v5, and that was more or less the time from v4 to v5. From what I’ve read, v6 is involving more fundamental changes, so it seems like it will take longer from v5 to v6 than it took v4 to v5? I guess my question is: are we close-enough yet? :‒)
I would report it against 5.1.9, the steps to reproduce it are easy.
If setting length = zero in the dialog causes this, it should be fixed or not allowed.
I’m confident we will see 5.1.10
There’s no one-size-fits-all answer to that question. Personally I would say that if you are willing to take some risk compared to using only the stable version but still be relatively safe, wait until all the new features have been integrated and then stabilized for maybe a month. The features which are still waiting are arcs in polygons and the new python API.
When these features will be there is not known yet. @Qbort has been working on a merge request for arcs in polygons, maybe he has something to say. Earlier today someone asked about the new API in the developers mailing list (https://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg39436.html) and I’m sure everyone who has ever done something with the python API of KiCad are impatiently waiting for the answer.
There is also another case where the report is incorrect, although admittedly, not nearly as bad as the “Tracks crossed” due to length=0. See screenshot below:
The actual error is that the end of one track (the thin one, net +3.3V) is too close to another track (the wide, GND track).
I would definitely prefer that length=0 remain allowed :‒) It may seem useless, but it is neat that it is allowed and produces a disk of diameter = the width of the track.
Sorry @eelik for some reason I only received the ping now. Yes I’m working on that MR (which Seth already started), to bring curved polygons in. I am probably a couple of weeks away, depends how far I get this weekend.
Again: DRC is correct. (As far as I can see. I assume same clearancefor the track as for the GND pad)
To show what KiCad makes of clearances I suggest you turn on: Pcbnew / Preferences / Preferences / Pcbnew / Display Options / Clearance Outlines / Choose your Poison.
Again, @paulvdh ‒ looks like one of us is not understanding what the other is saying:
In the original case, the tracks do not cross. They are too close, and apparently when one of the tracks’ length is zero, the error is shown as “Tracks cross” (seems like a case of the else clause in an if -- elseif ··· block, where the developer did not see the one-of-the-tracks-being zero-length case coming).
In the above case, the error message is incorrect in a less severe way: the error message states that the track ends are too close. I argue that that statement is incorrect (the fact that there is an error is correct; what I claim is that the description of what the error is, that is what is incorrect). One of the track ends is too close to the middle of the other track. For that matter, I cannot even picture a situation where it would make sense to say “track ends too close” without inviting a philosophical discussion (if the “track end” is the point, then it’s not the end that is too close, since the violation occurs at the edge of the disc around the track end). Perhaps, the error message should (always) simply be: “Tracks too close”, and “Tracks overlap” when they do overlap (instead of “cross”, which implies that one of the tracks passes from one side to the other side of the other track).
Again, unless I’m not understanding what you’re saying?
It is awesome that v6 flgas (as a warning) a track with unconnected end!!! (which makes me wonder: is that a new feature in v6, or is it one of the (sadly so many) features that I have not discovered in v5?)
As feedback, I would say the error message (the third one) is confusing; the first part, “Error: clearance violation”, is perfect (I love it!! Much better than what I had imagined, just “tracks too close”) … however, the detailed info that follows, I find it confusing; two aspects:
Which one is “(current) clearance” and which one is “actual” ?? “actual” as in what you actually have in the layout? or “actual” as in the actual clearance specification?
Seems odd, talking about the clearance in the layout; intuitively, in the layout you have a distance; if that distance is smaller than the clearance, then there is a violation; maybe it is a linguistic issue / limitation on my side? It may well be that clearance means the space between two things; but in the context of a CAD software, in particular KiCAD, one gets used to understanding “clearance” as one of the specified requirements; in that sense, it sounds odd.
I think what I’m trying to articulate is: if the dialog box refers to the distance you have in the layout as “the clearance”, then the specified clearance should be referred to as “required” and not “actual”.
IMO saying just “clearance” is unclear. It could say for example “rule”. Even better would be if it would give details about the rule which causes the violation. In 5.99 there’s Inspect -> Clearance Resolution which gives some detail(s) about clearance rules between two items. The same idea could be utilized here somehow, and the Resolution dialog could be opened from the DRC window.
@eelik: while trying to figure out how to explain to radix what my actual (no pun intended) linguistic limitation would be (the way I suspected), I noticed a far worse issue with the dialog from 5.99:
It looks like you opened the same file I posted; however, there’s nothing in the file that has a clearance specification of 1.0 mm, and no two things in the layout are exactly 1.0mm away from each other. Where is that “1.0000 mm” in the dialog coming from?
Back to @radix point: the dialog above says “actual 0.115”. So, given the way you posted the dictionary definitions, I take it you’re suggesting that that can only mean “the clearance that does occur in reality, in the actual/concrete layout”. However, 0.115 is the specified clearance. From the DRC-bug.kicad_pcb file:
That’s right, because there wasn’t effective clearance value in the project, it was 0 in the Board Settings -> Constraints. Sorry for the confusion, I should have told but was too lazy, and now I have to write much more than I would have written if I would have told in the first place.
Curious. Some issue with 5.99 reading a kicad_pcb file created by 5.19? I ask, because in the file, there is a clearance specified for EBI (the lines I posted above are actually copy-n-pasted from the .kicad_pcb file posted above.
Agreed, @radix, that at this point it doesn’t really matter! :‒)
