Bug with Renumber Parts?

On 8/19/2015 8:03 PM, Brendon Meyer wrote:

Really sorry if this question has come up before, I haven't found an

answer from googling and general searching so here it is ...

 

Version 7.3.0 for Mac OS X (64 bit)  Professional Edition

 

Not sure if this is a bug/feature or something that I'm just doing plain

wrong.

When I'm using the renumber parts, it actually doesn't appear to work

when you have multiple modules.

 

So, for example, I create a master sheet, and inside that, I create say

two modules - one called CPU and one called MEMORY (which Eagle then

goes and tacks on a '1' to the end of the name to form 'CPU:1' and

'MEMORY:1' (as the logical sheet numbers inside those modules).

If you try to renumber the parts in any sub module, or for that matter

even from the master/root sheet, you it just plumb doesn't work and I'm

at a loss to work out WHY.

The renumber.ulp has not been reworked to be able to handle modules so

as of this moment it doesn't work in this scenario. Nothing you've done

wrong, the ULP just doesn't support it at this moment.

Best Regards,

Jorge Garcia

CadSoft Guest wrote:

 

The renumber.ulp has not been reworked to be able to handle modules so

as of this moment it doesn't work in this scenario. Nothing you've done

wrong, the ULP just doesn't support it at this moment.

 

Best Regards,

Jorge Garcia

 

Hello Jorge, I hope you are doing well.

It's not the first time that an ULP stopped working.

Why is Cadsoft not maintaining the ULP's which come preinstalled with Eagle?

Either, remove them or update them before publishing a new version of Eagle.

This gives a very amateurish impression.

Kind Regards,

Joop

Thanks for the reply Jorge. 

Good to know that I'm not doing anything completely stupid. 

The comment that 'Joop' had though is quite appropriate.  If there is something that is broken, then it probably should appear in the release notes somewhere. 

I was scratching through those and it didn't immediately jump out at me.  Not sure if you're representing Eagle/Element14 or not, but if you are, then it probably does warrant a note to save someone else the wasted time of trying to solve the insolvable - I banged my head against it for the better part of two days before biting the bullet and asking on a forum. 

/BGM

Hello Jorge, I hope you are doing well.

 

It's not the first time that an ULP stopped working.

Why is Cadsoft not maintaining the ULP's which come preinstalled with

Eagle?

Either, remove them or update them before publishing a new version of

Eagle.

This is a bit of catch-22. Not everyone is using the hierarchical

feature of EAGLE, so if we remove it we eliminate functionality that

they had before even if it's not fully up to date with the current

release. So removing them is not a good option.

With more man power and some relaxed deadlines updating every affected

ULP would be the ideal solution, but we don't have the resources or the

time due to the demands of our parent company.

I think the most reasonable solution for the time being is to note which

ULPs don't support what new feature and have that in the documentation.

I'll bring this up to the attention of our devs and management and see

what wee can do.

Best Regards,

Jorge Garcia

CadSoft Guest wrote:

... due to the demands of our parent company.

This is very bad news. Is the Cadsoft team still happy with the aquisition by Farnell?

On 8/24/2015 2:58 PM, Joop14 wrote:

CadSoft Guest wrote:

 

... due to the demands of our parent company.

 

This is very bad news. Is the Cadsoft team still happy with the

aquisition by Farnell?

Hi Joop,

I can only speak for myself. In general, I think the acquisition has

been positive. EAGLE has grown a lot since the acquisition and for the

most part we are allowed to run close to the way we did before.

But like any acquisition, there are new factors that create difficulties

and pressures that weren't there before. It just comes with the

territory. We are the first software company Farnell owns and there is a

large learning curve when you are used to selling physical hardware to

now selling software and the differences between the two types of

products. I hope things will get better as time goes on.

We are just going to keep doing the best work we can and make EAGLE the

best program it can be with the resources we have and may have in the

future. I feel good working here and look forward to contributing as

much as I can.

hth,

Jorge Garcia

Am 24.08.2015 um 18:05 schrieb Jorge Garcia:

With more man power and some relaxed deadlines updating every affected

ULP would be the ideal solution, but we don't have the resources or the

You released V7 more than one year ago, and there are still no resources

left to repair the ULPs you broke? Oh dear!

time due to the demands of our parent company.

As we learned, this demand is called "licensing". Are you really

concentrating all your resources on this one again? Oh dear!

I think the most reasonable solution for the time being is to note which

ULPs don't support what new feature and have that in the documentation.

Yes, this would be fine. Leave the ULPs non-functioning as they are, but

document it. No need to touch them ever again. Oh dear!

On 8/25/2015 1:29 PM, René König wrote:

Am 24.08.2015 um 18:05 schrieb Jorge Garcia:

With more man power and some relaxed deadlines updating every affected

ULP would be the ideal solution, but we don't have the resources or the

 

You released V7 more than one year ago, and there are still no resources

left to repair the ULPs you broke? Oh dear!

There's 100+ ULPs that ship with EAGLE, there's a lot to keep track of

there. They're technically not broken, they just can support a new

feature that was added to EAGLE after the ULP was created.

time due to the demands of our parent company.

 

As we learned, this demand is called "licensing". Are you really

concentrating all your resources on this one again? Oh dear!

That's a pretty narrow definition. We are not working on licensing

again, I think management learned the consequences of such a "feature".

It was a painful lesson for sure, but I'm glad it's been done and proven

to fail so that it is hopefully never brought up again.

Demands come in various forms. Anyone who has ever been an employee at

large company is familiar with the ideas of a deadlines and sales

targets and how much pressure these can exert. That was more along the

lines I was thinking when I wrote the comment.

I think the most reasonable solution for the time being is to note which

ULPs don't support what new feature and have that in the documentation.

 

Yes, this would be fine. Leave the ULPs non-functioning as they are, but

document it. No need to touch them ever again. Oh dear!

They need to be improved and corrected for sure, but as a temporary

measure it's the best I can offer for now.

hth,

Jorge Garcia

Hi Jorge Garcia. 

I've just spent a day going through the renumber and trying to familiarise myself with the LP ...

Fix is probably a bad word for the 'renumber' ... a complete re-write is going to be needed as you need to educate it with the concept of a hierarchy ... right now, it thinks the world is flat and that just *isn't* the case with 7.x.x as far as I can see. 

This I think is going to be a hell of a lot more complicated that it first appears as you are not going to get any help from the UL from what I can see.  Single dimensioned arrays - no pointers, not real complex data types ... yeah ... dark ages <sigh> (yes, I've been 'doodling' with trying to fix it). 

In the standard freeware version of Eagle as you have a single sheet and no modules (that I'm aware of), no module qualification is necessary in the names.  All devices are therefore going have a flag unqualified name of 'IC<n>', 'R<n>', 'C<n>' and so forth. 

Current renumber (renumber-sheet.ulp) seems to handle that just fine - it can handle a flat earth. 

The moment you start adding modules though your data structures change so what we're now looking at is something that appears as:

<module><sheet#><NAME> ..

The interesting part is what happens with the name... 

In a multi-module your standard part is going to look something like:

[[<MODULE><#>]:..]:R<n>

(Submodules appear as just additional prefixes - e.g. FRED1:SUBMODULE1:SUBSUBMOD1:IC1)

The current code just doesn't handle that at all. 

Now, in so far as I can tell, the whole process basically loads everything into a large flat array and then sorts based on X(1) <-> X(2) ... or Y(1) <-> Y(2) depending on user choice.  The sort part itself doesn't do any renumbering but what it does is to generate a series of commands that will do the work - as per this bit of code. 

void Rename(int x, int y, string Old, string New) {

  // Generates the EAGLE command necessary to change element name Old to New

  //sprintf(c, "Name '%s' (%d %d);#297\n", New, x, y);

  sprintf(c, "NAME '%s' '%s';#298\n", Old, New); // 2013-08-19

  Cmd += c;

  return;

}

As I mentioned, I actually started with a view of trying to fix it ..(based on the assumption that as this has been broken for so long now, CadSOFT probably isn't going to be fixing it any time soon) and then rapidly threw my hands in the air while banging up against the limitations of UL ...

At that point, so I did the semi-sensible thing ...I exported it and and then got Perl deal with it...

What *I've* now managed to achieve is I replaced the standard renumber with a very simple wrapper that exports the entire schematic (via a *.allparts) and then invoked Perl to take that flat export and generate a series of renumber instructions (the Perl code right now builds a tree and then progressively walks up and down the tree)

If I paste those generated commands back in one at a time, it *sort* of works.... 

Right now, only basic sequential renumbering - nothing intelligent like left-to-right vs top-to-bottom. 

I need to clean it up a hell of a lot more than the state it's presently in and that includes a loopback where the wrapper will take the command file generated by Perl and then soak that back in for execution.  Clunky but it may do the business. 

Now that sort of workaround-in-progress aside for my particular problem ... the release notes thing is a *MUST* ... if something is broken - *ESPECIALLY* in the version that I've paid top dollar for - I *REALLY* want to know about it. 

My $0.02 worth ...

/BGM

P.S. If anyone is interested (CadSOFT?) I may post the final code.  Right now, it needs a lot of work to support different sort orders such as left-to-right, top-to-bottom, but also things like main component locality (.e.g resistors/capacitors near IC#2 so they would be numbered 201, 202, 203, etc) but this is when I get a bit more time.  Right now, just trying to get the basics working properly first and then I should be able to start adding the bells and whistles. 

I realy would like to have a solution to be able to renumber components in modules.

/IHA