How to manage composite parts

Il 17/03/2013 03:10, Warren Brayshaw ha scritto:

The following may help you to work out an approach.

For this I think the attached image of a PCB fuse with separate PCB mounted

clips is a good reference example.

 

The schematic requires a fuse symbol with a value for the fuse

 

The BOM  requires

2 x clips

1 x fuse

Great!

The assembler needs placement instructions for all the sub parts of the

schematic's 'fuse' symbol.

1 x clip loc = X1Y1 rotation = 0

1 x clip loc = X2Y2 rotation = 180

1 x fuse loc....etc etc

 

The sub parts have to be separate to be included in the part placement

file.

Exactly.

Eagle has the GATE feature but that makes for many sub-parts on the

schematic and one part on the board so that won't do here. We need to get

at least the two clips onto the board separately and ideally the fuse as

well as an element with no pads.

 

So three separate parts means three separate items on the schematic so the

BOM ULP can detect them as separates. The schematic representation is thus

a composite of the needed sub-parts.

The pain is that you need to move them around as a group.

It is small pain in the schematic. I'm afraid how to hold in position

the parts in the layout.

The clips here need to be different devices because they have different

packages for our purpose. The left clip, say, has the pads for part but

also placement guides, on a custom layer,  for the other clip. This right

clip has the same rotation as the left clip, in the library, so that the

assembler is not driven mad. You add the 180 degrees rotation as you add it

to the board.

 

The right clip only has pads for itself but use its origin to land on the

marker of the left pad. Alternately the left pad has both pads and the

right clip is only documentation or tPlace layer outlines. Accurate

placement and rotation is still required for the assembler.

 

The fuse element on the board is no more than documentation or tPlace

layers but it is placed accurately so you can recover its coordinates for

the assembler as it may be placed by machine.

 

So all the needs can be met with only the schematic grouping not as nice as

we would desire.

If I understand correctly you're suggesting to:

1) create three parts: left clip, right clip fuse

2) draw the package of, say, left clip with some marker to place the

other parts

3) in the layout, position the right clip and the fuses on their marks

(this is what I was trying to avoid)

4) in the schematic, group and move around the three parts.

Not very handy but it's a good drawback.

Well, I ask you another bit of patience.

Please let's consider another example.

An MCU module with two connectors and four holes.

The best would be:

- in the schematic a single part with all the pins

- in the BOM the two connectors and the 4x mechanical stuff (screws,

nuts, etc...)

I would do the following:

- two parts: one for each connector. But only one with the usual

rectangular box around the pins. The other is composed of the pins only

at the right distance to be placed over the box already placed.

- the package should be created as described above, with the reference

marker to place the other connector. A simple but powerful feature I

wish is to define a group and store it. So I can move the group without

have to redefine it every time (every CAD has this option).

- I don't know how to represent the mechanical parts! Ok, I can just put

a note on an hidden layer and then manually compile the BOM.

It's a pity a great software like EAGLE can't manage this common problem

natively.

All electrical CADs can.

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

Marco Trapanese wrote on Sun, 17 March 2013 03:26

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.

Thank you

Marco

The following may help you to work out an approach.

For this I think the attached image of a PCB fuse with separate PCB mounted

clips is a good reference example.

The schematic requires a fuse symbol with a value for the fuse

The BOM  requires

2 x clips

1 x fuse

The assembler needs placement instructions for all the sub parts of the

schematic's 'fuse' symbol.

1 x clip loc = X1Y1 rotation = 0

1 x clip loc = X2Y2 rotation = 180

1 x fuse loc....etc etc

The sub parts have to be separate to be included in the part placement

file.

Eagle has the GATE feature but that makes for many sub-parts on the

schematic and one part on the board so that won't do here. We need to get

at least the two clips onto the board separately and ideally the fuse as

well as an element with no pads.

So three separate parts means three separate items on the schematic so the

BOM ULP can detect them as separates. The schematic representation is thus

a composite of the needed sub-parts.

The pain is that you need to move them around as a group.

The clips here need to be different devices because they have different

packages for our purpose. The left clip, say, has the pads for part but

also placement guides, on a custom layer,  for the other clip. This right

clip has the same rotation as the left clip, in the library, so that the

assembler is not driven mad. You add the 180 degrees rotation as you add it

to the board.

The right clip only has pads for itself but use its origin to land on the

marker of the left pad. Alternately the left pad has both pads and the

right clip is only documentation or tPlace layer outlines. Accurate

placement and rotation is still required for the assembler.

The fuse element on the board is no more than documentation or tPlace

layers but it is placed accurately so you can recover its coordinates for

the assembler as it may be placed by machine.

So all the needs can be met with only the schematic grouping not as nice as

we would desire.

HTH

Warren

--

Web access to CadSoft support forums at www.eaglecentral.ca.  Where the CadSoft EAGLE community meets.

Attachments:

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

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

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