symbol with multiple package variations

"Gary Gofstein" <ggofstein@lbl_nospam.gov> schrieb im Newsbeitrag

news:g2msm2$ftf$1@cheetah.cadsoft.de...

I still do not understand your problem, if I have an opamp that has thru

I see you respond to Don Owen, but allow me to jump in again....

hole and SMD package variations, and I want to change the package but

maintain the same part, that is easily changeable by the method I

described: on your layout, use the change command, select package, click

your part and you will be given a choice of which package to use.

 

Of course this only works if the package has already been tied to that

particular part in the library.

Exactly, and this is the point.

It is not true ( in general) that the pins for the different packages will

always correspond, so pin 2 on the DIL package may not be connected to

the same node as pin 2 on the SOIC package.

This clearly is within the designer's responsibility. I do not want to be

forced into useless library work just because there is a slight chance that

the pin numbering scheme does not correspond in some cases. Simply because

the risk is not the least bit lower if you do it all through the libraries.

This is a waste of time. Did you ever work with Eagle V3.5? I am still

working with it today for most of the time, although I have all licenses up

to V5, and this is one of the reasons.

Although, if you mostly use logic, you may never have come across this.

This is the reason why you may have to use the "connect" dialog in the

library to link a particular part to a new package. In general, there is

no one to one correspondence. If you doubt this I can send you some

examples!

I know, and I tell you this added "connect" complexity through the use of

the library editor is worth absolutely nothing. I already had these

discussions. My answer in the past was that you can do exactly the same

mistake within the library editor: In V3.5 you could replace a package with

another. Trouble arose if the pin numbering was different. Today you have to

define and "connect" a new package in the library editor. Just as easily you

can take over the (wrong) pin assignment from another package. The only

difference here is the increased effort. Again, this is a time waster. It is

even more likely that you are so busy with the definition of the new

packages in the library editor that you miss the actual problem with the non

matching numbering. With the "REPLACE" I start to think about this at

exactly the right time, and I am not distressed by this package definition

nonsense inside the lib editor.

I am very confused by your posting. It seems that you are saying you wish

there was another layer of package specification so that all 14DIL

packages could be substituted for one another. So you could have a 14DIL

with big and with small holes, or 8SOIC with two pad variations, one for

wave and one for hand soldering? Then they would always correspond, so

there would be no need to specify where the signals come out on each

package pin? Is this what you're saying?

 

Basically, I can't tell if your just overlooking the admittedly obtuse way

(that most things are in EAGLE) of changing packages simply and easily.

Or, if you really have a problem that EAGLE's package substitution won't

solve and also don't appreciate that there is no way to generally

substitute one package for another. Or, perhaps I have no clue as to what

you're talking about and your problem would instantly make sense to me

once I understood what, exactly, you are trying to do.

As I pointed out elsewhere: if we both were to update the same board by

replacing a number of components (say, from SO footprint to TSSOP), and you

do it with V5 or V4, while I do it with V3.5, I can promise you that you are

still busy defining the first two packages, when I already finished my job,

closed my office and made myself a nice tea.

T.

So you weren't really looking for "support" so much as you are asking

for a new feature, or more accurately the removal of a "misfeature".

Well, I never used v3 of EAGLE, so I guess I don't know how much more

easily it handles this problem for you.

In my case, the packages rarely have any significant correspondence, so

I am quite happy with the connect dialog. It takes me only a few seconds

to connect up those 8 op amp pins while I glance at the data sheet. My

bottleneck is remembering how to copy other packages into the library if

they are not already present.

Maybe the new pins in the connect dialog should default to the pads that

are already defined for the part. Then you'd only have to click OK if

they match up. That would save you 2 mouse clicks per pad. I could see

that if you have a package with dozens or hundreds of pins that match

up, it would make real sense.

Again, I'll stress, my situation is the exact opposite of yours, the

packages do not correspond, so I love the connection dialog. But I

generally support your view, the software doesn't need to babysit or

think for  the user. Maybe I'll download 3.5 and try it! Go have a nice tea!

So you weren't really looking for "support" so much as you are asking

for a new feature, or more accurately the removal of a "misfeature".

Well, I never used v3 of EAGLE, so I guess I don't know how much more

easily it handles this problem for you.

In my case, the packages rarely have any significant correspondence, so

I am quite happy with the connect dialog. It takes me only a few seconds

to connect up those 8 op amp pins while I glance at the data sheet. My

bottleneck is remembering how to copy other packages into the library if

they are not already present.

Maybe the new pins in the connect dialog should default to the pads that

are already defined for the part. Then you'd only have to click OK if

they match up. That would save you 2 mouse clicks per pad. I could see

that if you have a package with dozens or hundreds of pins that match

up, it would make real sense.

Again, I'll stress, my situation is the exact opposite of yours, the

packages do not correspond, so I love the connection dialog. But I

generally support your view, the software doesn't need to babysit or

think for  the user. Maybe I'll download 3.5 and try it! Go have a nice tea!