Search/Find an element, how???

You should try xfind.ulp. Bind it to Ctrl-F and life just became a little easier.

http://www.cadsoftusa.com/downloads/file/xfind.ulp

Eric

Thanks!

What I don't understand however, is why Cadsoft is not able to update / maintain their ulp's. Many of them need improvement, or they stopped working since version 7.

Instead of adding connections with online parties, Cadsoft should work on the core of Eagle and their ulp's.

For example:

- board mirror view

- exceptions for thermals in polygons

- check used libraries / report missing libraries and inconsistencies during "update from libray" something like: Eagle library check

- restrict layers for inner layers

- LTSpice export on Linux

- locale for printf() in ULP

- after smash, properties of names and values are not updated from library anymore

- save last modification date-time stamp in brd and sch file

- X-ref for busses

Wake-up Cadsoft team!

On 10/29/2015 9:55 AM, Joop14 wrote:

Thanks!

 

What I don't understand however, is why Cadsoft is not able to update /

maintain their ulp's. Many of them need improvement, or they stopped

working since version 7.

 

Instead of adding connections with online parties, Cadsoft should work

on the core of Eagle and their ulp's.

For example:

 

- board mirror view

This is possible with the mirror-board.ulp that ships with EAGLE

- exceptions for thermals in polygons

There's a couple of ways to handle this already. For example within the

library you can specify if certain pads should always use solid

connections by unchecking the thermals box for the pad. The downside of

that is that the pad always needs to be treated the same way.

Another way to do that would be a polygon within a polygon, with the

internal polygon having thermals off. Neither way is super nice but they

work.

- check used libraries / report missing libraries and inconsistencies

during "update from libray" something like: Eagle library check

(http://www.teuniz.net/eagle/eaglelibcheck/)

+1, This one has gotten some movement lately but I wasn't involved in

the final determination of EAGLE's roadmap so I don't know if that's in

there.

- restrict layers for inner layers

+1, I personally think it would be cleaner if polygons could assume some

sort of restrict property that way you wouldn't need a separate layer.

- LTSpice export on Linux

+1

- locale for printf() in ULP

Not sure I understand this one, could you elaborate?

- after smash, properties of names and values are not updated from

library anymore

I don't think this would be a good idea. Generally if you are assigning

values in the schematic or board, you would not want a library update to

change them. Could create confusion, unless I'm misunderstanding what

you're asking for.

- save last modification date-time stamp in brd and sch file

This is already possible with the >LAST_DATE_TIME text variable. It

updates every time you save the file, or are you asking for something else.

- X-ref for busses

This one is odd to me as well. In the case of a single net the XREF

makes sense since you want to easily find other instances of that net. A

bus however is a collection of nets, so I find an X-ref for a bus less

useful since it's doesn't aid in finding a particular signal.

Additionally, Bus labels can get pretty long so I'm sure there are cases

where this would be inconvenient.

The idea behind these comments is to show that if some form of

workaround exists even if it's not the most convenient that usually

makes a given feature medium to low prio. In the case of others I

totally agree that we need them but determining priorities is very

difficult because everyone has a different opinion and some of the

heaviest opinions aren't coming from technical staff.

I'm happy to see that first time ever we are really adding features

progressively throughout a major version, instead of having the lions

share up front and then sticking to bugfixes and minor tweaks as a

version aged. Maybe some of the new stuff isn't all up your alley, but

other users do find it useful.

Thank you for your input we really appreciate.

Best Regards,

Jorge Garcia

Hello Jorge, I hope you are doing well.

First of all, thank you for responding, I appreciate it.

CadSoft Guest wrote:

 

On 10/29/2015 9:55 AM, Joop14 wrote:

Thanks!

 

What I don't understand however, is why Cadsoft is not able to update /

maintain their ulp's. Many of them need improvement, or they stopped

working since version 7.

 

Instead of adding connections with online parties, Cadsoft should work

on the core of Eagle and their ulp's.

For example:

 

- board mirror view

This is possible with the mirror-board.ulp that ships with EAGLE

I don't like the fact that mirror-board act on the actual content of the board.

Also, all coordinates are wrong when using this ulp to mirror the board.

- exceptions for thermals in polygons

There's a couple of ways to handle this already. For example within the

library you can specify if certain pads should always use solid

connections by unchecking the thermals box for the pad. The downside of

that is that the pad always needs to be treated the same way.

 

Another way to do that would be a polygon within a polygon, with the

internal polygon having thermals off. Neither way is super nice but they

work.

I'll try that.

- locale for printf() in ULP

Not sure I understand this one, could you elaborate?

When you print the value of a float or double in a formatted string with printf(), the decimal separator will

be a dot or a comma, depending on the locale settings of the pc i.e. in the US it will print 1.23 and in most

countries in Europe it will print 1,23. This causes big problems, for example when printing values to a file

in csv format.

- after smash, properties of names and values are not updated from

library anymore

I don't think this would be a good idea. Generally if you are assigning

values in the schematic or board, you would not want a library update to

change them. Could create confusion, unless I'm misunderstanding what

you're asking for.

When I change a library (for example, I change the text size of the name and value) and then I do an

update from library in a schematic, size of text of name and value of all instances will be updated, apart

from the ones that are smashed. Why?

Smash should only detach the name and value labels from the element for their position.

Appearantly, it looses the ability to get updated from library.

- save last modification date-time stamp in brd and sch file

This is already possible with the >LAST_DATE_TIME text variable. It

updates every time you save the file, or are you asking for something else.

Eagle uses the date/time when it was last saved, not necessarily modified.

The difference is subtle but important.

For example, when I copy the file to another destination, the save date/time in Eagle changes

but there are no modifications compared with the original.

Another example, I send a copy of a schematic to somebody via email.

He receives the schematic and saves it on his pc. The save date/time will be different despite the file

has not been modified.

What I would like to see is that Eagle stores the last modification date/time stamp in the schematic/board

files. This will make it more clear if a file has been altered or not.

- X-ref for busses

This one is odd to me as well. In the case of a single net the XREF

makes sense since you want to easily find other instances of that net. A

bus however is a collection of nets, so I find an X-ref for a bus less

useful since it's doesn't aid in finding a particular signal.

Additionally, Bus labels can get pretty long so I'm sure there are cases

where this would be inconvenient.

As an example, I have an MCU with an 8-bit parallel databus in sheet 4. The datalines are attached to a bus

with the name "databus". The bus suddenly stops at the border without any indication.

In sheet 12 I draw the same bus with name "databus" where the datalines are connected to another chip.

After printing the schematic, when reading sheet 4, how does one know where to find the other end of the bus?

What about the broken IDF export?

http://www.element14.com/community/thread/43949/l/idf-export-broken?displayFullThread=true

Kind Regards,

Joop

Hi,

CadSoft Guest wrote:

On 10/29/2015 9:55 AM, Joop14 wrote:

Thanks!

What I don't understand however, is why Cadsoft is not able to update /

maintain their ulp's. Many of them need improvement, or they stopped

working since version 7.

Instead of adding connections with online parties, Cadsoft should work

on the core of Eagle and their ulp's.

For example:

- board mirror view

This is possible with the mirror-board.ulp that ships with EAGLE

I don't like the fact that mirror-board act on the actual content of the board.

Also, all coordinates are wrong when using this ulp to mirror the board.

Me too, when I need a mirrored view of a board, it's only because I have a board on my desk, and need to find a part or a net to put an oscilloscope on it. I don't want to change my board , certainly not !!

I just need a mirrored view of it, simply because in real life, after designing a board virtually on a computer, I get a real one in my hand, I need to test it and sometime looking on the top is not enough !

- X-ref for busses

This one is odd to me as well. In the case of a single net the XREF

makes sense since you want to easily find other instances of that net. A

bus however is a collection of nets, so I find an X-ref for a bus less

useful since it's doesn't aid in finding a particular signal.

Additionally, Bus labels can get pretty long so I'm sure there are cases

where this would be inconvenient.

No, I think the Xref for bus is to locate the bus.

It should work like net, and locate the position of the other XREF of the same bus (same bus = same bus name).

Guillaume.

On 30/10/15 11:51, Guillaume barrey wrote:

Me too, when I need a mirrored view of a board, it's only because I have

a board on my desk, and need to find a part or a net to put an

oscilloscope on it. I don't want to change my board , certainly not !!

I just need a mirrored view of it, simply because in real life, after

designing a board virtually on a computer, I get a real one in my hand,

I need to test it and sometime looking on the top is not enough !

I which case what I do is print the bottom side, mirrored, to a PDF.

On 30/10/15 11:51, Guillaume barrey wrote:

Me too, when I need a mirrored view of a board, it's only because I have

a board on my desk, and need to find a part or a net to put an

oscilloscope on it. I don't want to change my board , certainly not !!

I just need a mirrored view of it, simply because in real life, after

designing a board virtually on a computer, I get a real one in my hand,

I need to test it and sometime looking on the top is not enough !

 

I which case what I do is print the bottom side, mirrored, to a PDF.

It's what I do now but tell me how to you use the 'show @' command on printed pdf, how you follow net, how do you manage to highlight a net... I tried to click with my pen on the paper but nothing happen !!!!!

More seriously... if some people ask this feature it's is not just for been annoying...(i know I'm no the only one to ask this...) maybe it because it would be easier to do some task....

Guillaume.

>> >

- board mirror view

 

This is possible with the mirror-board.ulp that ships with EAGLE

I don't like the fact that mirror-board act on the actual content of the

board.

Also, all coordinates are wrong when using this ulp to mirror the board.

 

This is true, a better bottom view functionality has been requested and

is on the wish list, but for now it's considered low prio because of

what I mentioned before.

- locale for printf() in ULP

 

Not sure I understand this one, could you elaborate?

When you print the value of a float or double in a formatted string with

printf(), the decimal separator will

be a dot or a comma, depending on the locale settings of the pc i.e. in

the US it will print 1.23 and in most

countries in Europe it will print 1,23. This causes big problems, for

example when printing values to a file

in csv format.

The complexities of supporting multiple languages ;). The CSV(character

separated values) files that EAGLE generates by default use semicolons

as the delimiter instead of commas probably for that same reason.

As long as you let the semicolon be used as the delimiter then

everything should work.

- after smash, properties of names and values are not updated

from

 

library anymore

 

I don't think this would be a good idea. Generally if you are

assigning

 

values in the schematic or board, you would not want a library update

to

 

change them. Could create confusion, unless I'm misunderstanding

what

 

you're asking for.

When I change a library (for example, I change the text size of the name

and value) and then I do an

update from library in a schematic, size of text of name and value of

all instances will be updated, apart

from the ones that are smashed. Why?

Smash should only detach the name and value labels from the element for

their position.

Appearantly, it looses the ability to get updated from library.

Smash basically removes all control from EAGLE and it gives it to you.

However you leave a text after it is smashed that is how EAGLE is going

to leave it when you do the update. It's the safest move.

- save last modification date-time stamp in brd and sch file

 

This is already possible with the >LAST_DATE_TIME text variable. It

 

updates every time you save the file, or are you asking for something

else.

Eagle uses the date/time when it was last saved, not necessarily

modified.

The difference is subtle but important.

For example, when I copy the file to another destination, the save

date/time in Eagle changes

but there are no modifications compared with the original.

Another example, I send a copy of a schematic to somebody via email.

He receives the schematic and saves it on his pc. The save date/time

will be different despite the file

has not been modified.

What I would like to see is that Eagle stores the last modification

date/time stamp in the schematic/board

files. This will make it more clear if a file has been altered or not.

Putting is in as an enhancement request.

- X-ref for busses

 

This one is odd to me as well. In the case of a single net the XREF

 

makes sense since you want to easily find other instances of that net.

A

 

bus however is a collection of nets, so I find an X-ref for a bus

less

 

useful since it's doesn't aid in finding a particular signal.

 

Additionally, Bus labels can get pretty long so I'm sure there are

cases

 

where this would be inconvenient.

As an example, I have an MCU with an 8-bit parallel databus in sheet 4.

The datalines are attached to a bus

with the name "databus". The bus suddenly stops at the border without

any indication.

In sheet 12 I draw the same bus with name "databus" where the datalines

are connected to another chip.

After printing the schematic, when reading sheet 4, how does one know

where to find the other end of the bus?

Putting in the enhancement request.

 

What about the broken IDF export?

 

http://www.element14.com/community/thread/43949/l/idf-export-broken?displayFullThread=true

Last I spoke to the Developers this was going to be in EAGLE, but I see

that in V7.4.0 the ULP has not been updated. I don't think the Python

script will be included but the improved ULP should have been brought

into the EAGLE distribution. I'll follow up and see what happened.

Best Regards,

Jorge Garcia

Thank you Jorge, for bringing this under the attention (again) of the developers.

It's very much appreciated.

CadSoft Guest wrote:

- locale for printf() in ULP

 

Not sure I understand this one, could you elaborate?

When you print the value of a float or double in a formatted string with

printf(), the decimal separator will

be a dot or a comma, depending on the locale settings of the pc i.e. in

the US it will print 1.23 and in most

countries in Europe it will print 1,23. This causes big problems, for

example when printing values to a file

in csv format.

The complexities of supporting multiple languages ;). The CSV(character

separated values) files that EAGLE generates by default use semicolons

as the delimiter instead of commas probably for that same reason.

 

As long as you let the semicolon be used as the delimiter then

everything should work.

Unfortunately, this is not the case.  Let's do an example. Let's assume for a second that all programs interpret the decimal separator in csv files according to the locale (which is not always the case by the way).

Let's say we are in an european office and we export some Eagle board data by using an ulp.

Values are written as floats, let's say wit a precision of three decimals. They will be printed with a comma as a decimal separator.

Everything seems to work fine. Also some third party software that reeds our exported data.

Now we send this exported data to an office in the US. Guess what's going to happen?

Exactly, the software at the other end of the ocean will interpret the comma as a grouping charachter, effectively ignoring it.

As a result, all values will be multiplied with thousand!

To avoid mistakes, a ulp should be able to be in control about the locale or otherwise to make sure that with printf() the decimal separator charachter is defined, independent from the locale settings of the pc.

Kind Regards,

Joop

 

Unfortunately, this is not the case.  Let's do an example. Let's assume

for a second that all programs interpret the decimal separator in csv

files according to the locale (which is not always the case by the way).

Let's say we are in an european office and we export some Eagle board

data by using an ulp.

Values are written as floats, let's say wit a precision of three

decimals. They will be printed with a comma as a decimal separator.

Everything seems to work fine. Also some third party software that reeds

our exported data.

Now we send this exported data to an office in the US. Guess what's

going to happen?

Exactly, the software at the other end of the ocean will interpret the

comma as a grouping charachter, effectively ignoring it.

Hi Joop,

I disagree, both Excel and LibreOffice allow you to specify what the

delimiter should be. You can select tabs, whitespace, commas,

semicolons, etc.

That's just my opinion though.

Let me know if there's anything else I can do for you.

Best Regards,

Jorge Garcia