How to manage composite parts

On 03/16/2013 10:31 AM, Marco Trapanese wrote:

Hello,

 

sometime I have a part composed of multiple components.

Some examples:

 

- battery holder: two clips

- MCU module: two or more connectors

 

 

In the schematic is correct to have one symbol for the whole part. It

makes no sense to place two different clips (which must be placed at

an exact distance with the correct silkscreen info) o two different

connectors for the MCU module.

 

The downside is it's hard to manage and maintain the BOM because I

will get only one item rather than 2 or more. And the manufacturer

code isn't really applied to the whole part but to the single sub-items.

 

I wonder how you would handle this.

It's called a sub-assembly.  But there's no direct way of handling this

through Eagle.  In a full BOM, each assembly consists of one or more

components, and one or more other assemblies, each of which would be

referred to as a sub-assembly, forming a hierarchy.  The battery holder

with two clips would be modeled as a single part in eagle, and in your

BOM software it would be referenced as a sub-assembly.  The sub-assembly

for this would be the two connectors.

Going the other direction, your finished PCB is not the final product,

but merely one sub-assembly.  The next higher level assembly may include

the machined case in which the board is mounted, standoffs, hold down

screws, buttons, switches, displays, labels, etc., forming your finished

product assembly.  Going up one level higher, one can include the

finished product (as a sub-assembly), packing materials (bubble wrap,

peanuts), a unit container, and perhaps even a shipping container in a

top-level assembly that one might call "as-shipped".

A hierarchy such as this makes it easy to do a cost roll-up.

As you can see, Eagle plays a small role in the overall BOM, but it does

a pretty decent job detailing the PCB.  A model to consider is to create

the battery holder with its two connectors as a single device in your

library.  Then use attributes to specify the manufacturer's part numbers

for the holder.

    MFGRPN1=12222

    MFGRPN2=2345

    ...

You can modify the standard bom.ulp to also emit attributes of each

part, even filtering out attributes that do not begin with "MFGRPN".

HTH,

    - Chuck

Il 16/03/2013 16:34, Chuck Huber ha scritto:

Thank you for your clear answer.

A hierarchy such as this makes it easy to do a cost roll-up.

 

As you can see, Eagle plays a small role in the overall BOM, but it does

a pretty decent job detailing the PCB.  A model to consider is to create

the battery holder with its two connectors as a single device in your

library.  Then use attributes to specify the manufacturer's part numbers

for the holder.

     MFGRPN1=12222

     MFGRPN2=2345

     ...

 

You can modify the standard bom.ulp to also emit attributes of each

part, even filtering out attributes that do not begin with "MFGRPN".

This could be fine but I'm afraid it would need a "three-dimensional" table.

My own libraries have an attribute for each supplier's order code. I

mean the part name (base name + technology + package) is actually the

manufacturer code.

Then I have several attributes, to store the order codes, i.e.:

FARNELL=XXX

MOUSER=YYY

DIGIKEY=ZZZ

in this way when I open my BOM in Excel it's easier to place orders.

According to your hint I should add an attribute for each sub-part, but

each sub-part itself should have the order codes for each supplier - no

way

I think a smart ulp could do the trick:

1. add an attribute for each sub-part with the exact EAGLE refs

(sub-assembly prefix, gate, library, part, tech, package)

2. export the BOM with attributes

3. run a post-processing ULP that finds the sub-assembly prefix and

explode the attributes adding rows to the BOM itself with the

information read from the other libraries.

Not very handy, indeed, but in this way there is no multiple data (e.g.

the sub-parts information are stored only in the initial library) and

the higher level of the sub-assembly is always up to date.

Another big issue is the coherence of the designators.

In the schematic it's correct to view the battery holder as, say, B1. In

the BOM you will have the two sub-parts but the designator is still B1

and the guys who will make the board will complain about this.

Marco

Il 16/03/2013 16:34, Chuck Huber ha scritto:

Thank you for your clear answer.

A hierarchy such as this makes it easy to do a cost roll-up.

 

As you can see, Eagle plays a small role in the overall BOM, but it does

a pretty decent job detailing the PCB.  A model to consider is to create

the battery holder with its two connectors as a single device in your

library.  Then use attributes to specify the manufacturer's part numbers

for the holder.

     MFGRPN1=12222

     MFGRPN2=2345

     ...

 

You can modify the standard bom.ulp to also emit attributes of each

part, even filtering out attributes that do not begin with "MFGRPN".

This could be fine but I'm afraid it would need a "three-dimensional" table.

My own libraries have an attribute for each supplier's order code. I

mean the part name (base name + technology + package) is actually the

manufacturer code.

Then I have several attributes, to store the order codes, i.e.:

FARNELL=XXX

MOUSER=YYY

DIGIKEY=ZZZ

in this way when I open my BOM in Excel it's easier to place orders.

According to your hint I should add an attribute for each sub-part, but

each sub-part itself should have the order codes for each supplier - no

way

I think a smart ulp could do the trick:

1. add an attribute for each sub-part with the exact EAGLE refs

(sub-assembly prefix, gate, library, part, tech, package)

2. export the BOM with attributes

3. run a post-processing ULP that finds the sub-assembly prefix and

explode the attributes adding rows to the BOM itself with the

information read from the other libraries.

Not very handy, indeed, but in this way there is no multiple data (e.g.

the sub-parts information are stored only in the initial library) and

the higher level of the sub-assembly is always up to date.

Another big issue is the coherence of the designators.

In the schematic it's correct to view the battery holder as, say, B1. In

the BOM you will have the two sub-parts but the designator is still B1

and the guys who will make the board will complain about this.

Marco

Il 16/03/2013 22:44, Chuck Huber ha scritto:

True.  In the instances where I have sub-assemblies mounted on the

board, I provide the assembly house with not only the PCB BOM, but also

the BOM of the sub-assembly.  K1-DB on the main board, for example,

would refer to a daughter board whose primary function is that of a

relay (hence the 'K').  It has been assigned an internal part number.

 

Then I provide a complete BOM for the daughter board, which contains K1,

and a diode.

This is exactly what I do usually. Manually.

It would be nice to manage this in EAGLE directly, because if after two

years you have to change something you will likely forget something...

In the example you provided, the battery holder B1 would be assigned

your own internal part number (BXXX-DB), then the BOM would include the

two connectors cited earlier.

Thinking out loud for a moment, this would provide one side of the

connector - that which is installed on the battery holder, but it still

does not address the two mating connectors that you need on your main board.

Yes, this is the point. I instruct the the assembly house how to handle

B1 but of course it's not very straightforward.

Suffice to say that the Eagle BOM is not the utopia of BOM's.  In fact,

I have written a C program that imports the CSV produced by Eagle and

load it into a MySQL database.  This same program also reads a

supplementary file to add parts to or remove parts from the assembly.

Components that are removed from what Eagle exports are test points

(usually just SMD pads or holes), and spark gaps.  Other things to

remove would be a bit more esoteric components such as controlled

impedance resistors built on to the board.  After that, I use PHP

scripts on an internal web server to access the assembly database from a

browser.

I wrote a simple Excel macro do to this - it's the same thing.

I'm not sure if ULP is the best way to go here.  Consider a language

outside of Eagle - something that will readily import what Eagle

produces then massage it from there.

I was thinking about ULP because (I guessed) it would be easier to

access the other libraries to extract the information of the other parts.

But I was wrong... the lbr files are just plain xml files!

When I will have some spare time I'll try to develop a simple C++

application to improve the BOM.

Anyway, if the CADSOFT's guys would like to help us adding some features

we all will be very happy!

Best regards

Marco

On 03/16/2013 12:07 PM, Marco Trapanese wrote:

...

 

I think a smart ulp could do the trick:

 

1. add an attribute for each sub-part with the exact EAGLE refs

(sub-assembly prefix, gate, library, part, tech, package)

 

2. export the BOM with attributes

 

3. run a post-processing ULP that finds the sub-assembly prefix and

explode the attributes adding rows to the BOM itself with the

information read from the other libraries.

True.  In the instances where I have sub-assemblies mounted on the

board, I provide the assembly house with not only the PCB BOM, but also

the BOM of the sub-assembly.  K1-DB on the main board, for example,

would refer to a daughter board whose primary function is that of a

relay (hence the 'K').  It has been assigned an internal part number.

Then I provide a complete BOM for the daughter board, which contains K1,

and a diode.

In the example you provided, the battery holder B1 would be assigned

your own internal part number (BXXX-DB), then the BOM would include the

two connectors cited earlier.

Thinking out loud for a moment, this would provide one side of the

connector - that which is installed on the battery holder, but it still

does not address the two mating connectors that you need on your main board.

Suffice to say that the Eagle BOM is not the utopia of BOM's.  In fact,

I have written a C program that imports the CSV produced by Eagle and

load it into a MySQL database.  This same program also reads a

supplementary file to add parts to or remove parts from the assembly.

Components that are removed from what Eagle exports are test points

(usually just SMD pads or holes), and spark gaps.  Other things to

remove would be a bit more esoteric components such as controlled

impedance resistors built on to the board.  After that, I use PHP

scripts on an internal web server to access the assembly database from a

browser.

I'm not sure if ULP is the best way to go here.  Consider a language

outside of Eagle - something that will readily import what Eagle

produces then massage it from there.

Enjoy,

    - Chuck