Footprint duplication in Gencad export - proposed changes

[se...@malmoset.com]

Problem:
The gencad export duplicates every footprint regardless of the setting of the "Generate a new shape" option.

Cause:
In export_gencad_writer.cpp (hashFootprint around line 615), footprints are hashed to determine duplicates. The hashing has some limitations though. First off, it hashes the fields. Those will always be different, since it includes the reference. Even excluding the reference, they're usually different. Example: 0402 Capacitors. Many different capacitors, same footprint, but the export generates a footprint for each.

Next up, the GraphicalItems hashing. This can also be problematic because the lines around a footprint can end up saved in a different order, even if they came from the same library footprint. I'm not sure of the underlying cause here, but it breaks the hashing.

Solutions:

Easiest:
1. I think we should eliminate hashing of the fields (remove lines 617,618). I can't think of why this is useful.
2. For my use, I could also safely eliminate the hashing of graphical items (silk screen), since the differences aren't visible anyway. Others might disagree on this.

Thoughts:

Field hashing should probably always be removed. It essentially forces on the "UsePinNamesUnique" option.

1. The UsePinNamesUnique option provides a means to get individual footprints generated for everything. So, I don't see a big need for the hashing function to be super conservative. There's an easy way for a user to get a conservative output if they want it. Thus, I'd suggest removing both the field hash and the graphical hash.

2. The next possibility is to remove the field hash and to sort the lines of the graphical elements in such a way that they will always output in the same order and the hashes will be compatible. I've tried to come up with a sort method for this and haven't come up with one.

3. Add another option to the export called "Precise footprint comparison" or similar that enables the graphical hash. Turn it off by default.

I'm happy to produce patches for any of these options, just wanted to query the maintainers about what they think is the best approach before I built and submitted the patch.



Thanks,

Sean

[Seth Hillbrand]

The gencad export is lightly used so your input here is valuable. 

Does the gencad export provide a bom?  If so, maybe hashing value is useful.  But clearly hashing refdes is not. 

For the graphical items, I'd use a set to order them before hashing 

Seth

--
You received this message because you are subscribed to the Google Groups "KiCad Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to devlist+u...@kicad.org.
To view this discussion visit https://groups.google.com/a/kicad.org/d/msgid/devlist/e5d16250-a31d-4487-b3c5-2097347cae20n%40kicad.org.

[Sean Mollet]

1. No, it’s just an alternative PCB export.

2. I agree that’s the best approach, but I’m unsure of the best way to sort them. Each item has (for lines anyway, which I’d be fine with just doing this for lines and letting circles/elipses duplicate) a start point and an end point. So, we’re sorting a set of lines. Maybe just sort by PT_A.x, PT_A.y,PT_B.x,PT_B.y?

Sean

To view this discussion visit https://groups.google.com/a/kicad.org/d/msgid/devlist/CAFdeG-ozEv2f-GevF5sWP-gR8trbNLrODkbkysZ0rAY5MapJYQ%40mail.gmail.com.

[Seth Hillbrand]

The actual sort doesn't matter as long as it is consistent.  I would sort based on the elements being hashed .  You will need to fall back to UUID if all points are the same but that is ok because the hash doesn't care

To view this discussion visit https://groups.google.com/a/kicad.org/d/msgid/devlist/A9CE256D-8B63-4A7B-9BFA-D71ACFEBFF9D%40malmoset.com.