Polar grid is a buggy mess

[tszaboo]

So I started experimenting with polar grid in Altium.
What an experience this is. So snapping traces to polar grids doesn't work at all, it just snaps to the global grid.
Now I'm trying to place some components. They rotate alongside the polar grid. That sounds like what you actually want to have, but it doesn't work. So if you want to place something at a 120 degree rotation at 120 degree from the center of the grid, tough luck. 1 out of 10 times, it works, the other times depending on which way you are dragging the component, it end up with fractional rotations. When you fix the rotation, it moves the component's pad from the grid. When you move back the component to the grid, it messes up the rotation again.
And there aren't any routing options that would go along the grid, so it would curve.
Oh, and sometimes, I place a part on the grid, and it ends up half a meter (literally) from where I placed it.
I honestly think they never tried using this after coding it, because it doesn't make sense at all. Or I'm doing something wrong, if so please help me.

[tszaboo]

Oh, this is great, look at this SMA lunching into a coplanar waveguide. The RF will just love that random transition that happened with this connector, those random angles. Chef's kiss.

[T3sl4co1l]

What random angles?  It looks like some polygon thin web removal has occurred, is that what you mean, how it's cut asymmetrically around the microstrip/pad to CPWG transition?

The dimension of this geometry being sub mm, you'll have a hard fucking time[1] measuring that at all, down at the 10ps scale, let alone mattering against the pad and SMA transitions being comparable or greater in overall magnitude.

If you need the transitions to look good (even just aesthetically -- hey, it's good enough reason for half my fiddling around ), I would suggest attaching either polygon cutouts, or explicit regions (including GND pads, or connected to the solder pads proper, so they get connected as such), to shape the transition as desired.  You can similarly shape the signal pad to more of a taper, which will also reduce the acute angles that are more likely to get trimmed as poly necking.

And yeah, I see the poly cutout in there already, but I mean to make it project out in a triangle or arc or whatever, hugging the trace, to ease the transition and stave off the neck-cutting.

[1] A derived unit of the Metric Fuckload, mind. Keep things professional and all.

Anyway, afraid I've not used the polar grid, or at least very much, so I don't have much to comment on that.  What was it.. I think I actually used it once, but just for some positioning that was a little easier to do that way plus setup instead of place, select and rotate?

Which is more or less the traditional way to do it, assign some reference points, and place components on square grid as normal, then rotate into place, around respective centers.  Hard to maintain in-situ, maybe want to label the angles of each region to indicate how much to rotate it back by to then make changes, or whatever, but, if you just need one-offs and need it done, I mean, it's fine.

Tim

[T3sl4co1l]

Oh, and sometimes, I place a part on the grid, and it ends up half a meter (literally) from where I placed it.

Also this, I think, might be a separate thing?  Like you know how-  -- well it's Altium, of course you know! -- you begin an operation, and the object just snaps off to BFE for an instant, you shake it around a little and it pops back under the mouse cursor again?  That happens to me, probably most often with rubber-stamping (CTRL+R), but any placing action I think does it, completely randomly.

That one, I think is a consequence of the old/glitchy (deprecated, maybe even?) GDI? interface/API they use; it doesn't quite track the mouse cursor, it doesn't quite track the screen space, or object or projected space under it, it depends on move events, it's weird.  It always clears up and tracks the mouse once you wait a moment and move around, and if you don't move, there's nothing to track, it just puts it where it initially thought it was (nevermind that it's somewhere offscreen).

I can imagine that being exacerbated by polar grid.  Or maybe when it tries to snap line segments and angles between points, then weirdness ensues.  (Related: every so often when I'm resizing a poly/region outline, rounding errors cause what should've been a colinear line collapsing into a single segment, to instead manifest a wild vertex way outside the working area.  This is just misinterpreting rounding error, via division by near-zero, into an unintended, but [probably] numerically valid, large-valued coordinate.  The deeper problem here, to me, is the inconsistent rounding depending on how you move vertices and lines/sides; and that it needs to round at all, since it is an integer based coordinate system, not floating point.  Except when it is, but mostly it isn't.  Which again, all sorts of hijinx particularly near the singularity of a polar grid, if that is relevant.)

Tim

[tszaboo]

And yeah, I see the poly cutout in there already, but I mean to make it project out in a triangle or arc or whatever, hugging the trace, to ease the transition and stave off the neck-cutting.

The same cutout on 3 different angles resulted 3 different GND shapes.

Which is more or less the traditional way to do it, assign some reference points, and place components on square grid as normal, then rotate into place, around respective centers.  Hard to maintain in-situ, maybe want to label the angles of each region to indicate how much to rotate it back by to then make changes, or whatever, but, if you just need one-offs and need it done, I mean, it's fine.

I've been doing that when it was necessary. Sometimes when I'm trying a "new" feature in Altium, that supposed to make your work easier, I feel like nobody ever used those features and they  don't work. Like try making a single layer PCB stackup, impossible.

The deeper problem here, to me, is the inconsistent rounding depending on how you move vertices and lines/sides; and that it needs to round at all, since it is an integer based coordinate system, not floating point.  Except when it is, but mostly it isn't.  Which again, all sorts of hijinx particularly near the singularity of a polar grid, if that is relevant.)

It internally uses 1um as the smallest unit.
I really don't know why it was throwing those components everywhere, it somehow didn't like that footprint from the vault. When I replaced it with a local one that I made a while ago, it started working properly.

[ajb]

If you have a modest number of features that need to be reliably and precisely aligned to a weird layout it may be easier to create that layout in another application and import it as a DWG/DXF onto a spare mechanical layer.  You can then snap components or other board features to the imported DXF objects.  DXF import scaling is also a bit buggy, but it should only take about three tries to find the settings that work.  That doesn't really help the routing, but maybe you can work around some of that by manually rotating track segments to the correct angle, snapping an end onto a pad, and then continue routing off the other end?

The deeper problem here, to me, is the inconsistent rounding depending on how you move vertices and lines/sides; and that it needs to round at all, since it is an integer based coordinate system, not floating point.  Except when it is, but mostly it isn't.  Which again, all sorts of hijinx particularly near the singularity of a polar grid, if that is relevant.)

It internally uses 1um as the smallest unit.

Does it?  I've seen geometry exported in metric (step files or DXFs) show errors of 1μin, but wouldn't be surprised if different parts of the application use different representations and have different rounding problems.  But the size of the rounding error doesn't necessarily control the size of the resulting placement error, for example if that 1μm/1μin is enough to flip a comparison with a snapping threshold.  IME that sort of thing shows up all the time in walkaround routing -- vertices in adjacent tracks show rounding errors in the clearance boundaries that will push a track to the next grid snap point.  This could be why the two footprints result in different behavior: some minor difference in geometry causing the snapping to be computed differently.

[T3sl4co1l]

Units are integer microinches I *think*, but I haven't exactly poked around the internal formats to know for sure.

The most common paranoia quirk I see is probably, when autorouted traces don't... exist? correctly? For example nudging one segment in a bus, and it doesn't move because it thinks the corners are pinned, and if you force it (manual route, Hug&Push mode) it makes the whole bus pop out around some corner that's like one of the segments extends beyond the corner it ends at.  Which I assume is at least in part a rounding thing, but, maybe it's alternative representations of objects.  (Also, not sure what version that applies to, if it's ever been fixed. I use a pretty old version by now...)

As for various collision, avoidance, cutting algorithms; I don't think there's any reason to assume they're geometrically invariant.  I would guess routing stuff is axis aligned, or prioritized at least (maybe glossed as a later step, for example), and stuff like poly neck cutting may be between vertices rather than any particular geometric alignment (you might hope it's aligned more or less equi-angled with the lines being cut, and it does often enough, but it doesn't need to, and often does ugly or inconsistent looking things, like pictured at the top here).

Tim