KLC: Relay naming convention

[antoniovazquezblanco]

Discussion originated in KiCad/kicad-footprints#1638

There seems to be multiple THT relay conventions for naming. In the relays folder I can see the following examples:

Relay_StandexMeder_DIP_HighProfile
Relay_SPST_Schrack-RT1-FormA_RM3.5mm
Relay_Socket_DPDT_Finder_96.12
Relay_1P1T_Panasonic_ADW11_FormA
Relay_1-Form-C_Schrack-RYII_RM3.2mm

It would be desirable to reach a consensus about relay naming and if necessary document it afterwards.

For the time being @evanshultz has given the following input:

One thing I don't like about this naming scheme is that it separates members of the same family. For example, if a family have 1FormA and 1FormC members they're potentially spaced apart.

I am also thinking about the 1P1T vs 1FormC notations. I personally prefer to see the number of poles an throws but relay notation includes more information (normally open/closed) so maybe we should drop the usage of both notations in favour of the form notation?

Current proposal based on that input:
Relay_[Manufacturer]_[Model]_[poles]Form[A|B|C]_[Options]
RelaySocket_[Manufacturer]_[Model]_[poles]Form[A|B|C]_[Options]

[poeschlr]

I would follow the switch naming convention as close as feasible.

We might also think about a standardized naming for pins (contacts and coils) to allow for the use of generic symbols. (similar to what we did with audio connectors)

My suggestion would be to follow EN 5000 (overview found in https://www.finder-relais.net/en/Finder-general-technical-information-en.pdf#page=2)

---

Edit: I would still ask for specific symbols but still use generic pin numbering. Meaning similar solution to the transistors. (The generic symbol allows the user to easily use a relay not yet added to the lib or it also allows for a more flexible design flow. The fully specified alternative symbol allows for usecases where this is benefitial and also to document important information in the symbol description. We might also want to standardize it.)

[antoniovazquezblanco]

Current switch convention:
SW_[type]_[poles]P[throws]Tx[quantity]_[NO/NC]_[Latching/Toggle]_[control]_[light]_[options]_[Horizontal/Vertical]_[man]_[mpn]

New relay proposal:
Relay_[Socket]_[poles]P[throws]Tx[quantity]_[NO/NC]_[Latching]_[options]_[man]_[mpn]

[evanshultz]

Thanks for starting this, @antoniovazquezblanco !

I believe the root question was regarding footprints, so I'll add in my thoughts just for footprints below.

---

In my experience the XFormY is common in relays and helpful. I like that over the xPyT format.

---

The switch footprint naming from KiCad/kicad-symbols#580 (comment) is SW_[type]_[poles]P[throws]Tx[quantity]_[NO/NC]_[Latching/Toggle]_[control]_[light]_[options]_[Horizontal/Vertical]_[man]_[mpn].

That means the type and xPyT are grouped first. And the placement for manufacturer name and PN are at the very end. I didn't notice this before during the relay discussion, so sorry for that, but this is opposite everywhere else I've seen where the manufacturer stuff is at the beginning. Why would we not do that for all footprints instead of all footprints except for switches? Are switches so generic that this is a better scheme?

Let's take the Panasonic JW series as an example. Relay*Panasonic*JW1* works well as an FP filter and clearly reveals the manufacturer of the relay. Actually, it works either way because of the wildcarding. JW1 includes the contact being 1FormC, assuming CvPcb is also filtering by pin quantity. And Relay*Panasonic*JW1a* catches the `FormA version.

Manufacturer at the end means that the Panasonic JW footprints are split all over the place, grouped by the contact configuration. To me, grouping by series is more important than the contact configuration.

While switches are perhaps more compatible than relays, relays often have rather unique characteristics. Contact construction can vary greatly between relays which have the same body size and ratings on paper. I've been bitten by this before and so to me, knowing the vendor of the relay is important. I can't accept supply chain folks adding on other sources because there's too many criteria to evaluate just from a datasheet. Contact configuration and current certainly don't tell the whole story. My experience is with some small signal relays and many power relays. And I also think body size is an important piece of info when selecting a relay, and that's not in the switch footprint name at all. If the relay footprint name is based off the switch one, where is body size? Or am I unusual and body size isn't so important?

So from what I see the discussion is about the placement of the manufacturer info. Which is best to have at the front of the footprint name?

1. Manufacturer info, which carries the manufacturer name (of course) and body size due to the family.
2. Contact configuration, which would relate to the usage of the relay.

I described my thoughts about why I prefer the manufacturer at the front. To summarize:

1. In general, manufacturer-specific footprints put the manufacturer at the front already.
2. We seem to prioritize manufacturer since footprints are broken up this way for big folders.
3. For relays, grouping by family means that I know right where to look if I want to check for a specific vendor's part. I just go that vendor's name and then to the family name. Maybe I'm weird or use the tool awkwardly, but I tend to do that often. So for me this feels natural.
4. While some relay requirements have lots of potential alternate parts, I usually pick them from the vendors I know and so that means the manufacturer is important to me. I don't view relays as common parts with just a few important criteria, so selecting by manufacturer is the best way I know of to find the correct relay for the application.
5. To me, relays aren't all that generic even if the basic specs are the same because the internal construction can vary. So making relay footprints more specific than the switch footprint naming indicates seems prudent.
6. If body size isn't part of the standard footprint name for a relay, then the manufacturer and series is the way to know how big things are (it may not have a particular ordering, but one gets to know the sizes as they become familiar).

Naturally, there are downsides as well. Nothing is perfect. That's just my feeling. And if the FP filters are clever then CvPcb probably only shows matching footprints anyway so to KiCad users it may not matter.

Wow. That was a lot. Sorry if I went overboard. I was just typing what came to mind.

---

I'm on board with those relay pin names and used on generic and specific symbols. Good reference link.

[poeschlr]

I do not know why we have manufacturers at the start for other libs. In IC package libs it can make sense as it then clearly differentiates generic from manufacturer specific footprints. For switches (and relays) all footprints are manufacturer specific.

---

Meaning i strongly vote for having at least the contact configuration and coil type at the start as it will allow us to be more flexible in the future (It allows having generic symbols in some future. Possibly with aliases for specific parts assuming the v6 format allows for having aliases with different footprints.)

---

Edit: In general i would not want to have another massive renaming at the start of v6. Things like where to put the manufacturer name are highly subjective and i think we can have differences here between libs as we can have different goals for them. (Relays and switches are quite different to IC packages. So are connectors.)
And yes in the long run it could happen that the relay lib is split into multiple libs along manufacturer lines. The naming convention should however mainly focus on having it easy to use footprint filters for generic symbols.

[antoniovazquezblanco]

From the last comments I get that the manufacturer should be kept at the end for the moment. Have we reached an agreement about naming or is there anything else that should be discussed?

Thank you guys!

[evanshultz]

It is not true that relays are all manufacturer-specific. At least not for power relays I'm familiar with.

As I showed above, because the FP filter wildcards catch the manufacturer and series name in any position it does not matter where in the footprint name they are located. If if making this easy is the most important option (and also assuming your first point about all relays being manufacturer-specific), why not just use the manufacturer and series and dispense with any other fields?

No matter what footprint name format is selected, there will be lots of non-adhering footprints. Possibly all of them. So if matching the format is desired for v6, many libraries will need a massive renaming to adhere.

@antoniovazquezblanco
I defer to Rene on the general topic.

But I still have a couple of questions, taking the format you proposed at #418 (comment):

1. What about XFormY vs XPYT? I don't see Rene's response to that so the contents of this field can be settled.
2. What does the Socket field capture for a relay?
3. Does coil latching matter? Isn't that more of a symbol thing than a footprint one? I don't think that affects the footprint, unless there's a coil graphic on the footprint to show this. It would seem latching and non-latching can share a footprint easily IMO.
4. Same with NO vs NC. Why unique footprints? Can't the footprint be in common? Or did you intend to have (and standardize on) a graphic on the footprint to show this?
5. Would body size be a helpful thing to include? Switches vary wildly, but relays are often rectangular. If the user sees the body size in the footprint in CvPcb or another tool (like KiCost?), would that help them select a relay?
6. Some relays have the choice of THT or SMD pins. Should that be captured in the footprint? We do that with other footprints, and if one footprint covers a wide range of series names then it would help to cut down on the number of footprints or make footprint naming less awkward.

[antoniovazquezblanco]

What does the Socket field capture for a relay?

Some manufacturers provide sockets for relays so they can be replaced easely.
https://gfinder.findernet.com/public/attachments/56/DE/S56DE.pdf#page=12

[antoniovazquezblanco]

1. What about XFormY vs XPYT? I don't see Rene's response to that so the contents of this field can be settled.

@poeschlr

3. Does coil latching matter? Isn't that more of a symbol thing than a footprint one? I don't think that affects the footprint, unless there's a coil graphic on the footprint to show this. It would seem latching and non-latching can share a footprint easily IMO.
4. Same with NO vs NC. Why unique footprints? Can't the footprint be in common? Or did you intend to have (and standardize on) a graphic on the footprint to show this?

It should not matter physically I agree

5. Would body size be a helpful thing to include? Switches vary wildly, but relays are often rectangular. If the user sees the body size in the footprint in CvPcb or another tool (like KiCost?), would that help them select a relay?

I think this could help the user but we should advance what to do with non-standard shaped relays. Do we omit this information or do we use an axis aligned bounding box?

6. Some relays have the choice of THT or SMD pins. Should that be captured in the footprint? We do that with other footprints, and if one footprint covers a wide range of series names then it would help to cut down on the number of footprints or make footprint naming less awkward.

Maybe do the same as in the converters and add that info at the end.

Current standard summary:
Relay_[Socket]_([poles]P[throws]Tx[quantity]|XFormY )_[options]_[man]_[mpn]_[THT|SMD]

[evanshultz]

Thanks for starting and continuing this discussion!

2 Got it. Thank you. I would suggest this goes into the options field since I guess it's far less common that not using a socket?

5 Yes, I would say an overall bounding box for odd-shaped relays. And that's only if size is accepted.

[antoniovazquezblanco]

Current standard options:

1. Relay_[poles]P[throws]Tx[quantity]_[width]x[length]mm_[options]_[man]_[mpn]_[THT|SMD]
2. Relay_XFormY_[width]x[length]mm_[options]_[man]_[mpn]_[THT|SMD]

• Options: Socket, etc.

Do you agree with size positioning in the name?

I think that the rest mainly depends on what Rene considers more adecuate. I personally am more familiar withe the xPyT notation but XFormY is more common around the relay world.

Thanks!

[poeschlr]

To answer your questions adressed at me:

Does coil latching matter? Isn't that more of a symbol thing than a footprint one? I don't think that affects the footprint, unless there's a coil graphic on the footprint to show this. It would seem latching and non-latching can share a footprint easily IMO.
Same with NO vs NC. Why unique footprints? Can't the footprint be in common? Or did you intend to have (and standardize on) a graphic on the footprint to show this?

For connecting the correct generic symbol to the correct footprints. How else would you filter it? (Same as with the switches) Unless kicad adds additional things we can filter for such things need to be encoded in the footprint name. (Or do you really want to keep the lib fully atomic? Fine by me but i still feel we paint us into a corner that way.)

[poeschlr]

Additionally: Why is there both FormX and the pole/throw nomenclature in there. This seems silly. Lets keep it as pole/throw only as it is intuitively understandable (FormX means one needs to learn what the letters stand for. Poly/Throw tells you on the tin what to expect.)

[evanshultz]

I mentioned above that relays seem generally manufacturer-specific. So I understand your point about latching vs non-latching and NO vs NC in the footprint name would apply when generic symbols were used with a specific footprint. Right? Is there another case to consider?

Intuitiveness depends on if one is familiar with the XFormY nomenclature or the pole/throw nomenclature. Intuitive to one person doesn't mean intuitive to everyone, especially when there are regional differences around the world.

[poeschlr]

The nomenclature would be quite clear if we write out the words throw and pole instead of shortening them to a single letter. Maybe this would be the way to go? (pole and throw should be understandable by every electrical engineer with at least a bit of understanding of the english language. And we kind of assume the later to be true as we do not provide translated libraries anyways.)

[antoniovazquezblanco]

The nomenclature would be quite clear if we write out the words throw and pole instead of shortening them to a single letter. Maybe this would be the way to go?

I would vote to keep the P and T nomeclature as it is very well known and writing down the full word would make FP names much longer...

Relay_[poles]P[throws]Tx[quantity]_[NO/NC]_[width]x[length]x[height]mm_[options]_[man]_[mpn]_[THT|SMD]

Should we include height in dimensions?