Transformers library about kicad-symbols

[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.

KiCad/kicad-library#1447 (comment) 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: KiCad/kicad-library-utils#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.