Support copper pours/planes

[Gigahawk]

For multi-layer boards, it is common to dedicate a whole layer to a common net such as ground, usually referred to as pours or planes.
This makes routing much simpler by running a short trace from a pad to a via.

As far as I can tell the autorouter is unaware of these pours, but are present in the GUI shown as "conduction areas".
There was some effort made to support this in #70, however by just marking nets to ignore this means that they will have to be manually routed.
Creating these vias before autorouting may lead to increased workload on the autorouter, since they may be unknowingly placed in a way that blocks other traces.
Creating these vias after autorouting may not be possible, since the autorouter may route through all of the available space for the via.

Some tuning parameters that should probably be exposed:

• Typically the length of the trace from the pad to the via is quite small, and some (most?) board houses allow the via to be directly within the pad (assuming it meets other requirements like annular width etc.). There should be a weight to control how hard the autorouter tries to shorten these traces.
• In general, it's preferred to have one via per pad, however this is not strictly necessary. There should be a weight to control how hard the autorouter tries to have a via per pad.

Note: there may be cases where traces are routed through the layer with the pour, which may create voids/discontinuities.
The autorouter should make sure that all the nets are still actually connected.

[redfast00]

I think I encountered this problem in a 2-layer board in Kicad with the plugin: I dedicated one plane to GND and one to 3.3V. The autorouter then created a solution where the ground plane is not connected to itself, leading to connection errors in the DRC. When I route the same board without the copper planes, everything is connected correctly.

[neltnerb]

I also pretty much always use an internal ground and power plane. I just tried running the router using the same tricks I use to get the EagleCAD autorouter to work right and it seems to recognize the net connection. Maybe it has been updated, but you might try this workaround and see if it works. It sounds close to what you're already doing, hopefully there is a small difference that might help.

I place vias for power and ground right next to the power and ground pads on every single part. I actually then just deleted all traces globally, so it doesn't even have the short trace from the via to the pad. It seems to correctly pick up that these make for continuous connections to the net when autorouting (evidence is that the ground vias aren't getting autorouted to one another).

I don't see it attempting to route any power or ground traces at all, everything it added is a signal or a short connection to the nearby via (I should have left those so they'd be prettier and centered). I did not enable routing on the two internal layers, it just seems to work as I wanted it to (no routing signals on internal layers because it removes the simplicity of the low impedance power and ground planes).

Hope this helps. I marked out a power and ground via I added to my PCB showing the autorouter not attempting to connect the manually placed ground and power vias to one another.

[neltnerb]

I should clarify that it is routing from the V+ signal on a pad to the V+ signal on the via, so it is routing the power from the via to the pad. I see that issue 70 is talking about optionally skipping nets to save CPU time, so I'm not certain what you meant.

Apologies if I'm missing the point, I post only as evidence that it is recognizing the inner layer net connection. Otherwise I would see it trying to connect V+ vias to one another and GND vias to one another, I think. It is also not ignoring them entirely, because it is routing V+ pads to the associated vias.

[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.

[redfast00]

Still seems relevant

[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.

[redfast00]

Still relevant

[redfast00]

@andrasfuchs What do you think about this? https://drewdevault.com/2021/10/26/stalebot.html

[andrasfuchs]

Drew clearly isn't a fan of stalebot, and I can see disadvantages of using it, but in the case of Freerouting I think the positives outweigh the negatives. I'm sorry if it makes you comment every now and then if there was no activity on an issue that you are interested in, I know it's inconvenient.

The problem I had with the issues earlier that many of them were very old and not relevant any more for the current version. Now we have a more up-to-date list of them, thanks to stalebot. The majority of the remaining issues are valid though, and I think it's not a bad thing that every 60 inactive days we get a reminder that it's still there. It can even activate the community to consider making a pull request with the fix.

We have thousands of monthly active users, so anyone could make a fix or hire someone to make the fix for them if the problem is critical for their work, and I think stalebot could be a good reminder of that.

I will change the message of the bot to remind everybody that it's a community project that needs you, the users to keep getting better, and I'm always here to help your efforts, and I will review and merge every pull request we get as soon as I can.

[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!

[redfast00]

Still relevant

[edplese]

A potential workaround for 4+ layer boards is to set the power planes to signal layers and then set all of the "Traces cost on layer" settings for the power plane layers in the advanced autorouter settings to very high numbers like 10,000+. The power planes must be set to signal layers or Freerouting ignores them and then the very high costs generally prevent it from routing traces on these layers.