[PEDA] Octagonal Pads

[Geoff Harland]

<snip>
GH> > > Or have I "grabbed the wrong end of the stick" in this instance,
GH> > > and you actually want just two of the four corners to be
GH> > > rounded instead?
> >
DS> > yes this is what i had wanted
> >
DS> > these sorts of shapes can be very handy at times, chokes, buttons,
DS> > dual footprint compromises that customers always demand
> >
DS> > ideally i would like to be able to define a completely arbitrary pad
DS> > shape, e.g. a polygon with differing radiused corners
> >
DS> > failing that then the current rounded rectangle but with 4 (or 2)
DS> > settable corner radii
> >
DS> > failing both of those then also acceptable would be piling up a bunch
DS> > of junk (tracks, fills, regions, other pads) BUT without the current
DS> > nuisance of having to update free primitives all the time
>
GH> I thought that there had been improvements in updating the Net
GH> properties of (non-pad) primitives in relatively recent times. (Or was
GH> that an instance of an "overly optimistic" item within the release notes
GH>  provided for one of the SPs released for AD6?)
>
GH> And would defining an union of the primitives of interest be helpful at
GH> all in such circumstances? (Originally each union consisted of a set of
GH> components, but I gather that at some stage the concept was extended
GH> to enable users to "group" *any* set of objects.)
>
DS> > these primitives when part of a component and when touching a pad and
DS> > when on an electrical layer should simply become children of the pad,
DS> > sort of like a nested sub component and any child pads should lose
DS> > most of their electrical properties such as designator so that that
DS> > ambiguity would also be solved
DS> > solder mask and paste could be offered as a calculation of the
DS> > boundary of the finished composite object (sort of a 'SUPER-PAD') or
DS> > simply drawn or pasted from the conglomerate mess
>
GH> I am pretty sure that P-CAD provides the ability for users to define
GH> shapes of their own choosing for each layer of a pad (including Paste
GH> Mask andSolder Mask layers, and P-CAD's equivalent of Power Plane
GH> layers), and has done so for a number of major versions; there is also a
GH> "default" option available for the Solder Mask layers in which the
GH> details on those layers are derived from the details on the appropriate
GH> external copper layer in conjunction with a "Solder Mask Expansion"
GH> setting. (I'm not sure whether a similar feature is also provided for
GH> the Paste Mask layers, but perhaps there is.)
>
GH> I don't know whether that functionality will ever be provided within AD
GH> as well, but if P-CAD users are not going to lose any of the
GH> functionality which is currently provided to them, it would need to be
GH> implemented at some stage (though perhaps in a following major version
GH> of AD, rather than within AD6).
<snip>

Something else which I have since recalled is that there have been various
times when I have wanted to effectively implement pads with customised
shapes, and while it would be untrue to say that I have never used non-pad
objects to implement such shapes at such times, I have still always regarded
it as desirable to use *just* pad objects at such times.

The reason for that preference is that there is normally a lot less hassle
in implementing the appropriate details on the Solder Mask and Paste Mask
layers. (And if there is any reason for subsequently changing the value of
the Solder Mask Expansion and/or Paste Mask Expansion property for the "pad"
concerned, I usually don't have to edit any objects on any of those layers.)

To avoid synchronisation-related issues, it is highly desirable to also
provide additional corresponding pins within the associated schematic
file(s), and in such cases I customarily "overlay" each additional pin
required in exactly the same location as the "nominal" pin. Only the
original "nominal" pin has its Designator and/or Name properties displayed,
while *both* of those properties are concealed for any additional pins which
are subsequently added to the relevant part.

It has been claimed on at least one occasion in the past that a
netlist-related issue involving different pads/pins having the same
Name/Designator property has been rectified, but my experience has been that
regardless of whether any changes have been made to the source code, that
claim needs to be taken with a grain of salt. As such, I ensure that every
pin within each (schematic) component continues to have an unique Designator
property, and similarly, every pad within every (PCB) component continues to
have an unique Name property.

So as one example, if a pad with a customised shape is to be assigned a Name
property of 2, a "second" (supplementary) pad would be designated as 2A,
while a "third" pad, if required, would be designated as 2B, etc. And
similarly for the pins for the corresponding part within the corresponding
schematic file.

I would be the first to agree that there is some additional work involved in
doing all this, and that that approach wouldn't necessarily always be the
best approach in some circumstances. That said, I think that that approach
still has something going for it in at least some situations, though it
would of course be even better to have the P-CAD feature provided in which
customised shapes can be specified on each layer as required.

Regards,
Geoff Harland.