Problems with custom pad shape...

Steve, thanks for the answer! No doubt the offset pad/SM are from the moved origin. But it's not the cause of the copper pad being changed when the symbol is placed. I'm fairly confident of this because the origins were originally in the center of the original full circles. Before I discovered the pad problem I moved the pad center - because the way the symbol is made both pins would have identical origins (and thus shorting out when routed).

Redwire: As I read it you do see the same error when placed with 16.5? This is a bit intersting as it means it's definitely my symbol that's messed up and not just a general 16.2 error with placement. I'll try to redo the symbol with different names etc. - although I'd rather recognize the problem than using brute force until I "get lucky". ;-)

If I manage to get through this one, I'll make a post with any findings immediately...

Thanks a lot for your efforts so far!

Andre,

Sorry to be jumping in late, but I'm having difficulty understanding your issue exactly.  I just grabbed your original (?) zip file and it appears to me you are seeing exactly what you should given the data files there.

Also, I assume that you ultimately want a package symbol with two separate semi-circle pads with separate isolated electrical connections?

The first problem I see is the origins of your two shape symbols currently do not match up.  The origins will be used as the alignment point by pad designer in overlaying the two shapes as well as becoming the origin and placement and connect point of the resulting padstack when imported into a package symbol as a "pin".   The origin of the two custom shapes should therefore be in the centers of the two shapes, not at the edge (center of the original circle) as is currently shown in your "halfcircle2mm-sm" shape symbol.

The second problem I see is your "Halfcircle2mm.pad" padstack file currently specifies the soldermask shape for use on both the "BEGIN_LAYER" and "SOLDERMASK_TOP" layers of the padstack.  This is why your copper pad is the same size as the soldermask when placed in your package symbol. 

If you fix the origins of your two shape symbols to center of the shapes such that they overlay correctly like you want them, then specify their respective usage correctly in you padstack definition, you should be able to use the same padstack to place two separate "pins" in your package symbol (with one rotated 180) and spaced approximately 1mm apart (center-to-center) to get the desired results.

In the heirachical flow of things, the custom shape symbols will flow into the padstack definition.  The padstack will then get used or placed into the package symbol with whatever is defined in the "SOLDERMASK_TOP" layer of the padstack being mapped into the "PACKAGE_GEOMETRY, SOLDERMASK_TOP" subclass of the package symbol.  Then when you use that symbol on a board and generate gerbers, the package_geometry soldermask items are collected from all your package symbols along with any custom "BOARD_GEOMETRY, SOLDERMASK_TOP" items to become your overall soldermask artwork.  At least normally, depending on how your artwork is defined.

Please excuse me if I have totally mis-understood the problem.

Roger Green

 Roger,

 No need for apologies - I very much appreciate any feedback I can get!

 I think you understand the goal fully. And you might have found a problem in the padstack definition. The solder mask should of course use halfcircle2mm-sm. I might have uploaded a wrong file of the many malfunctional attempts - butI'm a bit puzzled if it's that simple. I'm confident I've had multiple attempt where the soldermask and pads looked fine in the editor - but when the symbol is placed the pad suddenly changes to be the same as the pad (see the Package-in-editor(dra).png and Placed-symbol.png from the zip). But if there's a problem in the padstack I might be even to trial and error a working symbol (with a "real" SM, not the hacked on in my current) in a couple of hours...

Initially I had the origin in the center of the virtual circle - but I moved it 1mm in as the routing would cause errors if not routed straight away from the flat side. Now it just exist "funny" when not routed straight away... 

However the problem still remains: No matter how perfect the symbol (.dra) looks when edited it's totally messed up when placed on a board. Just take a look at the screenshot in my last post (test-package-in-editor.png): This is how the symbol 'must look' in the editor to "be right" on a board. It's probably something to do with the pad origins being differently interpreted in when the editor is in library mode and board mode. This makes it very annoying to debug.

I definitely want to avoid any components with non standard pads if this is the tool standard.... ;-)