Both resistor symbols are part of both standards (as @Rene_Poschl has indicated) so all this talk of which standard Kicad should support is rather moot. Besides, no one seems to be asking for the entire library to be made compliant with one standard or another. The original question is regarding one symbol, the zig-zag resistor. It stands to reason that those who prefer the zig-zag resistor, which would seem to be the majority of those who have voiced an opinion on this thread, also prefer the loopy inductor, and probably a few other symbols such as zig-zag pots etc. If someone were to start from scratch it would probably be less than an hours work to create them, less time than has been spent on this thread so far.
The USA is a full member of the IEC via ANSI, as such ANSI and IEC arenāt exactly competing standards.
This is an IEEE/ANSI/CSA document that also indicates which symbols are recommended by the IEC.
Excellent! So @1.21Gigawatts, @cbernardo and @Rene_Poschl have all volunteered to create and maintain the new symbols! We should have this done in no time. That is superb and I thank you for your effort.
Please donāt add yet another default library, there does seem to be a limit. I would prefer to see device_ansi as a full alternative. Simply adding to devices is going to bloat the library and alternate symbols like logic has will trigger arguments about priority
Maybe I repeat myself: We try to keep a more or less uniform style in the lib and I doubt that an alternative device_ieee.lib will be accepted!
Especially since one would have to double a lot of symbols ā¦ and later there will be more questions:
If someone submits a new symbol should we require to provide both styles, or do we accept any style?
How do we keep names consistent?
If a new symbol is only provided in wiggly, who creates the box-shaped?
If someone submits a compound symbol (e.g. an IC with a sketch of internal schematic, transistor with resistors in package, ā¦), which style do we require? Do they also have to be doubled?
If we do a larger change of say FPFilters ā¦ do we need to do them on both sets of symbols?
ā¦ and all the other stuff that will just create additional work for the few librarians that there are and make submitting even more complicated, as not even the style is defined for the lib ā¦
Somebody hasnāt being paying attention! The symbols we are discussing are IEC, which you claim is the standard Kicad is intended to support.
Yes, the question is why? Itās still as silly as the first time you posted it. Do you currently enforce what the internals of a symbol look like? Not according to my library. If I select a resistor I get the rectangular symbol, but if I select a resistor pack I get a rectangle full of zig-zags. There are a number of transistors with integrated resistors all of which are zig-zags.
That too is based on false assumptions.
Do any of you actually have a copy of the IEC standard you hold so dear?
Out of curiosity I had a look through some datasheets in my library to see which symbols were used by whom:
Those using the rectangular symbol:
FTDI NXP ST Micro
Those using the zig-zag:
Maxim Microchip Samsung Analog Devices TI
Xilinx Davicom On Semi Semtech Linear
Altera muRata Intersil Invensense Toshiba
Skylab Vishay LiteOn X-Powers Terminus
Micrel Genesys Logic Avia Semi Bourns
The ālibrariesā (footprints, 3D models, schematic symbols) are a different project and maintained mostly by volunteers who are not involved with the software development (libraries are in various repositories under github.com/kicad)
Thanks.
Personally I think some effort is needed for a separate project to provide part configuration and management
FWIW, where I work, we use in-house part numbers tied to our departmental component DB (previously in Oracle, now in Postgres). The current, proprietary EDA tool setās component libraries refer to these in-house part numbers. It doesnāt have any kind of connection to the DB, so, according to our layout specialists, we wonāt be loosing that feature by switching to KiCad. (The company only purchased licenses for our layout specialists. Us designers have been left to use Visio or Dia. KiCad will be an improvement for us.)
Perhaps if KiCad had a provision to configure an URL template and the means to automatically insert the componentās part number in the URL template, then display that as a click-able link.
Well I have ā¦ I saw that in the 1975 docu ā¦ still it was decided to stick to only-rectangular symbols when overworking device.lib. I used this doc (more recent!) as source: http://pcad-libs.embedders.org/rules/ref_617.pdf (from Alstom, based on IEC 60617-2/-11:1996). If you look at p. 72 ā¦ no wiggly (unless I overlooked them).
To prevent people from putting in the work which may be rejected in the lib (see it merely as a warning!).
Then youāre using an old lib version. In current lib-versions they look like this:
The transistors are old symbols and should (!!!) be overworked, but so far no one volunteered
which false assumptions? If you name them, we can discuss them!
Best,
JAN
PS: Bottom line is this: During the last year, a large effort has been made to make the lib look more uniform and sleek (and itās still going on, Iām currently e.g. overhauling regul.lib and ther is a PR for linear.lib ā¦). Based on that and on what we do on a day-to-day basis in review, I strongly suspect, that the wiggly resistors would not be accepted into the lib (and if itās just to keep the lib managable by preventing doubled and tripled symbols that all are the same, just with a different look!). What I would find nice would be support from KiCAD for different styles, as it is implemented for standard logic and deMorgan-form. This way one would have ONE component, just with two user-selectable appearances (I would vote to accept such symbols, if the feature exsted in KiCAD) ā¦
Judging by the list of companies I posted above it seems some 90% of the industry would disagree.
Apparently not!
Yes, it was not the current version. Upon checking the most recent version I see that resistor packs have indeed been changed. Much to my disappointment.
I agree, as it is easy enough to create your own symbols. It is however disappointing that they all but ban the worldās most popular symbol for resistor type components from the Kicad libraries.
Nonetheless I stand corrected and apologize for not having been more thorough during my earlier research. I have since learned that the 1996 revision of IEC 60617 deprecated the zig-zag resistor symbol. It is no longer an IEC recommendation, although the loopy inductor remains.
The fact that after more than two decades the IEC recommended symbol is not more widespread should tell you something.
I was told to stop using zig-zag resistors by the British Post Office before it became BT in the 80s and then the Marconi drawing office tracers decided that boxes were easier.
What that list of zig-zag users has in common is that they are in the US (Philips bought Signetics). Philips Europe and Siemens were box users.
These days the biggest advocate of zig-zags is LTSpice
While many of them are headquartered in the US, especially after all of the recent acquisitions, most of them are global companies serving an International market. But the list also contains several Asian manufacturers from Korea, China, Japan, and Taiwan. I didnāt list mikron (Russian) who belong to the zig zag list. Not to be confused with Micron (US) who are also of the zig-zag group. Infineon (German) Europeās largest semiconductor company can be added to the box group, but they do manage let a zig-zag slip through here and there.
NXP (Netherlands) = Philips and they are in the box group in my list above.
Anyway, the zig-zag is obviously still a very common symbol in the industry.
The actual argument that I tried to make is the question: Who keeps the libs in good shape with all those varieties of symbols? Maybe that should be discussed. A decision has been made for one style to achieve a common style in the lib. You might call that decision arbitrary or dislike the outcome, but the reasons for the decision are NOT merely promoting a certain standard, but more trying to cook it down to ONE desired style!
The first library item that I changed was that ārā was associated to the zig-zag resistor!
Being an electronics technician on US military, Iād never before seen the box resistor.
Somewhere it was pointed out that the symbols actually resemble the basic physical characteristics of the real world parts.
Imagine a zig-zag route marked on the ground for a person to run, versus a simple straight path; thus resistance.
Capacitor are plates with a dielectric between them.
Inductors are created with loops of wire.
Anyways, Iāve been reading schematics with zig-zag resistors for decades now. The box resistors throw me off a little. I end up trying to look closer to see if it is some type of chip, or some other thing, because I donāt automatically āmentally seeā that box as being a resistor on first glance.
Itās another Atlantic split thing like metres vs feet, Celsius vs Fahrenheit.
As @jkriege2 pointed out, symbols showing internal circuits are a particular problem with this, itās not just a case of alternative basic device symbols.
Personally I find being able to place text inside the box on crowded schematics can avoid confusion
Concepts similar to this have been discussed on this Forum over the past year or so, without arriving at a consensus over whether KiCAD should move in that direction, and certainly no agreement over how such a system should work.
Some people just have to find fault with everything. I think that is an excellent educational project and as such the silkscreen is probably quite fitting.
You are the first to bring it up as no one else has suggested deviating from the IPC recommendation. So I see no argument there.
The āargumentā is about including an industry āstandardā schematic symbol in the Kicad libraries. But weāve been told that symbol is more or less banned from the āofficialā Kicad libraries in favor of the lesser adopted IEC standard. Repeatedly on this forum (numerous times in this thread alone) people are advised that if they want something supported by Kicad then they should do the work and contribute. But in this case that doesnāt seem to be an option.
I just find it disappointing that while constantly asking for help, a handful of ālibrariansā simultaneously state that they will not in turn accept technically correct contributions from the Kicad community. Making it obvious that it is not about who does the work.