Transformers library

[jkriege2]

Hi all!

I'm just pondering a bit with the transformers in our lib. We currently have three varieties of symbols:

1. Symbols for specific transformers with footpritns linked (these are fine and mostly have a nice style already!
2. some generic transformers in device.lib, but without distinction between air/ferrite/iron-cores (diferent symbols) and with rather arbitrary pin-numbers. Also these use very old style with huge coil-curls.
3. Generic Tranformer symbols TRANF1-TRANSF8 in Transformer.lib with same pin-numbering as in item 2, nicer style but no metadata etz. also there are no variants with case/shielding-pin, which might be useful in some cases.

Therefore I was thinking whether we should come up with generic transformer symbols that cover all cases in device.lib. Naming could be e.g.:

  Transformer[_<NP>Pri][_<NTP>TapPri][_<NS>Sec][_<NTS>TapSec]_<Air|Iron|Ferrite>[_Case]

  NP = number of primary coils without tap (2-pins)
  NTP = number of tapped primary coils (3-pins)
  NS = number of secondary coils without tap (2-pins)
  NTS = number of tapped secondary coils (3-pins)
  _<Air|Iron|Ferrite> = core material
  [_Case] = presence of case/shielding-connection pins

For the numbering I would number primary coil-pins 1,2,3,...,18,19 and secondary coil pins 21,22,23,..., The shielding pin would be 0 (if present). This would leave us with enough pin-numbers for all variants (also multi-tapped, although I'm not sure how to encode these in names, maybe _<NT2P>DblTapPri ...)

The problem we are left with then are the footprints: Either we adopt a generic scheme (like done for switches) with above pin-numbers and somehow the same encoding in the names, so FPFilters work, e.g. Transformer*1Pri*2Sec*Case* could filter out all transformers that have 1 primary and 2 secondary coils. But if manufacturers have then two or three types of trafos in one package, we would have to duplicate that footprint with different pin-numbering and would essentially encode the symbol in the footprint (not so nice IMHO).

Alternatively we see the generic symbols as templates only that people can copy to Transformer.lib and the renumber the pins as appropriate for their type of trafo. We should then remove any FPFilters from the generics. (seems to be the better option to me). I would like to see these generic symbols in device.lib and not in Transformer.lib to make it even clearer what they mean.

What do you all think on that?

Best, JAN

Symbols as I would propose them:

Existing Symbols in device.lib

Existing Symbols in Transformer.lib

[poeschlr]

I would go the route of having a few generic symbols in device lib as templates for creating atomic parts in the transformers lib. Similar to what we do with relays and (ac | dc)/dc converters. (This should be made clear in the description field)

If we want a generic system, then i would suggest to create a separate lib called transformer_generic that holds these symbols. (otherwise i fear the device lib will get too large to handle very soon.) Your idea of solving the pin numbering differences on the footprint side might contradict the KLC. (At least version 2 had a clear statement defining that differences in pin ordering must be taken care of on the symbol side. Not sure if this is included in version 3)

[evanshultz]

I believe there's one piece of information that needs to be asked first: is this for a generic transformer or for off-the-shelf (OTS) parts? For an OTS transformer I vote we just built the atomic part and put it in the library. Case closed. But since you're thinking about individual windings it makes me think you're talking about custom-designed transformers where there is no obvious naming scheme.

One fundamental problem is only having windings that can be on primary or secondary. Some transformers many only be primary or secondary, which your scheme can account for. But other transformers may span multiple domains; 3-phase and delta/wye configurations come to mind. I find having these two predefined buckets for any winding to be insufficient.

Or the secondary side might have multiple windings that all have multiples taps. How does your scheme handle this cases?

I've designed transformers with multiple shields. Also, shields can be flying (not terminated at a bobbin pin but going straight into a THT). Heck, windings can be flying. It is imprudent to choose a single pin number for a shield.

For generic symbols I don't see the point in skipping any pin numbers. The footprints will be driven by the bobbin, if present, and the bobbin pins can vary greatly even for the same core size. And the number of windings can vary greatly for the same stackup size. I think just greedily consume pin numbers for generic devices.

I believe the TRANF# symbols should be removed. They're useless.

https://github.com/KiCad/kicad-library/issues/1447#issuecomment-325499139 is some older thoughts of mine on transformers, but it appears only to cover footprint naming.

This is very tricky. I've tried a few ways to capture transformer symbols and none really suited me. I wish I had stumbled across a great way earlier and could share it. I've mostly done what was above, but just called each winding a "winding" and dispensed with "primary" and "secondary". That was the best I found but I didn't love it. I agree with your preference and Rene above that we have a smattering of nice reference symbols and then atomic parts are built from them in transformer.lib.

[hvraven]

I am currently working on generating symbols for some transformers from Block (footprint PR is already where) and started generating those using the symbol generator. I tried to set it up in a way that it could be used to regenerate the existing symbols and get them to a consistent style. It also handles alias generation where possible. I posted the current status as PR: https://github.com/KiCad/kicad-library-utils/pull/310

However there are some open questions:

• How to label the pins (if not specified in the datasheet). Should it follow the conventions suggested by @jkriege2 in the first post?
• How large should the drawings be? The two factors are the size of the individual coils and the separation between them. For the height of an individual coil (distance between outer pins) 400 mils seems to be good, as it also allows to add a center pin. A separation of 200 mils would be easiest to implement as the pins are always on a 100 mil grid, even if one side has 1 and the other 2 windings. This leads to relatively large symbols: Would this be acceptable?

Would it be ok to regenerate all existing symbols using the generator? As far as I understood this can only be done for major releases, but I think this wouldn't be an issue.