How to search in schema tic?

Am 09.09.2016 um 19:35 schrieb Joop:

I have a (system on a) module with 200 pins.

In the library, I divided these pins over 7 symbols in the device.

Those symbols are all in different schematic sheets. There are 15 sheets

so it's impossible to remember where is what.

 

Sometimes I need to find a certain pin of this module but I don't remember

on

which sheet it is.

My question is, is there a way to find out? I tried "run find" but it

doesn't offer what I'm looking for.

 

Thanks.

 

 

Try INVOKE (device name) for example and you get a list of pages the

device is on.

--

Mit freundlichen Grüßen / With best regards

Joern Paschedag

Joern Paschedag wrote on Sat, 10 September 2016 10:38

Try INVOKE (device name) for example and you get a list of pages the

device is on.

Thank you Joern, unfortunately it doesn't help much.

It doesn't show me on which sheet I'll find the pin I'm looking for.

I guess the problem is that, in order to write an ulp that can find the pin

in the schematic,

based on the pin-number of the package which can be made visible in the

board editor,

one must use the deprecated data member "contact" in the object "UL_PIN".

The question arises, why is that data member deprecated??

Am I overlooking something?

Thanks.

From the manual:

Note

The contacts() loop member loops through the contacts that have been

assigned to the

pin through a CONNECT command. This only makes sense in a UL_DEVICE context

(in

other cases the loop is empty).

The contact data member returns the contact that has been assigned to the

pin through a

CONNECT command. This member is deprecated! It will work for backwards

compatibility and as long as only one pad has been connected to the pin,

but will cause

a runtime error when used with a pin that is connected to more than one

pad.

--

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

Attachments:

On 10/09/16 13:12, Joop wrote:

The question arises, why is that data member deprecated??

 

Am I overlooking something?

 

I think the answer to that lies in:

From the manual:

 

It will work for backwards

compatibility and as long as only one pad has been connected to the pin,

but will cause

a runtime error when used with a pin that is connected to more than one

pad.

In other words, the contact member, as opposed to the contacts()

iterator, only makes sense in the context of a single pad being

connected to a pin. This used to be the rule - if you wanted more than

one GND pad on a package then either the device needed multiple symbols

with a GND pin or the symbol needed pins called GND@1, GND@2 etc. Newer

versions of Eagle allow multiple package pads to be assigned to the same

symbol pin, which has a number of benefits for components that, for

example, have four GND pins in SO8 but only one in TO-92. However, it

breaks the "contact" data member in ULPs.

Rob Pearce wrote on Sat, 10 September 2016 17:49

On 10/09/16 13:12, Joop wrote:

 

In other words, the contact member, as opposed to the contacts()

iterator, only makes sense in the context of a single pad being

connected to a pin. This used to be the rule - if you wanted more than

one GND pad on a package then either the device needed multiple

symbols

with a GND pin or the symbol needed pins called GND@1, GND@2 etc.

Newer

versions of Eagle allow multiple package pads to be assigned to the

same

symbol pin, which has a number of benefits for components that, for

example, have four GND pins in SO8 but only one in TO-92. However, it

breaks the "contact" data member in ULPs.

I understand. The thing is, I didn't read carefully so I didn't notice

that

"contact" and "contacts()" where different things... my mistake.

With the contacts() iterator I should be able to write an ulp that does

what I what.

Thanks for pointing out.

--

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

Rob Pearce wrote on Sat, 10 September 2016 17:49

On 10/09/16 13:12, Joop wrote:

 

In other words, the contact member, as opposed to the contacts()

iterator, only makes sense in the context of a single pad being

connected to a pin. This used to be the rule - if you wanted more than

one GND pad on a package then either the device needed multiple

symbols

with a GND pin or the symbol needed pins called GND@1, GND@2 etc.

Newer

versions of Eagle allow multiple package pads to be assigned to the

same

symbol pin, which has a number of benefits for components that, for

example, have four GND pins in SO8 but only one in TO-92. However, it

breaks the "contact" data member in ULPs.

I understand. The thing is, I didn't read carefully so I didn't notice

that

"contact" and "contacts()" where different things... my mistake.

With the contacts() iterator I should be able to write an ulp that does

what I what.

Thanks for pointing out.

--

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

Done. I wrote myself an ulp that searches in the schematic for a certain

pin.

It requires two parameters, a part number (e.g. IC308) and a pad name.

If the combination of the two parameters exists, it opens that sheet,

centers to the pin, zooms in and highlights the net connected to that pin.

Works like a charm.

--

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

On 09.09.2016 19:35, Joop wrote:

I have a (system on a) module with 200 pins.

In the library, I divided these pins over 7 symbols in the device.

Those symbols are all in different schematic sheets. There are 15 sheets

so it's impossible to remember where is what.

 

Sometimes I need to find a certain pin of this module but I don't remember

on

which sheet it is.

My question is, is there a way to find out? I tried "run find" but it

doesn't offer what I'm looking for.

I use "run find pad " if you know the symbol pin

name, but you also have to include an optional hidden @ extension in

this name. Maybe the find ulp should be modified to ignore this extension.

Morten Leikvoll wrote on Mon, 12 September 2016 10:16

I use "run find pad <padname>".

That doesn't work for me:

/data/novazembla/Eagle-660/ulp/find.ulp(1138):

Multiple contacts on pin, use contacts() instead

Morten Leikvoll wrote on Mon, 12 September 2016 10:16

You can also use "run find pin <pinname>" if you know the symbol pin

name,

I don't know that, that's the problem.

Also, it's impossible for an algorithm to find the right pin if you don't

provide

at least two parameters. How else to solve the problem when two instances

have the same pad name?

Anyway, it's solved now, my new ulp works fine.

Thanks to everybody for helping.

--

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

On 12.09.2016 12:50, Joop wrote:

Morten Leikvoll wrote on Mon, 12 September 2016 10:16

I use "run find pad <padname>".

 

That doesn't work for me:

 

/data/novazembla/Eagle-660/ulp/find.ulp(1138):

 

Multiple contacts on pin, use contacts() instead

Ah! I remember that bug. It should have been fixed in lastest beta, but

if you look back in some old posts (by me), the bugfix to the find.ulp

script is posted there.

The problem was the ulp was not updated after eagle started to support

symbols with merged pads.

On 12.09.2016 13:46, Morten Leikvoll wrote:

On 12.09.2016 12:50, Joop wrote:

Morten Leikvoll wrote on Mon, 12 September 2016 10:16

I use "run find pad <padname>".

 

That doesn't work for me:

 

/data/novazembla/Eagle-660/ulp/find.ulp(1138):

 

Multiple contacts on pin, use contacts() instead

 

Ah! I remember that bug. It should have been fixed in lastest beta, but

if you look back in some old posts (by me), the bugfix to the find.ulp

script is posted there.

The problem was the ulp was not updated after eagle started to support

symbols with merged pads.

Just to help you out, this was posted back in April, after initially

pointing at the bug in Dec 2015.

-

Since this is a very easy fix and hasnt been fixed on 7.5.3 beta, I will

help you:

On line 1138,1139 of the original find.ulp:

1138:if (P.contact) {

1139:if (P.contact.name == Find) {

Replace this with:

1138:P.contacts(C) {

1139:if (C.name == Find) {

And this will work also with symbols having multiple pads assigned to a pin.

-