Edit part name

[Jim Young]

I am starting the setup for a new board in OpenPnP and I'm running into this issue again. When I import my board file for placement data, it creates a new part for every component, even though many of them have the same value and will be sourced from the same feeder. In this case I want to rename one of the parts with a generic name, signifying its package and value and use it in the placement. I would then get ride of all the other parts with the same package and value. The problem is that the UI does not allow editing the part name. 

Is there some philosophical reason for this?

[Jim Young]

I see what the issue is, a part's name is its identifier, making it more difficult to delete or rename without dealing with any references to the part. One solution I found was to create a new part with the generic name and use it, later removing the other unreferenced parts.

[Wayne Black]

I run into this too. I use openpnp very infrequently and forget that the import function conjugates the part name and package/dimensions that dont fit already saved and edited packages with openpnp. Thus generating a new parts. Every time I do a new design in the pcb editor I forget to audit my components and set them corretly to prevent this. Its just easier for me just to just uncheck the auto part creation fx of the import utility and set the parts manually in the board placement list.

[Jim Young]

So, that's what the auto-part-creation checkbox does. If I leave it unchecked it only creates a single part per package/value?

[mark maker]

First, what import / E-CAD are you talking about?

I don't understand why this should happen. Each time you import from the E-CAD it should jump through the same hoops and create the same part identities. You just have to accept them as they are. If you start tinkering with them, then of course it will cause eternal problems down the road.

Why would you want to change them?

There is one issue that I'm aware of, namely that you used the .ulp import from Eagle and then later the direct .brd file Eagle import. The .brd import created the part-id as the combo of library id & package id & value, while the .ulp import left out the library id.

But in the current versions you should be able to disable that:

_Mark

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/de660329-3b81-4e9c-b8bc-545381a86159n%40googlegroups.com.

[Jim Young]

I'm importing an Eagle file that was exported from Diptrace. I have tried everything I could to get OpenPnP to accept a CSV file, but not matter how I format it or name the column row, it refuses to import. So, I just simply export my Diptrace file as an Eagle BRD file and that seems to work. The problem is that when I import the file for placement information it creates a part for EVERY component. The board I'm working on has 11 0805 110k resistors, so the import creates 11 individual parts, all with the same value. Since part is a property of feeder, and not the other way around, I'm not going to create a feeder for every part of the same value, that would be silly. So, I thought why not just rename one of the parts, with a generic name, and use that for all the 100k placements. Simple, yes? But no, it can't be done. The only remedy I've found is to create a new part and use that in my placements, deleting all the other parts created with the import.

[mark maker]

> so the import creates 11 individual parts, all with the same value.

Why would it do that? Are you saying the Eagle import is broken?

How do these part IDs look?

Or is it creating duplicates?

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/aedc7509-d8a2-4065-9713-301141399a35n%40googlegroups.com.

[Jim Young]

Seems broken to me. Since I'm exporting from Diptrace, it could be a problem with how Diptrace is creating the Eagle file. Here's a screenshot of all the 100nF parts the import created. It even made new packages for each individual part!

[Mark]

> it could be a problem with how Diptrace is creating the Eagle file

Looking at the code, I can guarantee that it is not OpenPnP doing that.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/0fa16f87-e261-464c-8bfd-6ff06588f9a7n%40googlegroups.com.

[Jim Young]

Yes, it looks like an issue with how Diptrace is converting to an Eagle file. I opened the BRD file in Fusion 360 and this is what it shows for the 100k resistors. A new package for each part.

Never the less, it still would be nice to be able to rename parts :-)

[Niclas Hedhman]

On 2023-03-27 20:24, Jim Young wrote:
> Yes, it looks like an issue with how Diptrace is converting to an
> Eagle file. I opened the BRD file in Fusion 360 and this is what it
> shows for the 100k resistors. A new package for each part.
>
> Never the less, it still would be nice to be able to rename parts :-)

I would simply use shell tools (sed or awk if it is text files, python
or something else if it is binary), in a script, to auto-mangle files
after the export. Much shorter turn-around and doesn't need to introduce
an unknowingly complex feature in OpenPnP.

Niclas

[Wayne Black]

Im using easyeda std edition. Mine is not an Openpnp issue and I didnt mean to imply it was.

In Easyeda the part package description includes the physical dimensions and produces a very long part name entry, ex;

1N4148W-G SOD-123 as intended turns out to be 1N4148W-G SOD-123_L2.8-W1.8-LS3.7-RD

What happens when Openpnp parses the pnp file, it correctly generates a new part 1N4148W-G SOD-123_L2.8-W1.8-LS3.7-RD

This is a housekeeping issue on my end when using Easyeda. Alot of the part library is user generated and there's all kinds of little issues. I'm too lazy to correct everything. My quick fix is to uncheck the add new part in the import fx and simply select the correct part already in my Openpnp parts list.

Fyi Other issues w the Easyeda generated pnp.csv file;

- .csv file is UTF-16LE encoding that chokes the Openpnp parser and needs to be resaved as UTF 8 or ANSI

- the '.csv' file uses a combination of [tab] and ["][tab]["] as delimiters

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/1684676866745d64356277a65b8dc62e%40hedhman.org.

--

Wayne Black

Owner

Black Box Embedded, LLC

black...@blackboxembedded.com

1.831.682.4964

[Mark]

> Yes, it looks like an issue with how Diptrace is converting to an Eagle file.

Are you sure there is no option to suppress that? I mean this is simply utter nonsense, even if they have some model discrepancy/data lost otherwise, this is simply no viable solution. The only "rational" reason I can think of is to keep customers from switching their designs to Eagle.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/cf0df078-361c-4a8b-bad4-1da963f7a2c0n%40googlegroups.com.

[Jan]

Hi Jim!
From what I'm reading the actual problem seems to be the .cvs importer.
Would you please take a look into the logs and check if there is
anything related? I know from importing Altium .csv data that the
importer itself in general works well. I can also see from studing the
code that there shall be messages in the logs...

Jan

>> https://groups.google.com/d/msgid/openpnp/de660329-3b81-4e9c-b8bc-545381a86159n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/de660329-3b81-4e9c-b8bc-545381a86159n%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com

> <mailto:openpnp+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/openpnp/aedc7509-d8a2-4065-9713-301141399a35n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/aedc7509-d8a2-4065-9713-301141399a35n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Mark]

The following would solve Wayne's problem, but not Jim's.

The clean solution in OpenPnP would be to hide the ID as is it done for all the other objects in OpenPnP, and use the Name instead. Part and Package already have the Named interface, it is simply not currently used.

Obviously such a rework would need to:

• Set all names to IDs on first use of getName(), this in turn
• Sets all names of existing and freshly imported Parts/Packages to IDs on first use
• Use getName() instead of getId() in all code that serves the UI (a lot of work)
• But still carefully keep using the ID whenever a reference is meant.
  

Using this pattern, you can rename Part or Package and still keep the ID that robustly references the part all the way back to the E-CAD. In subsequent imports, the Parts and Packages are still reliably re-identified and no duplicates created. But you get all the benefits of importing them when new, i.e. no danger of confusing parts in placements, no extra work. You would just rename the new Parts and Packages to your liking.

Keeping the full E-CAD identity is the only proper/professional way IMHO. Obviously this only holds true when the E-CAD actually export a stable, referencing ID. Diptrace 's unusable behavior, obviously, is not such a case.

A helper functions could even be written, that creates the names from the ID using some kind of pattern extraction.

I'm not saying I'm going to implement that, just saying what the proper way would be. 😁

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CABUTZN-XR0dE%2B6DubJUT6rpTRN6nK%2B%3DHJHHfRL-eHfAskJRJmQ%40mail.gmail.com.