Adding scripted generic connector symbols as discussed in issue #1451

[poeschlr]

This adds the script generated connector symbols as discussed in #1451
All symbols are added from 1 to 40 pins per row except for screw terminals. These are added from 1 to 20 pins.

[poeschlr]

Travis complains about missing datasheet links and about my footprint filters for the dual row connectors.
The dual row connector filter needs an underline to ensure that the it filters by the number of rows.
A datasheed does not make sense for a generic symbol.

[jkriege2]

Hi!

first for reference a screenshot of the old symbols:

a few comments from my side on the new ones:

1. you can add K ~ as datasheet, which will be ignored, but Travis does not complain anymore
2. The screw terminals, male+female connectors had a larger pitch on purpose ... mostly to make them stand out (I would say they are mostly used for power-supply connectors ... but I'm not sure whether that is really required ... but I liked them that way).
3. The male/female connectors: I would remove the box and make the half-circle and filled rectangle a bit larger. The old ones had the nice property that they can be paired. Also without the box they follow the IEC recommendation for a male/female connector symbol.
   
4. I think the 2x01 variants with pins 1&2 can be summariozed into a single symbol.

Best,
JAN

[jkriege2]

Also for ref the discussions on the screw terminals and the male/female connectors:
#719
#816

[poeschlr]

When do you have Male and female connectors connected on the same board?
I could see them for use cases where you want to communicate that it is a male/female pcb connector. (In that case only the male or female connector is on the board. The other connector either on a cable or on a separate board,)

[poeschlr]

Regarding footprint filters:
Currently pin headers and socket strips are in libs that do not start with Connector. Should i add a separate filter for them or do we move them into a lib starting with Connector?
(Connector does not necessary need to be on the beginning of the lib name for my filter to find it. But i think in this case if we move them the new lib name should start with Connector.)

[poeschlr]

Ok i removed the rectangle from the male and female versions. (Even though i do not understand the usecase for it.)

I also removed the duplicated 02x01 connectors and changed the datasheet filed to equal ~ as requested.

[poeschlr]

Travis now complains about the 1 pin male connector because it believes the artwork used for the male symbol is the outline of the symbol.
It also still throws the warning about the footprint filter. (I need an underscore there to ensure that it filters correctly.)

[evanshultz]

This look very nice!

If there's a script, should it be imported somewhere once we've finalized the design?

I also don't like this symbol change. Male and female that mate are on different boards, and in the case where they aren't why do we care if the symbols can snuggle together so much? I vote to go back.

I also think we go for Connector_ footprint library to group things together. Connector_Pin_Headers, Connector_Terminal_Blocks, etc.

[poeschlr]

If there's a script, should it be imported somewhere once we've finalized the design?

I will add it to the other generator scripts that live in the kicad-library-utils repo.
I also wrote a more powerful lib that should make it easier to script symbols. (Similar to the footprint-generator scripts by @pointhi.)
Only thing i still need to add is support for text and maybe parsing of libs. The later would remove the need to manually insert the generated symbols into an existing lib.

[t3hcatpaw]

@poeschlr

"When do you have Male and female connectors connected on the same board?"

Just for the record, it might seem somewhat unusual but sometimes it does happen lol

Also, these ERNIs are an example application for the connector symbols you just created.

[evanshultz]

The question here is having male and female symbols that mate together. Having male and female together is common and having, but having a mating pair of male/female connectors on the same board is odd.

[poeschlr]

It looks like the naming scheme for dual row connectors is not as consistent as i thought.
I will need at least two footprint filters to catch both options i found so far.

New filter options.

• Connector*:*2x??x*mm*
• Connector*:*2x???Pitch*

In my new naming convention i will fix one way to name connector footprints.

For single row connectors i might use

• Connector*:*_??x*mm* (Should catch most of the currently available footprints.)
• Connector*:*1x??x*mm* (Future proofing.)

Footprint filter feature: #1170

[t3hcatpaw]

I have to admit, it was not the best idea I've ever had, but that's exactly what I did :D
Just in case a subsystem wouldn't work I could separate them populate the connectors without having to re-design the whole board
EDIT: But I do agree that this is not a standard use case. If you employ such a solution you probably (a) don't need to remind yourself and (b) don't want to show it to anyone else anyway.

[t3hcatpaw]

Travis now complains about the 1 pin male connector because it believes the artwork used for the male symbol is the outline of the symbol.

Maybe if you change the rectangles from e.g.
S 34 5 0 -5 1 1 6 F
to
S 32 3 2 -3 1 1 10 F
the symbols look the same except for the slightly more rounded edges but at least that should eliminate the outline error thrown by Travis:

[poeschlr]

I'm not gonna hack my way around travis. Travis is correct in this case because the symbols without outline violate KLC. (If anything it should complain about all female and male symbols.)

[poeschlr]

@jkriege2 or @evanshultz i think this is now ready for review.

Edit: The footprint filters are tested in a nightly from 4 days ago. They work with the current naming scheme for connectors.

[t3hcatpaw]

Travis is correct in this case because the symbols without outline violate KLC.

Oh okay, that's my fault then, sorry. I've known about the KLC requiring an outline width of 10 mils but didn't realize that the actual presence of an outline body is required

[poeschlr]

For symbols like this i think it is required (by KLC). Exceptions are symbols like a diode or a single transistor. (At least this is my interpretation.)

[t3hcatpaw]

Thanks for the clarification :)

[evanshultz]

@poeschlr

If we were to merge, does the FPfilter work in 4.0.7? It doesn't work in 4.0.6, but I assume your comment about testing in nightly above is to confirm 4.0.7 will be OK.

Also, right now we have lots of compatible parts in Pin_Headers and Socket_Strips and a number of other libs. Thost footprints wouldn't get matched by CvPcb even if we re-named the libs since fp-lib-table never gets updated from GitHub. Is this a problem since the footprint libs have already been tagged for 4.0.7? For me, it seems we will make life harder since the footprint libs aren't also updated yet. Once option would be to simplify (or remove?) the FPfilter for these parts now and then update them post-4.0.7 once the footprint libraries have been renamed to all start with Connector.

BTW, while there's a huge number of symbols they look very nice and I don't see any other problems stopping them from being merged. Thank you!

[poeschlr]

The filter does not work in any stable release.
The old filter only resulted in a small number of suggested footprints (only pin headers and socket strips.)

For now i will add the old filters back to the symbols where appropriate. This way the pin headers are filtered in all versions of kicad, but all other connectors only in nightly.
In other words: The functionality for the stable release does not change but nightly gets the benefit of getting all connector footprints that match the row and pin number of the symbol. (At least for the correctly named footprints.)

[poeschlr]

@evanshultz Footprint filters are fixed now.

[evanshultz]

@poeschlr Great! Looks good and works in 4.0.6, if that matters.

[poeschlr]

Thanks for all the input i got. And thanks for the quick merge. This was truly a team effort.

[evanshultz]

Since this question spans multiple footprint repos and is related to this topic, perhaps we continue the discussion here.

How to name the footprint libs? Something like this:

• Connector_Audio
• Connector_Card
• Connector_DB
• Connector_DIMM
• Connector_Edge
• Connector_Ethernet (or Connector_Network)
• Connector_FFC_FPC
• Connector_HDMI
• Connector_Memory
• Connector_Pin
• Connector_Power
• Connector_Socket
• Connector_Tab (or Connector_Blade)
• Connector_Terminal_Block
• Connector_USB
• Connector_Wire

I dislike having a generic Connector.pretty repo, since it will likely turn into a wasteland, but there are so many connector types it may be the best way to go.

We could use Conn instead of Connector to make them shorter.

This is just a start, and having a table to better flesh out the purpose of each library would be required. But we have to get the ball rolling somehow. If you don't object this start, I'll create a new issue (maybe in Connectorrs.pretty repo) to hash this out.

[poeschlr]

I thought about the same thing today. I think we should move this to a issue though. Otherwise it will be missed by someone. (Should be a new RFC issue i think)

Short note: I like Connector_Network more than Connector_Ethernet
And another note: For connectors manufacturer specific libs make sense. (I don't think you wanted to imply to remove them, just making sure everyone is on the same page here)

I would also keep the name Connectors instead of Connector. (Otherwise all current repos need to be renamed again.)

[t3hcatpaw]

Thanks for the new connectors! Great work!