Bridges to Stencil Islands

[oclyke]

When using end styles labels with islands have bridges like those seen in stencilmaking.

The bridges seem to appear at inconsistent locations. Probably an artifact of the rendering process that is actually harmless. Though I don't have a solution in mind I think one approach would be to try to identify sections that are disconnected and render them individually (thanks cpt. obvious). Identifying isolated sections sounds tricky though

["oops" is not intended to be a dig - it just has lots of islands]

[nseidle]

I experienced this as well. I roughly remember tweaking the line thickness decreased the bridges enough that, while the Eagle view still had them, the CAM output was clean (no bridges).

It would be ideal to find a way to get rid of them, but currently it's annoyance rather than a blocker.

[NPoole]

I don't believe it's possible to actually get rid of them, in fact, a major challenge of this project was creating them. Because Eagle doesn't support nested polygons, islands have to be connected. You'll notice that the same thing happens with any SVG that's imported using gfwilliams' svgtoeagle script. The only reason they're more apparent here is that we're working on such a small scale. Even if you set the width to 0, Eagle will draw lines in the editor to show you that the polygon is closed, so there's no getting rid of them in the editor, but as Nate pointed out, small line widths should produce CAM files with no bridging.

My understanding is that small line widths also produce longer CAM times, so there's probably some balance to be found. If anyone can recommend the best line width, we can make it the default.

[NPoole]

To elaborate further on the island bridge issue, you cannot avoid it by making the bridge infinitely small (making both "siides" of the bridge start and end on identical points) because Eagle won't draw the polygon. There's actually a function in svgtoeagle that nudges these points so they won't sit on top of eachother.

[oclyke]

Ahhh! That is excellent to know. I too was concerned about the potential for CAMing times to increase but that might not actually be a big deal anymore. Since Nate's CAM ULP was updated to use the built-in Eagle CAMmer zero-width items (such as circles) seem to be OK. I wonder if this will apply to Buzzard labels (maybe one day I can verify experimentally). Anyway I'll close this because it seems like a feature, not a bug. 🐛

[nseidle]

I may have spoken too soon. I am still getting lines in CAM output... I'll close once I'm convinced we won't see island connections.

[nseidle]

run makelabel "(!RST!)"

run makelabel "(!RST!)" -t 0.01

run makelabel "(!RST!)" -t 0.001

So the trace thickness of 0.001 seems to mostly remove it. Unfortunately this trace thickness causes the CAMmer to take ~3 times as long (very unscientific).

[NPoole]

I just got test PCBs in and the bridges don't seem to resolve at 0.01 line width, so that's now the default!