Exporting pad data for Phoenix X-ray machine

On 30/10/2013 4:50 a.m., Caleb Dead wrote:

Hi all, we have Phoenix Micromex 180 x-ray machine for PCB inspection at

my workplace. Its software can greatly automate creation of new

inspection programs for boards, but as an input, it requires data with

component and pad coordinates. Two separate files are needed: 1. one

which lists all components, their names, package type and coordinates.

2. one which lists pad shapes and coordinates (relative to package's

origin mark) for all package types used on a board. Here are shortened

examples of needed file contents:

 

Component file:

1. Board dimensions: X size, Y size, layer height

DIMENSIONS: 130 90 1.6

1. RefDes    PackageID    X-shift    Y-shift    ROT    PinCount

Side    MountType

C7               27    30    50    0    2    TOP       THROUGH

R7               26    121    51    0    2    TOP       THROUGH

V18             19    23    40    0    3    TOP       SMD

C58             14    99    7    90    2    TOP       SMD

V30             16    6    63    0    2    TOP       SMD

V15             19    23    20    0    3    TOP       SMD

C8               27    30    45    0    2    TOP       THROUGH

C43             13    104    77    0    2    TOP       SMD

 

Pad coordinates file:

PackageID    label    X-shift    Y-shift    Rotation    Width

Height    Shape

6    1    -0.65    0    0    0.9    0.7    RECTANGLE

6    2    0.65    0    0    0.9    0.7    RECTANGLE

15    A    -1.7    0    90    1.8    1.4    OBLONG

15    K    1.7    0    90    1.8    1.4    OBLONG

22    A1    -12.06    12.06    0    0.6    0    ROUND

22    A10    -0.63    12.06    0    0.6    0    ROUND

22    A11    0.63    12.06    0    0.6    0    ROUND

22    A12    1.9    12.06    0    0.6    0    ROUND

22    A13    3.17    12.06    0    0.6    0    ROUND

27    1    -1.25    0    0    1.3    0    ROUND

27    2    1.25    0    0    1.3    0    ROUND

 

Obviously, the most "clean" solution would be to write my own ULP to

generate the files. But that would be very time-consuming, so I want to

try some alternative solutions before I do that. I figured the component

file could be easily obtained by editing the standard Eagle partlist,

for example by a relatively simple MS Excel macro. But I found no way

how to obtain the pad data, or at least not in the format needed. I know

there is export-ict-netlist-pad-coordinates.ulp, but this one exports

the pad coordinates relative to the entire board, not relative to

package's origin mark. And the information about pad shape is missing

completely in it.

 

So my question is: *is there some existing ULP which can produce such

Hi Caleb

This is outwardly an easy ULP but challanges arise when producing files

with the classifications used in your examples.

Do you have the file specifications you can post here?

Can you post real data files?

Some of the questions that need answering, for clarification, are:

What is the difference between rectangle and oblong?

Is the measurement always millimeter or can that change?

Is the width of the ROUND pad its diameter?

If a device has both SMD pads and through hole mounting should it be a

MountType SMD or THROUGH?

Does Phoenix expect PackageID to be numeric?

Is the file Tab delimited or comma delimited or something else?

How does Phoenix handle odd shaped pads when the pin does not align with

a SMD pad that seeds the odd shape? It contacts the associated polygon

or wire. Does it even matter?

Are the dimensions a rectangle( with thickness) the board fits into no

matter what the board shape?

Are the 'Side' options TOP and BOTTOM?

In Eagle an SMD pad is a rectangle with  a portion of rounding. 100%

rounding makes a square pad round. So each pad needs evaluating to

determine which Phoenix classification it resides in. Eagle has

elongation for Pads.  Elongation is only valid for shapes

PAD_SHAPE_LONG and PAD_SHAPE_OFFSET and defines how many percent the

long side of such a pad is longer than its small side.

So the ULP needs to produce a file in Phoenix speak.

I was able to create the data for the component file today but the Pad

coordinates file needs the above questions answered to progress to that

Warren

On 30/10/2013 4:50 a.m., Caleb Dead wrote:

Hi all, we have Phoenix Micromex 180 x-ray machine for PCB inspection at

my workplace. Its software can greatly automate creation of new

inspection programs for boards, but as an input, it requires data with

component and pad coordinates. Two separate files are needed: 1. one

which lists all components, their names, package type and coordinates.

2. one which lists pad shapes and coordinates (relative to package's

origin mark) for all package types used on a board. Here are shortened

examples of needed file contents:

 

Component file:

1. Board dimensions: X size, Y size, layer height

DIMENSIONS: 130 90 1.6

1. RefDes    PackageID    X-shift    Y-shift    ROT    PinCount

Side    MountType

C7               27    30    50    0    2    TOP       THROUGH

R7               26    121    51    0    2    TOP       THROUGH

V18             19    23    40    0    3    TOP       SMD

C58             14    99    7    90    2    TOP       SMD

V30             16    6    63    0    2    TOP       SMD

V15             19    23    20    0    3    TOP       SMD

C8               27    30    45    0    2    TOP       THROUGH

C43             13    104    77    0    2    TOP       SMD

 

Pad coordinates file:

PackageID    label    X-shift    Y-shift    Rotation    Width

Height    Shape

6    1    -0.65    0    0    0.9    0.7    RECTANGLE

6    2    0.65    0    0    0.9    0.7    RECTANGLE

15    A    -1.7    0    90    1.8    1.4    OBLONG

15    K    1.7    0    90    1.8    1.4    OBLONG

22    A1    -12.06    12.06    0    0.6    0    ROUND

22    A10    -0.63    12.06    0    0.6    0    ROUND

22    A11    0.63    12.06    0    0.6    0    ROUND

22    A12    1.9    12.06    0    0.6    0    ROUND

22    A13    3.17    12.06    0    0.6    0    ROUND

27    1    -1.25    0    0    1.3    0    ROUND

27    2    1.25    0    0    1.3    0    ROUND

 

Obviously, the most "clean" solution would be to write my own ULP to

generate the files. But that would be very time-consuming, so I want to

try some alternative solutions before I do that. I figured the component

file could be easily obtained by editing the standard Eagle partlist,

for example by a relatively simple MS Excel macro. But I found no way

how to obtain the pad data, or at least not in the format needed. I know

there is export-ict-netlist-pad-coordinates.ulp, but this one exports

the pad coordinates relative to the entire board, not relative to

package's origin mark. And the information about pad shape is missing

completely in it.

 

So my question is: *is there some existing ULP which can produce such

Hi Caleb

This is outwardly an easy ULP but challanges arise when producing files

with the classifications used in your examples.

Do you have the file specifications you can post here?

Can you post real data files?

Some of the questions that need answering, for clarification, are:

What is the difference between rectangle and oblong?

Is the measurement always millimeter or can that change?

Is the width of the ROUND pad its diameter?

If a device has both SMD pads and through hole mounting should it be a

MountType SMD or THROUGH?

Does Phoenix expect PackageID to be numeric?

Is the file Tab delimited or comma delimited or something else?

How does Phoenix handle odd shaped pads when the pin does not align with

a SMD pad that seeds the odd shape? It contacts the associated polygon

or wire. Does it even matter?

Are the dimensions a rectangle( with thickness) the board fits into no

matter what the board shape?

Are the 'Side' options TOP and BOTTOM?

In Eagle an SMD pad is a rectangle with  a portion of rounding. 100%

rounding makes a square pad round. So each pad needs evaluating to

determine which Phoenix classification it resides in. Eagle has

elongation for Pads.  Elongation is only valid for shapes

PAD_SHAPE_LONG and PAD_SHAPE_OFFSET and defines how many percent the

long side of such a pad is longer than its small side.

So the ULP needs to produce a file in Phoenix speak.

I was able to create the data for the component file today but the Pad

coordinates file needs the above questions answered to progress to that

Warren