Idea: Eeschema Multiple Alternate Symbol Shapes

The idea is to “unify” the different standards for symbols: A symbol could have US and international shapes (ANSI, IEEE, NEMA, IEC, DIN, etc.), and other users could later switch them themselves in the schematic, if so desired (I know: less interesting for the US). While De Morgan isn’t much used anymore, there are still the distinctive- and uniform-shaped symbols of ANSI gates (AND/OR/XOR and negated versions). Also, 45° rotated shapes for bridge/ring circuits. One power symbol could have different voltages. Opamps could have alternates with +/− inputs swapped (when used as comparators). Transistors with and without envelopes (case circles). FETs with and without body diodes… That’s quickly more than a single alternate symbol.

For ngspice, it has the same builtin circuit element (D in SPICE) for regular, Schottky and Zener diodes, but they have different symbol shapes and currently require multiple symbols with the same functionality.

Of course that’s mostly for discrete components (“Device” library) and less interesting for ICs, but most of what’s mentioned above has been done already.

While the KiCad lead development team is apparently opposed to such an idea, there are working branches for V5 and V6 on a fork.

Genius. Hope you keep us posted.

Thanks. Left original, right modified:

1 Like

Example alternate shapes (SVG file converted from PDF plot):
KiCad
The different line widths can easily be changed to a single width, and indicators (+/−/•) can be moved or hidden.

1 Like

@franzee I think this is great work and very useful.

I might be missing something or maybe there is some more background to this story that I am not aware of but I must say I am not sure why there is such a negative reaction about this improvement from Wayne.

I understand his point about discussing ideas before implementation of any major feature (in hindsight you probably you should have done that before starting, to keep everyone happy). I can see him being frustrated that this discussion didn’t happen in advance, but I don’t quite understand the reason for not wanting to accept the idea as a whole and just request you to make changes to the implementation to satisfy his concerns.

The issue with existing “DeMorgan” implementation means the lead developers have to maintain this code anyway to satisfy compatibility with legacy designs. I don’t think many people use this feature (I didn’t really know what it was until you pointed it out). Your idea of expanding the DeMorgan feature to be more generic and useful seems a good idea to me.

Another use case of this would be to have a more compact version of a symbol (e.g. a smaller resistor of length 200mil vs the standard 300mil), and make it easy to switch symbol for the same component. At the moment this would be difficult to achieve as it requires duplicating component libraries, which creates a lot of problems with duplicate entries that you then need to manage if ever doing an update to a field.

Unless the import of old formats automatically assigned any DeMorgan geometry as Shape2.

I’ve occasionally used the DeMorgan as an alternate shape, especially for a symbol that doesn’t make sense to have a DeMorgan (i.e. pretty much any symbol other than a logic gate symbol). But my usage is rare enough that I’m not even sure if I can find an example…

But, I can see if taken too far then placing symbols starts to become even more tedious. The way it currently is when choosing a symbol one only sees the “normal” geometry so you pick from a list of the geometries available and then only for some components do you choose the gate. If taken so far, then an additional shape choosing step will need to happen for most symbols. If you include all the different shapes in the symbol chooser, then what saving is there to the library list?

1 Like

Yes, that is what I meant: lead developers/contributors need to look after DeMorgan code anyway so why not extend it to be a bit more useful?

This is a very good point point and a great example of why discussion of new features need to occur before any code writing takes place: one person can’t think about all possible issues/negatives of a particular way of going about an idea. I agree that this has the potential of making symbol selection more onerous and further thought would need to go into how do you actually select another “alternate” shape without requiring excessive clicks.

An alternative to this whole idea might be expanding the “symbol inheritance” feature of the new schematic file format in v6 such that you can have components in the library deriving from others and allow changing of the symbol shape (I believe that at the moment the symbol inheritance model only allows changing parameters but I don’t think it allows changing symbol shapes/pin positions in the derived symbols). However, anything like this needs to be discussed thoroughly in the Developer’s mailing list (nothing would likely get done for v6).

If you include all the different shapes in the symbol chooser, then what saving is there to the library list?

I think this is the key point. If we could turn back time, I think the dev team would have preferred to not have the DeMorgan feature in the first place, and instead just use separate libraries if people prefer different styles of symbols.

The issue with existing “DeMorgan” implementation means the lead developers have to maintain this code anyway to satisfy compatibility with legacy designs.

Maintaining existing code and expanding what it does greatly are two different things. We also could “migrate people out” of DeMorgans if we wanted to, by splitting those parts into two different symbols for people.

At the moment this would be difficult to achieve as it requires duplicating component libraries, which creates a lot of problems with duplicate entries that you then need to manage if ever doing an update to a field.

While this is true in theory, I’m not sure how much it comes up in practice. After all, I think any given person or organization is only going to be using one style of symbol, and thus they need to add their custom fields to only one library.

(but also I think database libraries is a better solution to custom fields than putting the fields into the symbol libraries, so personally I’ll be going that route once we get it implemented…)

1 Like

Fair point. I don’t disagree.

It doesn’t come that often in practice. However I have had many situations when I wanted to have a smaller resistor symbol in my design to make it more legible. I liked the op’s idea of allowing this to be done with relative ease.

That is interesting. Is there any link/discussion with more information on that?

@craftyjon overall I completely agree with your comments and understand that certain ideas might create more work in the long term compared to the benefits they bring. I just think its good to at least be able to discuss such ideas constructively instead of turning them down with little discussion.

That is interesting. Is there any link/discussion with more information on that?

There has been some discussion on the developer mailing list but I’ve been putting off the formal spec development until after V6 is released.

Absolutely. Generally the developer’s mailing list is the preferred place to have that discussion (at least, in the context of actually writing code to support some new feature - this forum is fine to discuss ideas before opening issues on GitLab, etc)

2 Likes

This is interesting!

I don’t want to butt in on a discussion between people apparently well-versed with KiCAD (I’m a newbie), but I’ve missed DeMorgan alternatives in the libs (and have had to create them myself).

But I think you should take this further. As an example, standard logic functions, eg, the 74xx parts are split in two libraries, 74xx and 74xx_IEEE.
To me as a designer, it would make much more sense to just select a part, and then decide which symbol to use: the ‘standard’ or the IEEE.
Having multiple symbols for one part makes a lot of sense to me.
And it makes finding the right symbol for a device much easier (the number of libraries gets smaller).

Possibly limiting the “Number of Shapes:” entry in the GUI to 2 (instead of 64, like for units) to satisfy developers (see image below). In later versions then grayed out (unless paying support subscription fees :wink:).

Note that this is only a GUI change. Regular KiCad 5.1.7 supports multiple alternate shapes for symbol copying, editing, printing, saving, etc., if the files have been generated with other tools¹. It’s just that only shapes 1 and 2 can be selected or previewed in KiCad². Current KiCad 5.99 doesn’t fully support saving to the new file format though.

¹ kicad-symgen generates regular (shape 2) De Morgan symbols but it could also be a text editor.

² KiCad 6 allows to copy a symbol and paste it into a text editor, there adding or changing the appropriate (convert #) after (unit 1), and copying and pasting it back into the schematic.

newsym

Added Eeschema 5.1.7 executable for 64-bit Windows (for replacement on top of official installation).

@franzee, I don’t know where your screenshots are from, but they do not look like those of a normal KiCAD user.

I’m a normal user and am underwhelmed with the KiCAD symbol library in many ways.

As an engineer, I use DeMorgan equivalents in almost all designs for clarity and readability. But I’d never need the “DeMorgan” buttons in the KiCAD menu. Especially as they don’t work, because no one maintains the libraries. Useless.
Having multiple symbols for one component makes much more sense.
I’m close to retirement and volunteer for cleaning up your libraries. But only when the structure makes sense and is useful to other users.
The symbol library management is on top of that total cr*p. Just look at this totally incomprehensive message (Google Translate?):

Missed a couple of the screenshots:
newsymbol

Hotkeys (not in 5.1.7 though):

I guess this is maybe easier to understand if you assume the normal shape (aka body style) is internally shape #1 and the alternate shape (“DeMorgan”) is shape #2. Every graphical drawing element and every pin is associated with a shape number. There is also common shape #0, which means it’s always active or visible (that’s the meaning of “Common to all body styles (DeMorgan)”).

If you select “Has alternate body style (DeMorgan)”, that effectively means adding a shape #2, and pins associated with shape #2, and they are copied from shape #1 for convenience. The message asks if that copying is OK.