1
\$\begingroup\$

I have design rules for my polygon poors for different net labels.

Overview of priorities, scopes and attributes of pooring rules

In the picture I attached a screenshot where you can see how I set up my rules.

For the net class "HV" and for the netclass "Paux" I told it to create direct connects. For all other connections that are not included in one of those netclasses, Altium is supposed to create relief connections. Now for some weird reason it is creating relief connections for ALL polygon connections. I also swapped the priorities and it still happened.

Altium creates relief connection for a pad with no assigned net class (all good)

Altium creates relief connection for a pad with a netclass and a design rule for that net class, telling it to create direct connections

I also found this post, talking about further issues with Altium and pouring. The proposed solution (restarting Altium) did not work for me. I also repoured the polygons, several times. I tried to restart and recreate the polygons and everything.

\$\endgroup\$
2
  • \$\begingroup\$ Did you try referring this issue to the Altium support page? There might be some known issues with enabling connections to a polygon pour using this method. See: altium.com/support \$\endgroup\$
    – Nedd
    Commented Jul 1, 2023 at 6:49
  • \$\begingroup\$ I can't access the Altium support. I am using altium via my companies licence and they did not give me a user account or whatever to log into the Altium support. Is there an easy way to summarize the content of this link by any chance? \$\endgroup\$
    – Skilluca
    Commented Jul 2, 2023 at 17:59

2 Answers 2

2
\$\begingroup\$

I figured it out after finally getting access to the Altium support:

When I set up the design rules, I set up the net-class-match for "where the first object matches" AND "where the second object matches." I removed the "where the second object matches" and now it works.

The weird thing is that the second object also always has to be part of the same net, thus part of the same net class. I wonder why it would not work like that.

\$\endgroup\$
0
\$\begingroup\$

Hm, I have never, ever needed to enter a "second object" on that rule.

I can't actually imagine what use that would be, or why. The first object is obviously(?) the pad being poured around, and that's pretty much sufficient.

A test is in order.

It seems the second object is the polygon itself:

Design rule and polygon screenshot

This is in AD16, which should behave identical to current version, in terms of extant design rules and query matching.

I sorted through most every type of object I can think of, which excluded a few thousand, leaving just 46 in this example. Only the polygons (or the hidden regions they're composed of) matched.

Here I've broken it down to exclude a single polygon, which you can see has the expected effect. Excluding the components or pads has no effect here.

Design rule and polygon screenshot with reversed rule

Just to prove polygon doesn't apply in the first case, I excluded everything but the polygon in question; now nothing pours direct-connect (including the targeted polygon itself).

This is confusing, because the "Test Queries" button indicates that, pretty much anything in the query, is applicable. It seems like it may be a bug, as only non-polygon net objects should count for the first, and only polygons for the second. (Perhaps this has been improved since.)

Thanks, I shall add this information to my toolbox! (I doubt I'll use it, ever -- I've not needed this question asked before, and likely won't again -- but it's now there, just in case, and you never know.)

I suspect the most useful application would be, you have a great many polygons, doing many things, and perhaps polygon classes are involved, or other selection rules (named polygons, polygons by region or layer, etc.). Hm, one fairly probable use-case would be, say you want thermal relief on mid layers, but not on the surface: the OnMid polys can be excluded from such a rule as the second object.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.