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.

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.

Currently this is a outright bug in the english language version, but

Cadsoft doesn't seem to take is seriously because it looks right in

the version they use.

Off subject apologies.

I had not previously known of this  'text reads down' preferrence and agree

that if a significant portion of the market desires it then it should be

catered for.

I don't see the default as a German convention. 'text reads up' is my

preferrence as rotating the document clockwise (right) is my preference.

Are you saying the North American convention is to read a document from the

bottom or the left.

Cheers

Warren

warrenbrayshaw wrote on Fri, 01 April 2011 15:46

Are you saying the North American convention is to read a document from

the bottom or the left.

I don't think of it as reading a document from a particular side.  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.

For example, if you look at a german bookcase the titles will read up, but

here they will read down.

All this has been pointed out to Cadsoft before.  They don't seem to care.

They really should enhance text placement in general.  Eagle is workable

but very primitive in that regard.  Most software that lets you graphically

place text allows you to chose the anchor from one of the 9 corners, center

of edges, and center.  After that should be choice of direction, with

something better than the rather awkward "spin" flag to fix things.

I actually wrote a ULP that looks for vertical text strings.  It sets the

spin flag, orientation, and moves the origin around so that the text reads

down instead of up in the same place.  It mostly works, but it does move

the text around a little bit.

--

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

On 04/01/11 14:58, Olin Lathrop 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

COPY command worked in such a way that you select the command and then

click on the object you want to copy. Then you move the copy to the

desired target location and click again to place it.

The CUT command in the GED did only copy the selected group into

the "cutting" buffer for later use with PASTE. It did not delete

the group from the original drawing.

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

with Windows, but that's the reason why COPY and CUT behave as they do

in EAGLE.

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

the following changes for version 6:

- The COPY command, when activated, just copies the group into

   the buffer and terminates immediately. It will no longer be able to

   select individual objects for copying. To copy individual objects

   you will have to draw a group around each object, do a COPY and then

   a PASTE. Unlike the former CUT command, which allowed the user to

   define a reference point to "cut" the group at a particular location,

   at which it will be attached to the mouse cursor when doing a later

   PASTE, there will be no such reference point in the COPY command

   (as usual under Windows, the group will be selected at its center).

- The CUT command becomes a combination of COPY, followed by a DELETE

   of the group. Since board and schematic

   are connected via forward&backannotation, some limitations apply

   to the DELETE command (as is already the case now). Therefore it

   may not be possible to actually delete the entire group. In such a case,

   the group that has been copied into the buffer may contain objects

   that have not been deleted from the drawing. Also, when doing a CUT

   in the schematic, the group that gets copied into the buffer will

   contain only the objects from the schematic, while the DELETE will

   also delete the related objects from the board.

   Alternatively (and since it most likely would cause quite some

   confusion in boards and schematics) the CUT command could be

   removed entirely.

- The PASTE command remains unchanged.

These changes should make EAGLE's COPY/CUT mechanism as "Windows like"

as possible. Whether this behavior is actually useful, is another

question...

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 schrieb:

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

the following changes for version 6:

 

- The COPY command, when activated, just copies the group into

   the buffer and terminates immediately. It will no longer be able to

   select individual objects for copying.

That would be a great disadvantage. I often use COPY on single objects.

It wouldn't be any problem to keep that (with use of the LMB), IMHO -

even if the function for dealing with groups was changed as described above.

   To copy individual objects

   you will have to draw a group around each object, do a COPY and then

   a PASTE.

Horrible.

   Unlike the former CUT command, which allowed the user to

   define a reference point to "cut" the group at a particular location,

   at which it will be attached to the mouse cursor when doing a later

   PASTE, there will be no such reference point in the COPY command

   (as usual under Windows, the group will be selected at its center).

...so you'll run into many grid problems. Selecting the reference point

is a very essential feature of the (current) CUT command.

These changes should make EAGLE's COPY/CUT mechanism as "Windows like"

as possible. Whether this behavior is actually useful, is another

question...

Exactly. I hereby request YAES (yet another eaglerc.usr switch) to

restore the current behaviour.

(Additionally, what about scripts that use the old command syntax?)

Tilmann

P.S. Yes, you have to learn the different command behaviour compared to

windows standard. Yes, you also need to get used to it. But after all,

EAGLE is a complex and powerful design tool - and in the current

implementation, you get the maximum /working efficiency/, and that's

what counts. The need to learn the tools is common for all complex ones.

Perhaps you just need to /rename/ the existing commands to avoid (or

reduce) the windows users confusion? (Script handling should still be

considered, however.)

Am 04.04.2011 10:35, schrieb Klaus Schmidinger:

On 04/01/11 14:58, Olin Lathrop 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

COPY command worked in such a way that you select the command and then

click on the object you want to copy. Then you move the copy to the

desired target location and click again to place it.

 

The CUT command in the GED did only copy the selected group into

the "cutting" buffer for later use with PASTE. It did not delete

the group from the original drawing.

 

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

with Windows, but that's the reason why COPY and CUT behave as they do

in EAGLE.

 

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

the following changes for version 6:

 

- The COPY command, when activated, just copies the group into

the buffer and terminates immediately. It will no longer be able to

select individual objects for copying. To copy individual objects

you will have to draw a group around each object, do a COPY and then

a PASTE. Unlike the former CUT command, which allowed the user to

define a reference point to "cut" the group at a particular location,

at which it will be attached to the mouse cursor when doing a later

PASTE, there will be no such reference point in the COPY command

(as usual under Windows, the group will be selected at its center).

 

- The CUT command becomes a combination of COPY, followed by a DELETE

of the group. Since board and schematic

are connected via forward&backannotation, some limitations apply

to the DELETE command (as is already the case now). Therefore it

may not be possible to actually delete the entire group. In such a case,

the group that has been copied into the buffer may contain objects

that have not been deleted from the drawing. Also, when doing a CUT

in the schematic, the group that gets copied into the buffer will

contain only the objects from the schematic, while the DELETE will

also delete the related objects from the board.

Alternatively (and since it most likely would cause quite some

confusion in boards and schematics) the CUT command could be

removed entirely.

 

- The PASTE command remains unchanged.

 

These changes should make EAGLE's COPY/CUT mechanism as "Windows like"

as possible. Whether this behavior is actually useful, is another

question...

 

Klaus Schmidinger

Well, I think this is going to be a very bad idea. Apart from the fact

that some people think that they are the nabel of the world does not

mean that they are allways right.

You can bet that your suggested change will not close the subject "once

an for all".(Unfortunately)

Eagle is also not written for windows alone but also for linux etc.

But mostly window users go up the wall if something is not windows like.

(I shall not start a discussion about all the windows problems now, but

I am a windows user too).

So some people stumble over "cut" and they have not, and did not want,

learn that in over twenty years.

I bet that if the word "salary" wold be exchanged to "deptor" they would

accept that in 10 seconds

I use the "copy" very often in creating schematics und it would be worse

now allways first painting a group around a device just to copy it.

Why not just simply rename the "cut" into "groupcopy" or whatever you

like and leave the funktions as they are.

A far better idea is to have the complainers come up with a suitable name.

--

Mit freundlichen Grüßen / With best regards

Joern Paschedag

"Klaus Schmidinger" <Klaus.Schmidinger@cadsoft.de> wrote in message

news:inbvt9$fuu$1@cheetah.cadsoft.de...

The CUT word is a real world reference to cutting something from a

sheet of paper, or an old newspaper editing desk. If you cut something

, it is either deleted or moved+pasted somewhere else. The problem with

this reference to Eagle is that brd and sch works "in parallel", so if you

cut in either the traditional way, you have not defined what is going to

happen to the other part of the project.

Maybe the function CUT should be renamed. (how about "CLONE" or

"DUPLICATE"?). To make both this and the copy functions more usable I would

also add more to it, like different options to what happens to the

copied/cloned netnames when you paste it. This could have been done after

copying as a separate function (edit paste buffer nets), or when pasting. It

is very intuitive to say how this is going to happen GUI wise, but in

command space it may be more difficult to visualize. Maybe the paste buffer

should get its own project.pastebuffer(index).sch and/or

project.pastebuffer(index).brd reference and work much like the main

structure, while commands could get a netname prefix to work in the

pastebuffer, so that a net named "net" would be referred to as

"$paste(1).net" after a copy or clone to buffer 1. (I've assumed there will

be multiple paste buffers here).

The Eagle window could even have a "edit pastebuffer" mode, where the stuff

in the pastebuffer can be opened and edited.

"Morten Leikvoll" <mleikvol@yahoo.nospam> wrote in message

news:inch25$8ic$1@cheetah.cadsoft.de...

 

"Klaus Schmidinger" <Klaus.Schmidinger@cadsoft.de> wrote in message

news:inbvt9$fuu$1@cheetah.cadsoft.de...

Sorry for the left overs..

I could add that there should be a syncronized area clone/copy mode, where

you select a group window on both the sch and brd, and where clone/copy

checks if they contain the same parts and nets, and works on the selected

data in a wysiwyg way.

It should give error if nothing is common, or warning if one selection

contains other nets/parts than the other.

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)

--

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

Olin wrote on Mon, 04 April 2011 10:00

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 don't really agree with that conclusion Olin.  Here is what I would

suggest:

1)  We keep some way of keeping the current methodology for all the old

farts who can't rewire their brains and for the current library of scripts

that rely on the copy and cut commands to do what they normally do.

2)  Provide some method to use a new framework of cut, copy, paste that is

more inline with everything else in the world now.

So I would suggest an option on the SET command that flips back and forth

between these two modes.  For the GUI I would default to use the new modes

(old timers can change their eagle.scr file to easily get back to the old

way of doing things, newbies couldn't do the opposite easily).

I would further suggest that the script command behaves the opposite--it

assumes the older mode and would take a command line option to force it to

use the new functionality of cut, copy, paste.  That way the old scripts

will all work as expected and new ones can tell the command to use the new

mode.  The scripts could also just use the SET command to get the correct

mode to start and restore it when complete.

Then I think we get the best of everything--backwards compatibility and a

way for current users to get back to the way it was.  But new users get the

more modern functionality of these commands and have a better experience

with EAGLE out of the box.

Cheers,

James.

--

James Morrison  ~~~  Stratford Digital

Specializing in CadSoft EAGLE

• Online Sales to North America

• Electronic Design Services

• EAGLE Enterprise Toolkit

--

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

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.

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.

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