Alternate resistor symbol (KiCAD evaluation for company use)


#41

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.

Dale


#42

I’ll vote for this approach!


#43

Then we get into an argument about the silkscreen. Boxes are more common than on the schematic, but I have seen zigzags and also just a line bridging the pins
http://www.e-licktronic.com/en/content/40-power-tr-808-clone
and even worse, dumbells
https://www.rs-online.com/designspark/assembling-a-discrete-555-timer


#44

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.


#45

MAybe try and understand the reasons that I give above. This problem seems twofold:

  1. 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.
  2. 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?

Best,
JAN


#46

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?


#47

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.


#48

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. :+1:

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.


#49

Well like others have said in this thread …

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.


#50

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. :slight_smile:

Well actually, it is relevant in the sense that when I see a resistor symbol I think of those pipes. :wink:


#51

Na.

  1. someone who wants to use IEEE over IEC would probably not load the other library…
  2. you could always add the style as _IEC or _IEEE to the symbol/part name
  3. once we get the .sweet system, this will be of no concern anymore (*)
  4. 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 :wink:

*) 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:

(sym_lib_table
(lib (name 74xgxx)(type Legacy)(uri ${KICAD_SYS_SYMBOL_DIR}/74xgxx.lib)(options “”)(descr “Legacy 74xgxx symbol library.”))
(lib (name 74xx)(type Legacy)(uri ${KICAD_SYS_SYMBOL_DIR}/74xx.lib)(options “”)(descr “Legacy 74xx symbol library.”))
(lib (name ac-dc)(type Legacy)(uri ${KICAD_SYS_SYMBOL_DIR}/ac-dc.lib)(options “”)(descr “Legacy ac-dc symbol library.”))
(lib (name actel)(type Legacy)(uri ${KICAD_SYS_SYMBOL_DIR}/actel.lib)(options “”)(descr “Legacy actel symbol library.”))
(lib (name adc-dac)(type Legacy)(uri ${KICAD_SYS_SYMBOL_DIR}/adc-dac.lib)(options “”)(descr “Legacy adc-dac symbol library.”))

(lib (name Xicor)(type Legacy)(uri ${KICAD_SYS_SYMBOL_DIR}/Xicor.lib)(options “”)(descr “Legacy Xicor symbol library.”))
(lib (name xilinx)(type Legacy)(uri ${KICAD_SYS_SYMBOL_DIR}/xilinx.lib)(options “”)(descr “Legacy xilinx symbol library.”))
(lib (name zetex)(type Legacy)(uri ${KICAD_SYS_SYMBOL_DIR}/zetex.lib)(options “”)(descr “Legacy zetex symbol library.”))
(lib (name Zilog)(type Legacy)(uri ${KICAD_SYS_SYMBOL_DIR}/Zilog.lib)(options “”)(descr “Legacy Zilog symbol library.”))
)

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!


#52

[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. :wink:
[/quote]For me it was always the representation of a heater element just like you see in a toaster.


#53

^^^ YOU ARE NOT ALONE! ^^^

^^^ I SUPPORT THIS ^^^.

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.


#54

Resistor symbols: the C brace style of the hardware world.


#55

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.


#56

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.


#57

Well, isn’t this lively.

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.


#58

That means: Because not both?

¿ Por qué no los dos? = Why not both?
:slight_smile: :slight_smile: :slight_smile:


#59

Well this is what happens when you learn Spanish from memes.


#60

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 …

Best,
JAN