Bug report: Polygon arc segment issues, ring-shaped pads

Hello,

I’ve noticed some trouble when I use arc segments in polygons. For example, I want to create a pad and package definition for the Wurth Redcube 7466005R connector. This part sits on an annular ring on an unplated through-hole with four semi-annular paste segments. (Probably the through hole is recommended to be unplated because of its size, which many manufacturers cannot guarantee a good plate).

The first problem:

To define the paste segments, I created polygons with arc-faced edges. These appear to show up just fine in Horizon. However, I notice that when I export to Gerber output, KiCad’s gerber viewer reports a bunch of errors during the import, with messages like this:

RS274X: Aperture Macro “PS11”: ill. symbol, line: "* "

Both KiCad and Seeed Studio Fusion’s gerber viewers render those arc segments as straight lines. This is what I see:

The second problem:

I tried making the part with both a plated through-hole and an unplated-through-hole package variant. For the plated-through-hole package, I wanted to define a ring-shaped solder mask layer in the padstack. I wasn’t sure how to draw a ring (as opposed to a solid circle), so I tried drawing two polygons that had half-ring shapes. For the unplated-through-hole, I did the same thing to create the copper ring around the hole.

That worked as expected in Horizon.

But the Gerber viewer fails to show anything for the ring, in either case. Solid circles show up, but not the rings. If the Gerber viewer is treating the arc segments as straight lines, as before, then I could see how that would cause this problem, as the resulting polygon would have zero area instead of a half-ring.

The third problem:

When I try to route a trace to the plated through-hole connector, that works fine. But when I try to route a trace to the unplated through-hole connector, I get a “critical core exception thrown in tool_begin of Route track: invalid pad polygons: 2”. That’s not good.

I wondered if maybe the problem was that it wanted to connect the airwire to the center of the nonplated through hole, which of course, doesn’t have any copper to connect to. So I tried adding some extra little circles inside the copper ring I already drew, hoping that the airwire would try to connect to one of those. But that didn’t change anything. (Except those circles show up in gerber viewer, even though the rings don’t).

Is there a way for me to attach files here that aren’t images? I can send you a minimal test case that reproduces this issue.

I’ve changed the setting to allow uploading arbitrary files. Sample files to reproduce this issue would be highly appreciated.

Here you go! There’s a pool (containing only the connector) and a project with two of them, one using the plated and one the unplated hole. If you try connecting them with a trace, you’ll see the fatal error. The gerber output is also included, to check with KiCad’s viewer, just in case it generates fine on your end.

(I’m using 2.2.0 Halo commit 4571e56, Windows 10, x64)

horizon-bug-report.zip (71.3 KB)

(Update: I tried moving the padstack origin so that it’s located on the copper ring instead of the hole; that does result in a more sensible airwire endpoint, but it doesn’t fix the critical core exception, unfortunately).

gerber export: don't write newline after aperture macro primitive · horizon-eda/horizon@1a3a6b6 · GitHub fixes the error gerbview reported

gerber export: remove arcs from polygons in aperture macros · horizon-eda/horizon@0efe0ac · GitHub fixes the polygons with arcs in padstacks

That issue is due to the interface to the kicad router trying to turn the padstack into one contiguous polygon which doesn’t work since it’s got a hole in it. I already have an idea how to fix that one…

kicad router interface: handle pads with holes in them · horizon-eda/horizon@b6c0c8a · GitHub address this

You can get a build that includes all these fixes at JFrog

Let me know if this fixes all of your issues.

Hi Lukas,

You’re amazingly fast as always! Thank you!

Here are my observations:

  • I no longer get a critical core exception when I attempt to route a trace.

  • However, if the padstack is centered on the hole, the airwire still routes to the middle of the hole. So I can’t satisfy the router merely by routing a trace to the copper of the pad. I need the trace to connect to the hole itself, which will cause design rule violations.

    • As a workaround, I can offset the padstack such that the origin is located somewhere on the copper surface, so that my trace can terminate on the copper. I don’t mind doing that, although for a ring-shaped part like this, it’s not the most intuitive behaviour.
  • The four paste arc quadrants now render correctly in KiCAD’s Gerber Viewer program. Fantastic!

  • The mask and copper layers still do not render the hole correctly in KiCAD’s Gerber Viewer. :frowning:

    • However, they do render correctly in Seeed Fusion’s online Gerber viewer. So it might be KiCAD’s fault.

Here’s how things look in Horizon:

And here’s how they look in KiCAD’s Gerber Viewer:
gerber-copper
gerber-mask
gerber-paste

Here’s how they look in the preview when I upload the board to Seeed Studio Fusion:

I’m planning to order my boards through Seeed, so that gives me enough confidence that they’ll be able to manufacture them correctly. Of course, it’s still a bit worrying that KiCAD’s gerber viewer doesn’t agree, but that’s probably not Horizon’s fault. For what it’s worth, this is KiCAD gerber viewer 6.02 release build.

One more thing to mention – KiCAD’s Gerber Viewer no longer complains about aperture macros with the new version. So that’s good too!

After some testing I’m pretty sure that’s a bug in KiCad’s gerbview as the generated gerbers are renderd correctly by gerbv and Reference Gerber Viewer, by the developer of the Gerber Format. I’ve filed a bug with KiCad: gerbview: aperture macros with holes are rendered incorrectly (#11218) · Issues · KiCad / KiCad Source Code / kicad · GitLab

Depending on where the other end of the track connects to you could try to place the track where you need it rather than connecting it to the pad.

Oh wow, fantastic! And I’m impressed to see that they’ve fixed the bug already, too. That’s excellent.

Depending on where the other end of the track connects to you could try to place the track where you need it rather than connecting it to the pad.

If I do that, Horizon will bug me about failing pre-flight checks ("Airwire of net net_name").

That said, the airwire termination problem is really much less of a concern than the other ones, which are all fixed. Probably the easiest and cleanest thing to do for a part like this is to just offset the padstack so the origin is somewhere on the copper, and then offset it an equal and opposite distance in the package definition if I want the hole to be nicely placed at the origin. There probably aren’t that many pads that don’t have copper at the center anyway.

What might be nice is if the padstack editor warns me when I’ve defined a padstack of ‘top’ or ‘bottom’ type that has no copper at the origin (where the airwire will be terminated), or allows me to move the airwire terminus away from the origin if I want to. But I can see downsides to both of those too, since warnings can be annoying and making the airwire terminus movable adds complexity for little gain. So maybe the best thing to do about this is nothing.

Anyway, thanks for all the hard work and fixes!

That reminded me of Ability to specify router attachment points for complex padstacks · Issue #422 · horizon-eda/horizon · GitHub and I came up with GitHub - horizon-eda/horizon at track-conn-offset. This adds the “Move track connection” tool that allows you to offset where a track connects to a pad. It does some basic checks to make sure that the track still connects to the pad. I think that this approach is a good balance between implementation complexity and usefulness.

Anyhow, I’ll probably add a more through connectivity check that makes sure all copper of a particular net is properly connected.

add board connectivity check · horizon-eda/horizon@42eba6a · GitHub adds this