Standard for library creation version

Am 22.10.2011 00:38, schrieb Jorge Garcia:

1.Do not modify EAGLE's default libraries.

Yes.

2.User libraries should not be stored in EAGLE's internal lib folder.

For beginners, that seems to be OK. For people who only use their OWN

libraries (and NOT the CadSoft ones), that could be cumbersome, but

anyway...

1.Symbol pins must always align to a 0.1”(2.54mm) grid.

2.Symbols must always have >NAME and >VALUE place holders on layers 95

Names and 96 Values respectively.

Yes and Yes.

3.Place >NAME on top, and >VALUE on bottom side of the symbol.

That is NOT always my recommendation: For SMALL symbols (resistors,

capacitors, and whatnots), that works very well. BUT a part's name and

value should be NEAR each other, so that one can easily find BOTH of

them. Therefore, for large ICs, your suggestion would mean ripping them

apart quite considerably. For such parts, I put both of them on top.

Since this is something of QUITE personal preference, I wouldn't give

any recommendation, but just state that both of them SHOULD BE AVAILABLE

(some people leave them out).

4.Center the symbol around the origin.

Yes. Approximately. So that all pins are STILL on a 0.1" grid.

1.Power pins should generally have their pin direction parameter set to

Pwr.

2.Input pins should generally have their pin direction parameter set to IN.

3.Output pins should generally have their pin direction parameter set to

OUT.

4.Passive pins should generally have their pin direction parameter set

to PAS.

5.Also IO, HIZ, NC.

6.Do not use pin direction SUP for a normal Symbols. SUP is only for

supply-pins!

7.Any symbol notes or tips should be on layer 97 info.

8.It is better to give general names(OP AMP, DIODE, etc.) to symbols

instead of specific part numbers (LM741, 1N4007, etc.). This makes it

easy to reuse the symbol if your library is going to contain many

variations of the same type of component for example a library full of

op amps can probably make use of one op amp symbol.

Yes for 1 to 8.

9.For the >NAME and >VALUE text use a text size of 70 mils.

This perhaps is too user-dependent. I wouldn't give a recommendation

here, but anything from 50 to 80 mils seems to be OK (I myself prefer

60mil).

1.Design a package assuming that it will be placed on top of the board

(Use t layers). The MIRROR command can then be used on the board layout

to put a component on the bottom of the board.

Use tPlace for the component silkscreen which is printed on the PCB and

should not contact solder.

Yes and yes.

Use tDocu to draw leads of components leading to pads.

Use tNames for the >NAME place holder for the reference designator that

will be on the silkscreen.

Use tValues for the >VALUE place holder, which will not be part of the

silkscreen.

Use layer 48 Document or layer 49 Reference for any artistic features or

notes that will not appear on the silkscreen.

Well, erm, in principle, why not...

2.Center the package around the origin.

Yes. Approximately. But, if possible, still leave all pads on a DECENT

grid. Grid position takes precedence over centering.

1.For the >NAME and >VALUE text use a text size of 70 mils.

I do NOT recommend that AT ALL: With typical board densities, this text

size is TOO LARGE for the silkscreen and consumes TOO much space. In

order to create relatively small text that can still be read, but also

has more than 0.2mm wire thickness (which is a common minimal width for

manufacturing) to pass typical DRCs, I recommend a text size of 50mil

AND a text ratio of 16%.

2.Draw outline of package in tPlace with wire width 8 mil or 4mil.

8mil is OK, 4mil is NOT: Board manufacturers often have minimal width

restraints of 0.2mm (8mil is JUST larger than that) or 0.15mm (4mil is

even below THAT). 4mil is a very nice width for paper printouts, but NOT

for the silkscreen.

3.The ADD command in the board editor searches through the description

field, so a well setup description field can yield more fruitful

searches. Therefore a good description field for a package should include:

Standard package name(preferably in bold)

Any possible aliases for the package. For example a DIL08 package might

also be known as a DIP08.

Yes.

If the package is based off of a standard document such as one of the

IPC standards, then it should be referenced in the description field if

possible as an HTML link. If a link is not possible then a reference to

the name of the document should be sufficient. Listing this information

will help in checking the package for correctness.

If applicable length x width dimension.

For web-based documents, that's OK. It gets harder for LOCAL references:

What I would like to do is putting small PHOTOS of the mechanical

component in a device description (of course not for ICs or such, but

for mechanically special parts such as switches, connectors etc.). The

pictures should be saved in a certain subfolder of the library path.

Referencing such is not so easy. In my 'eagle.betatest' post form

2010-09-29, I suggested the following:

--- snip ---

  2. (This just came into my mind today) Support your nice

     '$EAGLEDIR' or '$HOME' syntax inside HTML references. This way,

     the definition of references could be platform-independent,

     clear, images could be referenced relative to the appropriate

     folder, and even the schematics could use this path without

     problems.

     DISADVANTAGES: Since your QT library surely does not support

     such a feature, a preprocessing of the string would be

     necessary.

--- snap ---

Walter Spermann answered to that:

   'That's a good idea, thanks. We keep this as a suggestion for a

   future version (not 5.11 though).'

Perhaps it can be included in version 6...

1.Always set a prefix, otherwise EAGLE will use U$ by default.

2.When creating multi-gated components, EAGLE will by default reference

them as G$1, G$2, etc. These names will not show up on the schematic,

therefore use the NAME command to rename the gates A, B, C, etc. A nice

way to do this is to type 'A' followed by enter when you have the gate

on your mouse cursor before placing it, EAGLE will then continue the

pattern for the other gates.

3.Use P for power symbols.

4.When naming devices use specific part numbers.

5.Always double check add levels and swap levels, otherwise your

components might not enter your schematic as you'd expect them to.

Recommendations for Devices

1.Just like packages, having a good description field can improve the

chances of the ADD command finding the component you want. A good

description field for a device should include:

Device name(preferably in bold).

Any other aliases the device might be recognized by.

A link or reference to the device's data sheet.

Manufacturer(s).

Short explanation of the device's function.

If applicable length x width dimension.

Yes to all of the above.

Andreas Weidner

Andreas Weidner schrieb:

Am 22.10.2011 00:38, schrieb Jorge Garcia:

>> 1.Do not modify EAGLE's default libraries.

 

Yes.

Indeed.

>> 2.User libraries should not be stored in EAGLE's internal lib folder.

 

For beginners, that seems to be OK. For people who only use their OWN

libraries (and NOT the CadSoft ones), that could be cumbersome, but

anyway...

Additionally: EAGLEs internal libraries should NOT be installed in a

subdirectory of the programs installation path. This also applies to all

other "data" directories (projects, ULPs, SCRs, CAM jobs etc.).

>> 1.Symbol pins must always align to a 0.1”(2.54mm) grid.

>> 2.Symbols must always have >NAME and >VALUE place holders on layers 95

>> Names and 96 Values respectively.

 

Yes and Yes.

...and yes.

>> 3.Place >NAME on top, and >VALUE on bottom side of the symbol.

 

That is NOT always my recommendation: For SMALL symbols (resistors,

capacitors, and whatnots), that works very well. BUT a part's name and

value should be NEAR each other, so that one can easily find BOTH of

them. Therefore, for large ICs, your suggestion would mean ripping them

apart quite considerably. For such parts, I put both of them on top.

Since this is something of QUITE personal preference, I wouldn't give

any recommendation, but just state that both of them SHOULD BE AVAILABLE

(some people leave them out).

I fully agree to this. For symbols larger than that of a resistor or

diode, I always place >NAME and >VALUE close to each other. (Normally on

top of the symbol, but that's my personal taste, of course.)

>> 4.Center the symbol around the origin.

 

Yes. Approximately. So that all pins are STILL on a 0.1" grid.

Exactly.

>> 1.Power pins should generally have their pin direction parameter set to

>> Pwr.

>> 2.Input pins should generally have their pin direction parameter set to IN.

>> 3.Output pins should generally have their pin direction parameter set to

>> OUT.

>> 4.Passive pins should generally have their pin direction parameter set

>> to PAS.

>> 5.Also IO, HIZ, NC.

>> 6.Do not use pin direction SUP for a normal Symbols. SUP is only for

>> supply-pins!

>> 7.Any symbol notes or tips should be on layer 97 info.

>> 8.It is better to give general names(OP AMP, DIODE, etc.) to symbols

>> instead of specific part numbers (LM741, 1N4007, etc.). This makes it

>> easy to reuse the symbol if your library is going to contain many

>> variations of the same type of component for example a library full of

>> op amps can probably make use of one op amp symbol.

 

Yes for 1 to 8.

Pin directions are somewhat difficult since they may lead to many

"false" DRC complaints. For example, different (ly named) power pins at

ICs which would ask for equally named nets.

But, "generally", this is OK. Of course, there are exceptions...

I suggest an additional rule here regarding pins:

Never name pins with respect to pad numbers/names later in the device

resp. package. Pin names always should represent the function of the

pin, nothing else.

>> 9.For the >NAME and >VALUE text use a text size of 70 mils.

 

This perhaps is too user-dependent. I wouldn't give a recommendation

here, but anything from 50 to 80 mils seems to be OK (I myself prefer

60mil).

Agreed - but as a general starting point, 70 mil appears OK to me.

>> 1.Design a package assuming that it will be placed on top of the board

>> (Use t layers). The MIRROR command can then be used on the board layout

>> to put a component on the bottom of the board.

>> Use tPlace for the component silkscreen which is printed on the PCB and

>> should not contact solder.

 

Yes and yes.

and yes.

And one more additional suggestion, regarding pads:

Never name pads regarding to a (real, intended or theoretical) function

within a device. Pad names ALWAYS should represent the "official" names

(normally numbers) of the pure package, nothing else.

>> Use tDocu to draw leads of components leading to pads.

>> Use tNames for the >NAME place holder for the reference designator that

>> will be on the silkscreen.

>> Use tValues for the >VALUE place holder, which will not be part of the

>> silkscreen.

>> Use layer 48 Document or layer 49 Reference for any artistic features or

>> notes that will not appear on the silkscreen.

 

Well, erm, in principle, why not...

Personally I find it useful to distinguish between SMD and THT

components - unfortunately, there aren't enough layers to fully do that,

so I use tDocu for SMD outlines, names and values. If I want to print

the part name in silkscreen, I can change its layer to tNames after a SMASH.

As generel hints, that suggestion appears OK - at this issue, personal

taste will greatly vary anyway...

>> 2.Center the package around the origin.

 

Yes. Approximately. But, if possible, still leave all pads on a DECENT

grid. Grid position takes precedence over centering.

No, in most cases centering takes precedence over pad grids. It's pretty

common that packages have off-grid pads anyway, and it's no problem for

EAGLE to deal with them (meanwhile). The mechanical position of a part

often is relevant, and that should be easily derived from its origin

(i.e. the center of a connector or an LED) for further mechanical design

work.

ONLY if the center of the package is not relevant at all, AND all pads

become on-grid by that, grid position may take precedence over centering.

>> 1.For the >NAME and >VALUE text use a text size of 70 mils.

 

I do NOT recommend that AT ALL: With typical board densities, this text

size is TOO LARGE for the silkscreen and consumes TOO much space. In

order to create relatively small text that can still be read, but also

has more than 0.2mm wire thickness (which is a common minimal width for

manufacturing) to pass typical DRCs, I recommend a text size of 50mil

AND a text ratio of 16%.

Agreed. The appropriate size of the silkscreen text varies with board

density. At low density boards, I commonly use 1.6 mm text size - and

with increasing density, I reduce that to 1.3 or even 1.0 mm. Thanks to

GROUP SMASH and GROUP CHANGE SIZE that's no big deal.

Additionally, the texts of SMD components should be smaller anyway, or

they wouldn't fit in even the paper printout (they're not in the

silkscreen, anyway, but you need a proper documentation as PDF or on

paper including the SMD parts). I commonly use 1 mm, sometimes I need to

reduce to 0.8 mm.

>> 2.Draw outline of package in tPlace with wire width 8 mil or 4mil.

 

8mil is OK, 4mil is NOT: Board manufacturers often have minimal width

restraints of 0.2mm (8mil is JUST larger than that) or 0.15mm (4mil is

even below THAT). 4mil is a very nice width for paper printouts, but NOT

for the silkscreen.

Exactly. 0.2 mm (or 8 mil) are good measures.

>> 3.The ADD command in the board editor searches through the description

>> field, so a well setup description field can yield more fruitful

>> searches. Therefore a good description field for a package should include:

>> Standard package name(preferably in bold)

>> Any possible aliases for the package. For example a DIL08 package might

>> also be known as a DIP08.

 

Yes.

Yes.

>> If the package is based off of a standard document such as one of the

>> IPC standards, then it should be referenced in the description field if

>> possible as an HTML link. If a link is not possible then a reference to

>> the name of the document should be sufficient. Listing this information

>> will help in checking the package for correctness.

>> If applicable length x width dimension.

 

For web-based documents, that's OK. It gets harder for LOCAL references:

Even for web based documents, that won't work satisfying. Document URLs

change, some disappear completely. So it's always necessary to include a

reference in human readable text form, i.e. "IPC-xxxx, Section X.Y, case

ABCD"). As a PCB CAD tool, EAGLE should not require dealing with the

validity of web links...

>> 1.Always set a prefix, otherwise EAGLE will use U$ by default.

>> 2.When creating multi-gated components, EAGLE will by default reference

>> them as G$1, G$2, etc. These names will not show up on the schematic,

>> therefore use the NAME command to rename the gates A, B, C, etc. A nice

>> way to do this is to type 'A' followed by enter when you have the gate

>> on your mouse cursor before placing it, EAGLE will then continue the

>> pattern for the other gates.

>> 3.Use P for power symbols.

>> 4.When naming devices use specific part numbers.

>> 5.Always double check add levels and swap levels, otherwise your

>> components might not enter your schematic as you'd expect them to.

>> Recommendations for Devices

>> 1.Just like packages, having a good description field can improve the

>> chances of the ADD command finding the component you want. A good

>> description field for a device should include:

>> Device name(preferably in bold).

>> Any other aliases the device might be recognized by.

>> A link or reference to the device's data sheet.

>> Manufacturer(s).

>> Short explanation of the device's function.

>> If applicable length x width dimension.

 

Yes to all of the above.

...except to 4.

Correct that to: Use generic devices wherever possible.

If you use specific part numbers, you'll end up with zillions of

identical devices, just with different names (i.e. TL072, MC1458, LM358,

TLC272, TLV272, etc. pp.).

For this particular example, I have one device for a dual opamp in

standard pinout, with the common package variants (DIP, SO, etc.). After

having placed it in a schematic, I simply set its VALUE to the correct one.

The same applies to all parts with standard packages and pinouts: many

transistors, thyristors and TRIACs, comparators, voltage regulators etc.

Only those that don't share a standard pinout need their own devices.

(The same rule can be applied to more complex parts as well, i.e.

microcontrollers with different features or memory sizes, but the same

symbol and pinout. They need only one device - with a properly set value.)

Tilmann

Am 22.10.2011 17:33, schrieb Tilmann Reh:

Andreas Weidner schrieb:

 

>> Am 22.10.2011 00:38, schrieb Jorge Garcia:

>>> 1.Do not modify EAGLE's default libraries.

>>

>> Yes.

 

Indeed.

 

>>> 2.User libraries should not be stored in EAGLE's internal lib folder.

>>

>> For beginners, that seems to be OK. For people who only use their OWN

>> libraries (and NOT the CadSoft ones), that could be cumbersome, but

>> anyway...

 

Additionally: EAGLEs internal libraries should NOT be installed in a

subdirectory of the programs installation path. This also applies to all

other "data" directories (projects, ULPs, SCRs, CAM jobs etc.).

 

>>> 1.Symbol pins must always align to a 0.1”(2.54mm) grid.

>>> 2.Symbols must always have>NAME and>VALUE place holders on layers 95

>>> Names and 96 Values respectively.

>>

>> Yes and Yes.

 

...and yes.

wire width for symbol outlines 16 mil.

>>> 3.Place>NAME on top, and>VALUE on bottom side of the symbol.

>>

>> That is NOT always my recommendation: For SMALL symbols (resistors,

>> capacitors, and whatnots), that works very well. BUT a part's name and

>> value should be NEAR each other, so that one can easily find BOTH of

>> them. Therefore, for large ICs, your suggestion would mean ripping them

>> apart quite considerably. For such parts, I put both of them on top.

>> Since this is something of QUITE personal preference, I wouldn't give

>> any recommendation, but just state that both of them SHOULD BE AVAILABLE

>> (some people leave them out).

 

I fully agree to this. For symbols larger than that of a resistor or

diode, I always place>NAME and>VALUE close to each other. (Normally on

top of the symbol, but that's my personal taste, of course.)

 

Mine too

>>> 4.Center the symbol around the origin.

>>

>> Yes. Approximately. So that all pins are STILL on a 0.1" grid.

 

Exactly.

 

>>> 1.Power pins should generally have their pin direction parameter set to

>>> Pwr.

>>> 2.Input pins should generally have their pin direction parameter set to IN.

>>> 3.Output pins should generally have their pin direction parameter set to

>>> OUT.

>>> 4.Passive pins should generally have their pin direction parameter set

>>> to PAS.

>>> 5.Also IO, HIZ, NC.

>>> 6.Do not use pin direction SUP for a normal Symbols. SUP is only for

>>> supply-pins!

>>> 7.Any symbol notes or tips should be on layer 97 info.

>>> 8.It is better to give general names(OP AMP, DIODE, etc.) to symbols

>>> instead of specific part numbers (LM741, 1N4007, etc.). This makes it

>>> easy to reuse the symbol if your library is going to contain many

>>> variations of the same type of component for example a library full of

>>> op amps can probably make use of one op amp symbol.

>>

>> Yes for 1 to 8.

 

Pin directions are somewhat difficult since they may lead to many

"false" DRC complaints. For example, different (ly named) power pins at

ICs which would ask for equally named nets.

But, "generally", this is OK. Of course, there are exceptions...

 

I suggest an additional rule here regarding pins:

Never name pins with respect to pad numbers/names later in the device

resp. package. Pin names always should represent the function of the

pin, nothing else.

YES

>>> 9.For the>NAME and>VALUE text use a text size of 70 mils.

>>

>> This perhaps is too user-dependent. I wouldn't give a recommendation

>> here, but anything from 50 to 80 mils seems to be OK (I myself prefer

>> 60mil).

I use 60 mil too

Agreed - but as a general starting point, 70 mil appears OK to me.

 

>>> 1.Design a package assuming that it will be placed on top of the board

>>> (Use t layers). The MIRROR command can then be used on the board layout

>>> to put a component on the bottom of the board.

>>> Use tPlace for the component silkscreen which is printed on the PCB and

>>> should not contact solder.

>>

>> Yes and yes.

 

and yes.

 

And one more additional suggestion, regarding pads:

Never name pads regarding to a (real, intended or theoretical) function

within a device. Pad names ALWAYS should represent the "official" names

(normally numbers) of the pure package, nothing else.

Yes, numbers only

>>> Use tDocu to draw leads of components leading to pads.

>>> Use tNames for the>NAME place holder for the reference designator that

>>> will be on the silkscreen.

>>> Use tValues for the>VALUE place holder, which will not be part of the

>>> silkscreen.

>>> Use layer 48 Document or layer 49 Reference for any artistic features or

>>> notes that will not appear on the silkscreen.

>>

>> Well, erm, in principle, why not...

 

Personally I find it useful to distinguish between SMD and THT

me too

components - unfortunately, there aren't enough layers to fully do that,

maybe something can be done in future version.

so I use tDocu for SMD outlines, names and values. If I want to print

the part name in silkscreen, I can change its layer to tNames after a SMASH.

 

As generel hints, that suggestion appears OK - at this issue, personal

taste will greatly vary anyway...

 

>>> 2.Center the package around the origin.

>>

>> Yes. Approximately. But, if possible, still leave all pads on a DECENT

>> grid. Grid position takes precedence over centering.

 

No, in most cases centering takes precedence over pad grids. It's pretty

common that packages have off-grid pads anyway, and it's no problem for

EAGLE to deal with them (meanwhile). The mechanical position of a part

often is relevant, and that should be easily derived from its origin

(i.e. the center of a connector or an LED) for further mechanical design

work.

 

ONLY if the center of the package is not relevant at all, AND all pads

become on-grid by that, grid position may take precedence over centering.

 

>>> 1.For the>NAME and>VALUE text use a text size of 70 mils.

>>

>> I do NOT recommend that AT ALL: With typical board densities, this text

>> size is TOO LARGE for the silkscreen and consumes TOO much space. In

>> order to create relatively small text that can still be read, but also

>> has more than 0.2mm wire thickness (which is a common minimal width for

>> manufacturing) to pass typical DRCs, I recommend a text size of 50mil

>> AND a text ratio of 16%.

I use 60 size and 12 ratio

Agreed. The appropriate size of the silkscreen text varies with board

density. At low density boards, I commonly use 1.6 mm text size - and

with increasing density, I reduce that to 1.3 or even 1.0 mm. Thanks to

GROUP SMASH and GROUP CHANGE SIZE that's no big deal.

 

Additionally, the texts of SMD components should be smaller anyway, or

they wouldn't fit in even the paper printout (they're not in the

silkscreen, anyway, but you need a proper documentation as PDF or on

paper including the SMD parts). I commonly use 1 mm, sometimes I need to

reduce to 0.8 mm.

 

>>> 2.Draw outline of package in tPlace with wire width 8 mil or 4mil.

>>

8 mil

>> 8mil is OK, 4mil is NOT: Board manufacturers often have minimal width

>> restraints of 0.2mm (8mil is JUST larger than that) or 0.15mm (4mil is

>> even below THAT). 4mil is a very nice width for paper printouts, but NOT

>> for the silkscreen.

 

Exactly. 0.2 mm (or 8 mil) are good measures.

 

>>> 3.The ADD command in the board editor searches through the description

>>> field, so a well setup description field can yield more fruitful

>>> searches. Therefore a good description field for a package should include:

>>> Standard package name(preferably in bold)

>>> Any possible aliases for the package. For example a DIL08 package might

>>> also be known as a DIP08.

>>

>> Yes.

 

Yes.

 

>>> If the package is based off of a standard document such as one of the

>>> IPC standards, then it should be referenced in the description field if

>>> possible as an HTML link. If a link is not possible then a reference to

>>> the name of the document should be sufficient. Listing this information

>>> will help in checking the package for correctness.

>>> If applicable length x width dimension.

>>

>> For web-based documents, that's OK. It gets harder for LOCAL references:

 

Even for web based documents, that won't work satisfying. Document URLs

change, some disappear completely. So it's always necessary to include a

reference in human readable text form, i.e. "IPC-xxxx, Section X.Y, case

ABCD"). As a PCB CAD tool, EAGLE should not require dealing with the

validity of web links...

Right. Companies are sold or bought and so the search goes astray.

>>> 1.Always set a prefix, otherwise EAGLE will use U$ by default.

>>> 2.When creating multi-gated components, EAGLE will by default reference

>>> them as G$1, G$2, etc. These names will not show up on the schematic,

>>> therefore use the NAME command to rename the gates A, B, C, etc. A nice

>>> way to do this is to type 'A' followed by enter when you have the gate

>>> on your mouse cursor before placing it, EAGLE will then continue the

>>> pattern for the other gates.

>>> 3.Use P for power symbols.

>>> 4.When naming devices use specific part numbers.

>>> 5.Always double check add levels and swap levels, otherwise your

>>> components might not enter your schematic as you'd expect them to.

>>> Recommendations for Devices

>>> 1.Just like packages, having a good description field can improve the

>>> chances of the ADD command finding the component you want. A good

>>> description field for a device should include:

>>> Device name(preferably in bold).

>>> Any other aliases the device might be recognized by.

>>> A link or reference to the device's data sheet.

>>> Manufacturer(s).

>>> Short explanation of the device's function.

>>> If applicable length x width dimension.

>>

>> Yes to all of the above.

 

...except to 4.

Correct that to: Use generic devices wherever possible.

that would be better

 

If you use specific part numbers, you'll end up with zillions of

identical devices, just with different names (i.e. TL072, MC1458, LM358,

TLC272, TLV272, etc. pp.).

 

For this particular example, I have one device for a dual opamp in

standard pinout, with the common package variants (DIP, SO, etc.). After

having placed it in a schematic, I simply set its VALUE to the correct one.

 

The same applies to all parts with standard packages and pinouts: many

transistors, thyristors and TRIACs, comparators, voltage regulators etc.

Only those that don't share a standard pinout need their own devices.

 

(The same rule can be applied to more complex parts as well, i.e.

microcontrollers with different features or memory sizes, but the same

symbol and pinout. They need only one device - with a properly set value.)

 

Tilmann

Wih a few exceptions that seems OK

It is OT here, but labels should have their own size-(ratio)-parameter.

--

Mit freundlichen Grüßen / With best regards

Joern Paschedag

Am 22.10.2011 17:33, schrieb Tilmann Reh:

Correct that to: Use generic devices wherever possible.

 

If you use specific part numbers, you'll end up with zillions of

identical devices, just with different names (i.e. TL072, MC1458, LM358,

TLC272, TLV272, etc. pp.).

Yes, BUT at least for our institute, SPECIFIC devices are exactly the

right thing to do: Our students are new to the whole stuff and know

neither standard pinouts nor data sheet specifications by heart.

Therefore, our devices include the manufacturer's base name (without

suffix) and a manufacturer-independent suffix for the package type

(e.g., 'S' for SMD). Data sheet excerpts are also included in the

library, so the students can quickly find some rough information about

what IC they need before looking through millions of data sheets.

Andreas Weidner

Am 23.10.2011 21:39, schrieb Andreas Weidner:

Am 22.10.2011 17:33, schrieb Tilmann Reh:

>> Correct that to: Use generic devices wherever possible.

>>

>> If you use specific part numbers, you'll end up with zillions of

>> identical devices, just with different names (i.e. TL072, MC1458, LM358,

>> TLC272, TLV272, etc. pp.).

 

Yes, BUT at least for our institute, SPECIFIC devices are exactly the

right thing to do: Our students are new to the whole stuff and know

neither standard pinouts nor data sheet specifications by heart.

 

I did that too when I started with eagle, but remember that this is a

suggestion for creating libraries only.

How the user is handling this is still up to him / her.

Maybe the guidelines should also mention not to create a big "new"

xxx-7.lbr if just one device is added to the xxx-6.lbr.

Therefore, our devices include the manufacturer's base name (without

suffix) and a manufacturer-independent suffix for the package type

(e.g., 'S' for SMD). Data sheet excerpts are also included in the

library, so the students can quickly find some rough information about

what IC they need before looking through millions of data sheets.

 

Andreas Weidner

I like that, could you show an example here?

--

Mit freundlichen Grüßen / With best regards

Joern Paschedag

Jorge Garcia wrote:

>Some users like to make a separate library for each project they work on

>and store it along with the board and schematic file that way everything

>is together and easily accessible. A simple USE command in the

>schematic/board editor will make the library active and available for

>the ADD command.

Even if I use "global" libraries, there might be project specific

parts. Therefore I have always "." in my library search path - but

this only works because I invoke Eagle passing the epf path.

I repeat my long standing suggestion to implement a new placeholder

"$epfdir" for the path the current project resides in. Last time in

eagle.suggest.eng, Subject: Re: Project handling, epf, eaglerc,

Date: 27 Jan 2011,Message-ID:

<ntp2k65feu6rgdlt0q51l7kicv80v65han@news.cadsoft.de>

>Recommendations for Symbols

>1.Power pins should generally have their pin direction parameter set to Pwr.

I consider the current ERC rules for power pins annoying, e.g. warning

me that I connected V+ to +5V. Therefore I don't use PWR in my

libraries.

>Packages

>1.Design a package assuming that it will be placed on top of the board

>(Use t layers). The MIRROR command can then be used on the board layout

>to put a component on the bottom of the board.

>Use tPlace for the component silkscreen which is printed on the PCB and

>should not contact solder.

>Use tDocu to draw leads of components leading to pads.

>2.Draw outline of package in tPlace with wire width 8 mil or 4mil.

first you say that tPlace is "silkscreen", now it's "outline"?

Both serves different purposes.

The precise package outline is needed during placement to see whether

there is enough distance between parts. That's essential information

in high density boards!

Silkscreen is sometimes needed for manual mounting, test, repair. In

our boards, there is usually no place for designators, we don't use

silkscreen print.

Oliver

--

Oliver Betz, Munich

despammed.com is broken, use Reply-To:

Andreas Weidner wrote:

>Am 22.10.2011 17:33, schrieb Tilmann Reh:

>> Correct that to: Use generic devices wherever possible.

>>

>> If you use specific part numbers, you'll end up with zillions of

>> identical devices, just with different names (i.e. TL072, MC1458, LM358,

>> TLC272, TLV272, etc. pp.).

>Yes, BUT at least for our institute, SPECIFIC devices are exactly the

>right thing to do: Our students are new to the whole stuff and know

>neither standard pinouts nor data sheet specifications by heart.

I understand this specific issue, but for professional use,  I also

prefer generic devices over cluttered libraries.

Oliver

--

Oliver Betz, Munich

despammed.com is broken, use Reply-To:

Am 24.10.2011 10:18, schrieb Joern Paschedag:

>> Therefore, our devices include the manufacturer's base name (without

>> suffix) and a manufacturer-independent suffix for the package type

>> (e.g., 'S' for SMD). Data sheet excerpts are also included in the

>> library, so the students can quickly find some rough information about

>> what IC they need before looking through millions of data sheets.

 

I like that, could you show an example here?

Please find attached a screenshot of one device of my opamp library

containing:

  - SOME data sheet excerpts for quick reference

  - NO data sheet links yet, because I either have to set up a decent

    data sheet server myself or wait until USEFUL local references

    in HTML texts are possible in EAGLE

  - Information about simulation support (our EAGLE can do simulations

    in conjunction with LTSpice and another simulator).

  - Package options: ALL our ICs are available in different flavours,

    with names manufacturer-independent and CONSISTENT across ALL

    libraries for easy memorising:

     - Suffix N: DIP case with 'normal' (big) pads, for easy

       soldering, but without the possibility of routing between pads

     - Suffix L: DIP case with 'long' pads, for easy soldering AND

       routing between pads

     - Suffix R: DIP case with 'reduced' pads, for routing between

       pads and saving space

     - Suffix S: SMD case

In order not to confuse our students with the different suffixes that

would normally appear in the >VALUE texts, the library makes use of

self-made >TYPE attributes (set to just 'LT1124' in this case).

Therefore, for ANY integrated circuit available, you immediately KNOW

how to call it when wanting to insert the SMD variant, e.g., OP07S. And

our students have a choice of DIP packages taking into account their

soldering skills (at least for circuits where the package type doesn't

really matter).

Passive components are like that, too: Our standard resistor is called

'R'. Nothing more than that, and it comes in a package with large pads

and 0.4" pad distance. If you want to have it with 0.5", it is called

'R05', in 1.0" it is called 'R10', in SMD size 1206 it's called 'R1206'.

EXTREMELY simple, EXTREMELY effective. THAT is the reason why the usage

of the command line can save about 90% of drawing time in our institute:

You VERY seldom need to open the library browser, because the

overwhelming majority of parts can just be typed in without thinking.

And for all rather special parts (like low-inductance TO-220-68TO-220-68 resistors

or sophisticated connectors) which you can't remember anyway, you just

use the library browser...

Andreas Weidner

Andreas Weidner schrieb:

...

EXTREMELY simple, EXTREMELY effective. THAT is the reason why the usage

of the command line can save about 90% of drawing time in our institute:

You VERY seldom need to open the library browser, because the

overwhelming majority of parts can just be typed in without thinking.

I am doing it that way for decades - hard to imagine there's another way

at all...

Besides - what's a library browser?? O:-)

And for all rather special parts (like low-inductance TO-220-68TO-220-68 resistors

or sophisticated connectors) which you can't remember anyway, you just

use the library browser...

If you know at least a part of the device name, ADD with wildcard pretty

well finds it for you. That's what I do if I can't remember to complete

device name for a particular variant...

I think I didn't use that "library browser" at all yet.

Tilmann

Am 24.10.2011 15:02, schrieb Tilmann Reh:

I am doing it that way for decades - hard to imagine there's another way

at all...

Some would think both of us old-fashioned ('old school - invented before

the mouse'), but it's SO wonderful to be able to do that and save LOTS

of time.

Besides: At first, I used EAGLE with the mouse (version 2 for MS-DOS),

and only AFTERWARDS learned how much quicker SOME things can be done

with the command line. Mouse came first, keyboard later - NOT the other

way around as some suggested somewhere...

Andreas Weidner