How to create library part with thermal pad?

Well Mr Pearce,

as much as I thank you for your help, I must admit that I am not as

knowledgeable using Eagle as you might have thought I was. That is why I

didn't understand (and still don't) why there are supposed to be holes in

the tStop layer, what they do, nor how come it is one of the only two

layers that are generated automaticall for a SMD pad. there might be

something (or more than one thing) that I don't understand, that's obvious,

but if I did know, then I obviously wouldn't be posting on this forum, eh?

So, no need to insinuate something by saying that I need less syllables in

order to understand, or telling me to read the help file when I don't even

know specifically what to look for... It is hard to know what to look for

when you think you've looked at everything you could think of, and then

there's the things one doesn't think of...

In any case your explanation did help me out. I shall try this polygon

perimeter-delimitation method with the tRestrict layer.

sincerely,

Redcutlass

--

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

Redcutlass wrote on Wed, 30 March 2011 12:29

That is why I didn't understand (and still don't) why there are

supposed to be holes in the tStop layer, what they do, nor how come it is

one of the only two layers that are generated automaticall for a SMD pad.

It seems now the real problem is not as much your understanding of Eagle,

but that you don't understand how PC boards work and how they are made.  If

you did, it would be intuitive how some of the Eagle layers map to layers

of a PCB.

Briefly, a PCB can the thought of as a sandwich of layers.  For simple

double sided boards from top to bottom these are the top silkscreen, top

soldermask, top copper, the PCB material itself (usually FR4 fiberglass),

bottom copper, and bottom soldermask.  You might also have a bottom

silkscreen for a more complicated board.

Go read up on PCB construction, then how the Eagle layers map to that will

make sense.

--

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

Am 04.04.2011 21:58, schrieb Gary Gofstein:

On 4/4/2011 7:00 AM, Olin Lathrop wrote:

>> Klaus Schmidinger wrote on Mon, 04 April 2011 04:35

>>> Well, I'm sorry I got into contact with the GED before I was

>>> "contaminated" with Windows,

>>

>> It's not a Windows thing. The copy and cut convention was around well

>> before that.

>>

>> Quote:

>>> To get this recurring discussion over with once and for all I suggest

>>> the following changes for version 6:

>>

>> The current problem is one of naming, not of how the commands actually

>> work. I think that changing anything now will cause too much pain to

>> people that have managed to get used to how it works, and more

>> importantly

>> that have scripts and ULPs that rely on the existing names.

>>

>> The fix is therefore documentation, not changing code. There should be a

>> "Introduction to Eagle" section or something new users will find that

>> explains the various unobvious things about Eagle. CUT doing just a COPY

>> should be prominently mentioned, and what COPY really does and when you'd

>> use that over CUT also needs to be made clear. That would have saved me a

>> bunch of time back when I started. (actually I'm still a little hazy

>> about

>> when to use COPY versus CUT, although I haven't spent the time to

>> deliberately try and educate myself either)

>>

I think the problem is not the functionality of the commands, it's the

misleading use of language to describe what they do. I agree that if

copy is renamed to "duplicate", it is consistent with other software and

obvious what it does. And cut then becomes copy, which would be

misleading except that in all other software, copy has a consistent

meaning of "place into paste buffer".

 

These command names in English predate Windows by many, many years. I

remember using a DEC CRT terminal (smart terminal) on a mainframe that

had local editing capability with a cut/copy/paste buffer in the 1980's.

 

Although "invoke" can be traced to the latin roots for "call in" ( which

is exactly what it does), the word invoke, in american english, can not

be used in this way. Changing the name to "Call Gates" or, even better,

"More Gates" or "Add Gates" would be a good start for a workable name

for this command. You could just leave the old "invoke" as well and not

tell anybody about it.

 

None of these changes have anything to do with experienced users, they

just clarify things for new users. It seems rather unprofessional to

have variances from accepted UI practice, /especially when it could be

done without them/. So, some of EAGLE's odd use of mouse controls is

much more acceptable, because it's not clear how it could be done with

the established UI model. But misleading names = sloppy software in the

new user's eyes.

I think this should be discussed in a new thread since it has nothing to

do with thermal pads.

--

Mit freundlichen Grüßen / With best regards

Joern Paschedag

On Sun, 3 Apr 2011, Olin Lathrop wrote to us saying :

However,

>pretty universally when you see vertical text here it is written going

>down, not up.  This applies to signs, the spines of books, and just about

>everything else.  Vertical text going up looks stupid, at least here.

Here in the UK that's not true. Sure, book spines are (usually) set to

read down, but that's actually for a book-specific reason: if you lay

the book down on a table with the front cover up, the text on the spine

is right-reading. Vertical text on a page usually runs upward, because

in the old days when it was a hand-written annotation a right-handed

person will always find it easier to write upward.

--

Rob Pearce                       http://www.bdt-home.demon.co.uk

The contents of     | All power corrupts, but we need electricity.

this message are    |

purely my opinion.  |

Don't believe a     |

word.               |

Klaus Schmidinger wrote:

>> It is pretty universally understood that CUT does a copy and delete.  This

>> was well established before Eagle was written.  It is totally beyond me

>> what Klaus and company were thinking when they named the copy command

>> "cut".

>The user interface of EAGLE was inspired by the "Valid GED", a graphical

>editor I was working with during my time at Siemens. In that editor the

Thanks for the insight. I always wondered where the naming comes from.

>To get this recurring discussion over with once and for all I suggest

>the following changes for version 6:

Please don't change the behaviour of the commands this way. It would

be a severe drawback!

As others wrote, it's a naming problem - the main issue is that the

current CUT command does "copy" to the buffer, not "cut".

I'm not sure whether renaming of the commands is suitable (compromise

"compatibility" vs. "new user friendliness"), and since I use Eagle

for a long time, I'm not able to give an unbiased vote.

If you ever think about changing the function, I strongly suggest to

start threads in the relevant groups and get the opinions from a

broader audience.

We might consider the relationship between COPY and CUT, and the use

of the left mouse button with CUT in this case.

Oliver

On Wed, 6 Apr 2011, Oliver Betz wrote to us saying :

>As others wrote, it's a naming problem - the main issue is that the

>current CUT command does "copy" to the buffer, not "cut".

The command currently referred to as "cut" is the problem, but if

renamed to "copy" then the existing command of that name causes trouble.

The best "fix" would be to alias the cut command to something clear and

unambiguous that doesn't clash with an existing command. But I can't

think of anything suitable. The existing "copy" command could be called

"clone" or something like that, since its functionality is akin to

duplicating individual components, but that in itself doesn't help

because it's the "cut" command that confuses people. I suppose "cut"

could be renamed to "clone" but that would, at least to me, still feel

to be the wrong way round.

Sorry, I'm not helping am I.

--

Rob Pearce                       http://www.bdt-home.demon.co.uk

The contents of     | All power corrupts, but we need electricity.

this message are    |

purely my opinion.  |

Don't believe a     |

word.               |

On 04/01/11 14:58, Olin Lathrop wrote:

...

Another annoying "feature" that is due to Eagle's origin is that vertical

text reads up not down.  That is the german convention.  However, I am

using the english language version, and judging from the number of

downloads and the activity in this forum, the english language version is

much more popular.  Is this ever going to get fixed?  It's been reported

as a problem long ago.  At the very least there should be a setting for

default vertical text direction.

I'm currently looking into this and would appreciate your advice on the

exact details.

The "German" convention is to have texts be readable from bottom

or right, as shown in the attached image. So any text with an angle

of '90 < angle <= 270' is drawn "upside down".

I understand that the texts "ABC R90" and "ABC R270" would have to

be drawn upside down in the American convention, but what's with

the other texts? Can you give me an expression like the above one,

which takes the angle and calculates whether or not to modify

the orientation?

Or can you point me to a web page that explains the American convention

for text orientations?

Klaus Schmidinger

--

_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10

CadSoft Computer GmbH                   Fax:   +49-8635-6989-40

Pleidolfweg 15                          Email:   kls@cadsoft.de

D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de

_______________________________________________________________

Attachments:

On 09/20/11 11:47, Klaus Schmidinger wrote:

On 04/01/11 14:58, Olin Lathrop wrote:

>> ...

>> Another annoying "feature" that is due to Eagle's origin is that vertical

>> text reads up not down. That is the german convention. However, I am

>> using the english language version, and judging from the number of

>> downloads and the activity in this forum, the english language version is

>> much more popular. Is this ever going to get fixed? It's been reported

>> as a problem long ago. At the very least there should be a setting for

>> default vertical text direction.

 

I'm currently looking into this and would appreciate your advice on the

exact details.

 

The "German" convention is to have texts be readable from bottom

or right, as shown in the attached image. So any text with an angle

of '90 < angle <= 270' is drawn "upside down".

 

I understand that the texts "ABC R90" and "ABC R270" would have to

be drawn upside down in the American convention, but what's with

the other texts? Can you give me an expression like the above one,

which takes the angle and calculates whether or not to modify

the orientation?

Answering to myself: I guess the only two texts that need to

be modified are those with rotation R90 and R270. All others will

be left as is.

The attached images show how this will look. Note that the pad names

of vertical pins will be drawn on the opposite side of the pin wire,

so that when looking at a pin the text is always "above" the pin wire.

Klaus Schmidinger

--

_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10

CadSoft Computer GmbH                   Fax:   +49-8635-6989-40

Pleidolfweg 15                          Email:   kls@cadsoft.de

D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de

_______________________________________________________________

Attachments:

Klaus Schmidinger wrote on Wed, 21 September 2011 10:06

The attached images show how this will look. Note that the pad names of

vertical pins will be drawn on the opposite side of the pin wire, so that

when looking at a pin the text is always "above" the pin wire.

One way or another, vertically oriented text needs to read down, not up.

If you look at a bookshelf here in the US, the titles on the bindings all

read down, for example.

What to do about text that is not exactly vertical or horizontal is a gray

area that I think doesn't have a single right answer.  The example in your

first picture is probably as good as any.  Your second picture is right

on.

Perhaps this whole thing is a problem only because of two unfortunate

design choices:  Eagle wants to "fix" something it maybe shouldn't be

messing with at all, and it doesn't have general text anchoring

capability.

Most systems that have to deal with graphical text allow at least the

choice of the 9 common anchor positions.  The text string extent is

considered a rectangle which can be anchored at any of the 4 corners, the

centers of the 4 edges, or the middle.  With a system like that there is

little need to automatically flip text orientation - in fact it's better to

leave it alone and let the user do what he wants.

To use a Eagle example, suppose I'm making the symbol for a horizontal

resistor.  I want to have the part designator above the symbol and the

value below, but each centered horizontally.  There is no way to do that in

Eagle now.  You have to guess how wide each string is going to be and move

it around so that it will be centered for the nominal width.  Short strings

will end up a little to the left and long strings to the right.  What I

really want to do is anchor the top string to its lower middle point and

the bottom string to its top middle point.  Fortunately for a resistor

there is usually enough room and a little misalignment can be ignored.

However, that was just to illustrate the point.

If Eagle doesn't automatically try to "fix" text orientation, this issue

wouldn't be a problem.  I guess that's like saying the spin flag should

always be on.  After laying out and routing a board, you always expect to

clean up the silkscreen and move text around to where it will be visible

and meaningful.  The text starts out a mess, but that's expected.  Having

that also be upside down makes it no worse.  As you're moving the strings

around with the mouse, a simple right click rotates it another 90 degrees

left.  If it reads up and I want it reading down, two quick mouse clicks

fix that.  The extra mouse clicks are irrelevant since it's a lot less than

moving the text to a decent spot to begin with.  The problem is when Eagle

decides to fix it and never allow the preferred vertical orientation

without having to turn on the spin flag.  That is a bid deal since it's

outside the simple workflow of moving the text around with the mouse.

So I think a better answer is to get rid of the spin flag altogether, give

us at least the 9 basic text anchor points, and never have Eagle think it

knows anything about what direction text should be other than how the user

set it.

Of course I'd have to actually try that to know for sure

--

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

Would it make sense to keep your circle of labels independant on view

rotation? If so, both are wrong, and you would need a flag to set

direction.

On 21.09.2011 18:53, Olin Lathrop wrote:

...

give us at least the 9 basic text anchor points

This will be possible in version 6.

Klaus Schmidinger

--

_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10

CadSoft Computer GmbH                   Fax:   +49-8635-6989-40

Pleidolfweg 15                          Email:   kls@cadsoft.de

D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de

_______________________________________________________________

On Wed, 21 Sep 2011, Olin Lathrop wrote to us saying :

>One way or another, vertically oriented text needs to read down, not up.

>If you look at a bookshelf here in the US, the titles on the bindings all

>read down, for example.

A bookshelf is a very poor model to use as referent. Book spines have

the text that way round purely to be right-reading when placed on a

table face-up. For annotations in margins (which is MUCH closer to the

model we're looking for) the natural thing for a right-handed person is

to write upwards, not down.

--

Rob Pearce                       http://www.bdt-home.demon.co.uk

The contents of     | All power corrupts, but we need electricity.

this message are    |

purely my opinion.  |

Don't believe a     |

word.               |

On Wed, 21 Sep 2011, Olin Lathrop wrote to us saying :

>One way or another, vertically oriented text needs to read down, not up.

>If you look at a bookshelf here in the US, the titles on the bindings all

>read down, for example.

A bookshelf is a very poor model to use as referent. Book spines have

the text that way round purely to be right-reading when placed on a

table face-up. For annotations in margins (which is MUCH closer to the

model we're looking for) the natural thing for a right-handed person is

to write upwards, not down.

--

Rob Pearce                       http://www.bdt-home.demon.co.uk

The contents of     | All power corrupts, but we need electricity.

this message are    |

purely my opinion.  |

Don't believe a     |

word.               |

Robert Pearce wrote on Fri, 23 September 2011 12:55

A bookshelf is a very poor model to use as referent.

It was merely a example.  How is the text on the spine of german books

oriented?  The only german book I could find right here where I am now has

a wide enough spine that the text is horizontal, so no help.

In any case, the point is that Eagle shouldn't be assuming a particular

convention and let the user more easily rotate text as he likes.

--

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

On 24.09.2011 00:51, Olin Lathrop wrote:

Robert Pearce wrote on Fri, 23 September 2011 12:55

>> A bookshelf is a very poor model to use as referent.

 

It was merely a example.  How is the text on the spine of german books

oriented?

German books usually have the text reading upwards.

In any case, the point is that Eagle shouldn't be assuming a particular

convention and let the user more easily rotate text as he likes.

Imagine a symbol with two pins, one extending to the right

and one to the left (i.e. rotated by 180 degrees). Would you

really want the pin and pad names of the left pin be written

upside down?

Klaus Schmidinger

--

_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10

CadSoft Computer GmbH                   Fax:   +49-8635-6989-40

Pleidolfweg 15                          Email:   kls@cadsoft.de

D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de

_______________________________________________________________

Klaus Schmidinger wrote on Sat, 24 September 2011 04:59

German books usually have the text reading upwards.

That's what I thought but wasn't sure.  Here in the US the spine of books

when in a bookcase read down.  This means there definitely are different

regional conventions.

Again, the books are only one indication of the general preference.  The Y

axis label is a special case because the Y axis "flows" upwards and the

text is just going along with that.  Other than in such cases, upwards

vertical text just looks strange or wrong.

Quote:

Imagine a symbol with two pins, one extending to the right

and one to the left (i.e. rotated by 180 degrees). Would you

really want the pin and pad names of the left pin be written

upside down?

No I wouldn't, but this particular case is a lot easier because there are

only 4 possible pin orientations so it's easy to say up front what the text

orientation for each case should be.  In the two vertical cases I want the

text reading down, not up as now.  This should probably be based on a

global vertical text orientation switch.

What I was thinking about more was arbitrary graphical text created with

the TEXT command, like in the silkscreen layer coming from package

definitions.  Those end up in arbitrary locations and orientations anyway,

so I don't care how Eagle originally writes them as long as it's easy for

me to move around and reorient.  Note that easy doesn't include having to

set the spin flag.

--

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

Klaus Schmidinger wrote:

On 24.09.2011 00:51, Olin Lathrop wrote:

>> Robert Pearce wrote on Fri, 23 September 2011 12:55

>>> A bookshelf is a very poor model to use as referent.

>>

>> It was merely a example.  How is the text on the spine of german

>> books oriented?

 

German books usually have the text reading upwards.

 

Book titling is irrelevant but the following from Wikipedia  completes our

education.

QUOTE

Spine titling.......

......Early books did not have titles on their spines; rather they were

shelved flat with their spines inward, and titles written with ink along

their fore edges. Modern books display their titles on their spines.

In languages with Chinese-influenced writing systems, the title is written

top-to-bottom, as is the language in general. In languages written

horizontally, conventions differ about the direction in which the title on

the spine is rotated:

• In the United States, the Commonwealth and in Scandinavia, titles are

usually written top-to-bottom on the spine. This means that when the book is

placed on a table with the front cover upwards, the title is correctly

oriented left-to-right on the spine. This practice is reflected in the

industry standards ANSI/NISO Z39.41[22] and ISO 6357.[23]

• In most of continental Europe, titles are conventionally printed

bottom-to-top on the spine so, when the books are placed vertically on

shelves, the title can be read by tilting the head to the left.[24]

END QUOTE

Latin America publications are not mentioned  but a quick search reveals

they mainly follow Europe.

Warren

--

Viewed / responded via the newsgroup at

news.cadsoft.de