MAybe try and understand the reasons that I give above. This problem seems twofold:
The question who thinks which symbol should be used … that can be debated, but sticking to an international standard as opposed to a country-specific standard seems to make more sense to me, when lmited resources are available.
In an ideal world I would love to have a lib that can be switched between standards (see above!), but that’s technically not so easy. So as this option is out, three options remain:
2.1. We have a lib that does not enforce/wish for any standardisation … and end up with a wild mixture that does not really help,
2.2 or we have enough man-power to manage and sort such a multi-standard lib and make sure that everything is available in every standard (with the current number of librarians: out of the question). Again note this is not “just” about the R-symbol, but also all the derived symbols, symbols with internal schematics, switches, diodes, … This also raises the question, if someone submits a certain diode, like e.g. a zener diode ZPD3V6 … which symbol should he submit? IEEE? IEC? Both? (IEC: , IEEE: )
2.3 the approach we go for at the moment: Choose one standard (although there will always be someone who dislikes that) and try to get the lib as conforming as possible (currently underway, but far from complete!!!)
I think 2.3 is more or less the only manageable approach with the current man-power that leads to a lib that is at least in part coherent! Which approach would you favour?
Why do you feel offended? @davidsrsb just gave examples of diverse silkscreens that people use … and the question is valid: Which one should KiCAD adopt then?
It was a bad example given the context, and the fact that silkscreen graphics were not part of the discussion in the first place.
I’ve never suggested the “librarians” should be responsible for creating us an all encompassing library that includes all symbols and every variant recommended by all the relevant standards. But the idea that you would reject any contributions from the community that don’t fit your view of what the rest of us should be doing is just a bit too “ivory tower” like.
Anyway, I’m out of this discussion, and possibly forum.
Why?.. it’s a nice forum and usually for helping newbies and not getting angry at each others opinions what the official libraries that ship with KiCAD should contain.
I was pretty amazed about your latest posts, they came over very informative and cool.
Why don’t the people who want a certain kind of symbol style that deviates from the official KiCAD version just get to work and start to build up a library that does what they want?
No one needs approval for that kind of work by anyone…
Github does cost nothing if the stuff is public and is actually made for collaborative work like this.
If there are so many people out there who want the alternative, there should be symbols for that style in no time…
Be the change you want to see.
Just start and see where it leads… it’s really not that hard.
I too don’t really care. But I know I’m not alone when it comes to preferring the zig-zag style resistor symbol (for one). I am only pursuing this argument on behalf of the community but I am not getting any support.
Unfortunately that makes some things even more difficult, (avoiding name clashes for both libraries and components, etc) and doesn’t benefit from any Github update facilities built into Kicad.[quote=“Joan_Sparky, post:48, topic:6310”]
I was pretty amazed about your latest posts, they came over very informative and cool.
[/quote]
Thank you for that! I hope my contributions were of some help to somebody.
Back when I was about 10 years old (we won’t get into just how long ago that was!) I read a book that was an introduction to electronics. It used the analogy of water flow to explain various electronic components and how they affected the flow of electricity. A resistor was shown as a series of short pipes connected together with 90 degree joints. This series of pipes would resist the flow of water and create a pressure drop between one end and the other. A diode was explained as a check valve. A capacitor, when connected in series, was like a diaphragm and would block a steady flow but pass pulses. And when the capacitor was connected in parallel it was like a tank with an inlet at the top and outlet at the bottom. With frequent enough pulses of water entering the tank we would have a steady flow of water out the bottom. I was fascinated by this book and hooked on electronics ever since.
Just a short anecdote, not really relevant to anything.
Well actually, it is relevant in the sense that when I see a resistor symbol I think of those pipes.
someone who wants to use IEEE over IEC would probably not load the other library…
you could always add the style as _IEC or _IEEE to the symbol/part name
once we get the .sweet system, this will be of no concern anymore (*)
the github update facility is not a useful system at the moment anyway, maybe once @SchrodingersGat had a chance to make it useful, and then it’s just a matter of getting included that the github resources can be anywhere - not only the official ones. Might want to put your effort into that basket, so this becomes a part of it
*) install yourself a nightly version and you’ll find a new item in the template folder called sym-lib-table, which looks like this on the inside:
It’s also in the kicad settings folder - just empty for my nightly… but you see where this is going, right?
We’re just a couple of steps away from them symbols being ID’d via [libname]:[partname].
So, go ahead, connect with the people who want what you want and start.
Those symbols wont make themselves and you’ll need a while to get enough together to call it a library…
Quote of Zorg: If you want something done, do it yourself. Yep!
[quote=“1.21Gigawatts, post:50, topic:6310”]
Well actually, it is relevant in the sense that when I see a resistor symbol I think of those pipes.
[/quote]For me it was always the representation of a heater element just like you see in a toaster.
Like I said, I’ve been reading schematics with the zig-zag resistor for decades now; since some time in high-school. My “mind” sees the zig-zag as a resistor, and the rectangle as some form of alien device that requires further investigation.
As I stated earlier, it is also physically representative of what it does electrically; like the pipe/toaster examples. It is my opinion that the basic symbols should retain the common old US designs in some library.
I’m already working through this and adding/modifying these into my own personal libraries. When I am done, I can share them; although I’m a little surprised that someone has not already done this well before today.
Sprig and others, I am somewhat on the fence, in that I can cope with either symbol. However, you are definitely not alone in wanting to retain zig-zag symbols.
I too would like to see the deMorgan method applied in this case – to provide alternate symbols in general, not just for logic.
On a more serious note, the only thing that matters for netlist export is the refdes and footprint attribute. What the symbol looks like should make no difference, even to back annotation, if I am not mistaken. In gEDA gschem, there is resistor-1.sym, resistor-2.sym and so forth, for different styles or sizes of resistor; nothing stops you using multiple resistor symbols in a layout if your particular needs make it necessary.
I think @erichVK5 sums it up best with ¿porque no los dos?
Adding a second resistor symbol to the library seems to be a fine solution that would keep everyone happy.
Using the de-morgan equivalent makes most sense to me, for the following reasons:
a) The symbols are then actually equivalent
b) Next week someone will ask about the potentiometer symbol! Rather than have duplicate symbols for each device, multiple representations of the same symbol seems easier to me.
c) In the fancy new .sweet implementation, perhaps there will be better facility for multiple representations for a single symbol. This is a good stop-gap until that stage.
Please, remember that y’all have the power to make a PR with any proposed changes. If a squiggly resistor is that important, let’s make it happen.
Still the question remains how we manage other symbols with eg. internal drawings then?
If we use the deMorgan-functionality (which is maybe the best way, although it’s meant for something else) we could require standard version is IEC and alternative version is IEEE … but what happens if someone ONLY provides an IEEE-styled symbol? Do we accept it? Do we accept it, if he/she also provides the IEC-version? Do we reject it?
Also: Does this mean we drop support for the deMorgan functionality as it was intended (i.e. for logic)? Otherwise eople using deMorgan-alternative on their schematic would also only get the alternative logic gates …
I am very surprised that the discussion of the “stupid resistor” has grown to 60 posts!. The devs and librarians must aware - officially - the current and future users of KiCad that in the case of commercial use they should create their own libraries, meet their standards.
And this is where the complication lies. Perhaps using De Morgan is too much of a hack for this feature.
I don’t support a library-wide duplication of every symbol with a resistor in it. The standard libs are one-size-fits-most and we cannot support every potential variation.
I shall do some digging and see if the upcoming library format supports proper multiple symbol representations. If that is the case, then perhaps this entire argument is moot and should be postponed until this feature is available.
Perhaps providing a place to list community contributed libraries would avoid future discussions like this. Certainly it would be more helpful to new users of KiCad.
As for my company’s possible adoption of KiCad, the layout specialists tell me that, whatever is adopted to replace the current EDA app, they will be creating local versions of the supplied libraries and that modifying the “resistor glyphs” won’t be a significant additional burden.
, IEEE: 
)
, IEEE: 
)
