Clearance violations for certain boards

[andrasfuchs]

There are still cases where Freerouting produces clearance violations. They should not happen.

If you have a KiCad project file that typically gets clearance violations after auto-routing, please upload it here.

[lynchaj]

Hi
Thank you! Here is an example board to illustrate the issue

03 processor.Z80, V1.0.zip

The Z80 processor board is one of a dozen boards with likely similar issues. You can find them here:

https://github.com/lynchaj/duodyne

These are presently in development and are updated on the GitHub repository every few days.

Thank you for looking into this issue. I greatly appreciate your time and effort.

Andrew Lynch

[benwillcox]

I've just found this issue after upgrading from 1.4.x (can't remember the exact version I'm sorry) having been using this version on various KiCAD projects with no issues. After installing 1.6.5 I found multiple clearance issues after autorouting a project that worked fine in the old version.
I have rolled back to 1.4.4 and it routes the same project with no clearance problems :-)

EDIT: I just read the background information on this issue from the previous issue. My issue might be a bit different as it's more than just a minor violation of the clearances - I must admit I haven't checked to the level of precision detailed in the original issue log, so can't say whether I am also seeing those errors.

But, after autorouting with 1.6.5 there are several instances of tracks clearly passing right over other pads and causing multiple short circuits, and routing tracks over no-fill (cut out) areas in the board, making the output unusable.
It seems to get worse the longer the batch optimiser runs, and if I check immediately after autorouting completes, I don't see these issues.
As I mentioned earlier, if I install 1.4.5 instead, then I don't have those issues.
I can upload my .dsn file if that would be useful?

Thank you

EDIT AGAIN: Apologies, I thought 1.6.5 was the latest version (it's on the homepage at https://freerouting.mihosoft.eu/) but I see that there is a 1.7.0 - the problem has been fixed it would seem. Feel free to delete this comment!

[andrasfuchs]

Thank you @benwillcox for the detailed report, it is great input! I'm glad your case works with 1.7.0!

I'll keep this issue open nonetheless until I tested it with multiple boards.

[andrasfuchs]

I started to investigate the issue, and I can confirm that auto-routing causes violations with the Z80 board.

I run it a few times, and so far it looks like that Freerouting has problems with the two hole clearances, H3 and H4, it violates the 0.25mm clearance for both.

It's strange, because I can see the copper to hole clearance definition of 0.25mm here:

But when KiCad exports the board, there is no mention of this rule, at least I can't seem to find it.

Is it normal to not export this rule to the DSN or is it a bug in KiCad?

Update: Yes, so as soon as I changed the net class clearances to 0.25mm, no violations occur. This means that Freerouting respects the clearances, but since KiCad doesn't save the copper to hole clearance in the DSN file, it's impossible for Freerouting to resprect that rule.

KiCad developers already know about the issue: https://gitlab.com/kicad/code/kicad/-/issues/14439

[lynchaj]

Hi
Yes, those are known issues and not the clearance violations I am concerned about. Both H3 and H4 are padless holes for routing wires between front and back of PCB if needed during debugging. I have since replaced both padless holes with holes with pads and since it then appears on the copper layer, FreeRouting is able to handle them properly. The silkscreen clipping is by design because the IDC connectors descend lower than the edge of the PCB. I handle those as exclusions to the DRC run.

The clearance violations I am concerned about are if you load the .SES file into KiCAD and then save it again as a .DSN file. Load the resulting .DSN file in FreeRouting and you'll see about 1500 clearance violations. At least that's what I see when I try it.

Thanks, Andrew Lynch

[lynchaj]

Hi,

I have since fixed the padless hole problem by replacing H3 and H4 with holes with pads so that problem is solved. 

The issue is when I load a .DSN file that's been exported from KiCAD based on a previously imported .SES file, I get hundreds of clearance violations.  This happens with all the versions of FreeRouting I use ranging from 1.2.43 Extra to 1.7.0 to the latest snapshot.

Steps to reproduce the problem:

1. start with PCB in KiCAD with parts but no traces.  If PCB has traces, you can select all traces & vias and delete them
2. export .DSN from KiCAD
3. load .DSN in FreeRouting, perform trace routing and optimization
4. save .SES file from FreeRouting
5. import .SES file into KiCAD (adds traces to PCB)
6. export .DSN from KiCAD (parts plus traces)
7. load .DSN in FreeRouting, press "violations" button to see clearance violations. Should be hundreds of them.  Also "incompletes" button will show several incompletes (10-12 usually).  If I use the latest snapshot, I get about 400 violations.  If I use 1.2.43 Extra I get about 1600 on current iteration of Z80 processor

You should be able to replicate my findings with the Z80 processor zip file I uploaded previously

Thanks, Andrew Lynch

[andrasfuchs]

Hi @lynchaj ,

Thank you for the detailed steps, I could reproduce the problem now, and started the investigation. Something isn't right, I'm just not sure yet where and if KiCad or Freerouting causes the problem.

Meanwhile I extended the clearance violation details in Freerouting a little, so we can see how serious the violation is:

It looks like a rounding problem to me, but I also noticed something curious. If I set a specific clearance value in KiCad, it saves just a slightly higher value into the DSN. I don't think it's intentional, but who knows.

Settings in KiCad:

Values saved in DSN:

I reported this issue here: https://gitlab.com/kicad/code/kicad/-/issues/14713

I'll continue the testing and report my findings here.

[lynchaj]

Thank you! I think this looks like some sort of rounding issue or maybe a type conversion issue.

Can you replicate this phenomenon using 64-bit KiCAD and/or FreeRouting? I wonder if it is 32-bit related.

Thanks, Andrew Lynch

[andrasfuchs]

I use 64-bit versions of both KiCad and Freerouting.

I suspect that both a KiCad DSN export problem and our collision detection algorithm are to blame.
It's still a little murky for me, so I'll need to dig deeper for this.

The good news is that it looks like that the violations are tiny, so although the violation list is annoying, they should not cause any issues through fabrication.

[lynchaj]

Hi Personally, I think this issue has been around for a long time. I've been using KiCAD and FreeRouting since 2006 and this has been a recurring problem as long as I can remember. The main problem this causes is it prevents an iterative design cycle to improving the board in small increments. Essentially, the transfer from KiCAD to FreeRouting and back to KiCAD is a one-time event.  Attempting to iterate will introduce clearance violations and subsequent cycles makes it worse. KiCAD DSN -> FreeRouting -> KiCAD SES -> the end What I would like to be able to do is repeat in a cycle as needed to make adjustments without starting over from scratch.  Being able to preserve the >90% trace routing solution but still able to make minor PCB updates and even manually adjust traces in KiCAD and re-enter the FreeRouting optimization. Hopefully, that is possible or something close.  Your help is greatly appreciated! Thanks, Andrew Lynch

[andrasfuchs]

I agree that it would be desirable, round-trips between KiCad and Freerouting should be a non-issue. Your use-case is a totally valid one.

As it turns out, we had a good suspicion earlier, there is a backed-in safety margin setting in KiCads DSN exporter, that might be the reason why it's not working properly. See the discussion here: https://gitlab.com/kicad/code/kicad/-/issues/14713 .

If they agree to remove that feature in their next release and I implement our own safeguards in Freerouting's next release then I don't see why it would be not possible to round-trips. I can't promise anything, because anything can come up during the process that I don't know about, but it's worth a try.

I'll keep you posted here.

[lynchaj]

Hi Andras,
Thank you so much! I think this would be a great fix to KiCAD and FreeRouting. Even if it takes a while, at least it is acknowledged as something that needs fixing. I think this issue has been around for quite a while (2009?).

Thank you! Much appreciated! Andrew Lynch

PS, maybe make the safety margin user selectable in the top menu under Parameters -> Route?

[andrasfuchs]

Alright, so I spent a good amount of time on testing and figuring out what the root of the issue can be.

My first suspicions were the SES and DSN file writers and DSN file readers, I thought that they do something funny with rounding the margins or coordinates. Although I cleaned up the DSN and SES writer routines I don't think they were the issue. There were some rounding hacks built-in, but they had no impact on the clearance violations.

The differences between the clearance calculation methods of KiCad and Freerouting are most likely to blame. The practical implications of this are so tiny that I decided to add an internal safety margin to the router, so it will not max out the allowed clearances that are defined in the net classes. This extra margin is 0.0016 mm, so I don't think that it will ever cause any problems for fabrication.

Anyway, after doing some more tests with KiCad 6 and Z80 prototype, clearances are still good even after a dozen roundtrips between KiCad and Freerouting.

Could you test the snapshot build and give some feedback?

[lynchaj]

Hi,
Will do and report back later, hopefully today

Thanks! Much appreciated, Andrew Lynch

[lynchaj]

Hi
I am afraid the problem is still there. I went through the cycle of saving the .SES file from FreeRouting and then importing into KiCAD and then exporting the .DSN file. In KiCAD, the board passes DRC without any problems other than the known 12 clipping issues from the IDC connectors. When I loaded the .DSN file into the latest snapshot FreeRouting, I had 2062 clearance violations (basically the whole board was covered in clearance violations) and 8 incompletes.

I zoomed in on the clearance violations and noticed some occur in the middle of traces. I am wondering if there is some issue in KiCAD where trace segments join if there is some overlap which appears as clearance violation FreeRouting? I also zoomed in on the 8 incompletes and they don't make much sense either. The traces are present and seem to go from the starting to finish points but FreeRouting says they are not connected. ???

Sorry, I wish I had better news. Thanks, Andrew Lynch

[lynchaj]

processor-Z80-test.zip

This is my test .DSN file

[andrasfuchs]

Alright, no worries, I'll keep looking. Thank you for the details!

I'll try to spare some time for this later this week.

[lynchaj]

Hi
One additional thing I've noticed with this board is that if it runs in the FreeRouting trace optimizer for an extended period of time like 1 week or more when I try to save the board I get "Java.Lang.StackOverflowError" message. Prior to the one week point, it saves fine.

Once a day or so, I interrupt the trace route optimization to export an .SES file, save as a .DSN file, and "save" the board. The "save" option writes a binary file .BIN however I can only do the save function for the first few days. After about a week I get the Java Stack overflow error.

This is the same .DSN file as I've posted earlier in the week.

Thanks, Andrew Lynch

[andrasfuchs]

Thank you Andrew!

It's a useful feedback, but I don't think I will be able to test this with such a long running times.

Since this seems to be independent from this issue (clearance violations), please create a new, separate issue if it still happens with the newest version.

[lynchaj]

Hi
Was there ever a root cause identified for the clearance violations seen in export of .DSN, FreeRouting, export of .SES, and import of .SES into KiCAD, and re-export of .DSN file to FreeRouting?

Thanks, Andrew Lynch

[github-actions]

This issue is stale because it has been inactive for 60 days. Remove stale label or comment or this will be closed in 7 days.

[lynchaj]

Hi
Please keep researching this issue. FreeRouting should be able to import boards exported from KiCAD with DRC compliant tracing without generating hundreds of clearance violations. Something is dreadfully wrong in FreeRouting that it is not able to import legitimate, error-free boards KiCAD exports as DSN files. Thank you, Andrew Lynch

PS, this is not a "once in a while" problem. Practically every board I make in KiCAD cannot be reimported into FreeRouting once the traces exist without hundreds of clearance violations. This makes no sense to me.

[lynchaj]

Hi
Maybe FreeRouting needs a "clearance violation repair mode" to attempt to salvage or at least minimize the number of clearance errors on reimport. Is that possible?

[lynchaj]

Hi,
Any updates on FreeRouting DSN re-import? I am hoping some day that KiCAD and FreeRouting can become completely circular to support an iterative design approach. As it is now, it is purely linear KiCAD -> FreeRouting because I cannot reimport / reexport more than one time. Much appreciated! Thanks, Andrew Lynch

[github-actions]

Hey there!👋 This issue is stale because it has been inactive for 60 days. If this matter is still relevant, feel free to remove the stale label or add a comment. Otherwise, it will be closed in 7 days. But remember, with thousands of monthly active users, someone might just have the solution you need. This is a community-driven project, and your active participation is crucial. If the issue is critical for your work, consider contributing a fix yourself or hiring someone to help. I'm here to support your efforts and will review and merge pull requests as quickly as I can. Let's collaborate to keep improving our project! 🚀 Your involvement is invaluable, and together, we can ensure the continuous growth and success of our community. Thank you for being an integral part of this journey. Your engagement is what drives our project forward!

[lynchaj]

Hi, still an issue. Hopefully someone can find and fix this issue. Thanks!

[github-actions]

Hey there!👋 This issue is stale because it has been inactive for 60 days. If this matter is still relevant, feel free to remove the stale label or add a comment. Otherwise, it will be closed in 7 days. But remember, with thousands of monthly active users, someone might just have the solution you need. This is a community-driven project, and your active participation is crucial. If the issue is critical for your work, consider contributing a fix yourself or hiring someone to help. I'm here to support your efforts and will review and merge pull requests as quickly as I can. Let's collaborate to keep improving our project! 🚀 Your involvement is invaluable, and together, we can ensure the continuous growth and success of our community. Thank you for being an integral part of this journey. Your engagement is what drives our project forward!