Comments (3)
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)
from kicad-symbols.
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.
from kicad-symbols.
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.
from kicad-symbols.
Related Issues (20)
- [v6] Power_*
- [v6] pspice
- [v6] Reference_*
- [v6] Regulator_*
- [v6] Relay*
- [v6] RF*
- [v6] RF*
- [v6] Security
- [v6] Sensor*
- [v6] Simulation_SPICE
- [v6] Switch
- [v6] Timer*
- [v6] Transformer
- [v6] Transistor*
- [v6] Triac_Thyristor
- [v6] Valve HOT 1
- [v6] Video HOT 2
- TXB0108DQSR Level Translator Sybol Error
- Minor fix with Comparator.lib HOT 1
- just a patchfile with new symbol HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from kicad-symbols.