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?
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…)
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)
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 ).
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 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.
@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?):
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.
Having different body styles isn’t the only possible solution. Another would be to have some kind of linkage between several symbols which are often used alternatively. Then have them in a dropdown list in the “Change Symbol(s)” dialog along with the free text and file chooser.
The implementation would be simpler and would require most of the functional needs with moderate usability. I just don’t think being able to switch back and forth between symbol styles with lightspeed is ever necessary.
There’s also one problem which I’m not sure how the current body style works and how this franzee’s proposition would work. If pins or locations of pins are changed, the schematic must be edited anyways. That would pretty much eat up all the time and workload savings acquired by quick symbol change. It wouldn’t be possible to just switch back and forth between, say, larger and smaller symbol.
I’m just a regular KiCad user who sometimes puts in a bit of effort to answer questions on this forum.
I am having some difficulty in wrapping my head around this, and why it would be beneficial.
From the first post:
These pins have different meanings. Swapping them would break the schematic / introduce errors.
A few posts later:
If the endpoints for wire’s don’t match up, then it also breaks the schematic because wires are not attached to symbols after a change.
This is currently handled very badly:
But multiple symbols is not the solution. I see the solution in a simple editable field (such as the “value” field) to enter a text string for the power net label.
When I think about a schematic symbol having changeable graphics, I’m thinking along the same way it’s handled with Footprints. The schematic as a UUID (timestamp) as identifier, and the Footprint is just a text string pointing to some library reference. And this is already implemented. If you hover over symbol, press e for edit, then you can already change the “Library Reference” of the symbol, which of course changes all it’s graphics. (Oops: Working with V5.1.6 here. are your screenshots from V5.99?)
I also have no desire to change such symbols after the fact. I choose something when designing the schematic, and then just stick with it. If I see a schematic made by someone else, I switch to using their conventions. I have no personal preference in this regard.
Some use transistors with circles, others use them without. I just use what’s in the library, but for pen and paper schematics, drawing the circles is too much work. I think the “official” convention is that transistors in separate housings have circles, and transistors in IC’s don’t have circles.
It’s dangerous to speak of what someone else may be thinking, here is my best guess:
There are 45 merge requests waiting on gitlab. and 900+ open issues. Wayne probably does not have time to think about some feature he knows nothing about, but has a substantial impact on the code base. There is 10+ years of development from lots of people (I don’t know the man-hours) in KiCad. Compared to that, this is an “insignificant detail”. (No insult intended). Some merge request for anything without being aware of a benefit for a significant of KiCad users in advance is simply instant rejection. This has nothing to do with the content or intention of the merge request.
Combine this with all the chaotic work going on for KiCad V6, including a file format change for Eeschema, and the developers trying to find a line of what does go into KiCad V6 and what not, the timing of this is… less than ideal.
To get back to the resistor example:
What sort of “lots of problems” are you referring to?
In old KiCad versions, symbol names with duplicate names were problematic, because it depended on the order in which libraries were loaded. I made some sneaky use of that, by defining a custom library and putting some modified symbols in it with the same names as those from the default libraries. Currently KiCad uses a combination of “library_name / symbol_name”
As of now I tend to agree with crafyjon. Just use different libraries for different visual representations. Which also goes back to the core question of: What exactly is a schematic symbol? As I see it, the graphical presentation is not at the core of a schematic symbol. The graphical presentation is just a text string, pointing to some library, just as the footprint link. This is also why you see the alarming question mark symbols if these links break because of a library change.
However, if you read the Eeschema manual chapter 12.2:
file:///usr/share/doc/kicad/help/en/eeschema.html#general-information-about-symbol-libraries
A symbol is composed of:
* Graphical items (lines, circles, arcs, text, etc ) that
provide the symbolic definition.
* ...
But still. Some minutes ago I first placed a 74xx:7400 gate on the schematic, and then changed the library reference to: CPU:Z80C and Eeschema does it without complaints. The other symbol attributes such as the value (7400) and Datasheet (http://www.ti.com/lit/gpn/sn7400) are unchanged.
I think this is a better way to go. Symbols may have a default graphical presentation, but ultimately they are 2 separate things.
Currently there is a list of “aliases” which can be defined for a schematic symbol. Maybe it would be a good idea to use some “alias” list for compatible graphical presentations of a symbol. I have not thought hard in this direction. Having such a list of compatible and interchangeable graphical properties may be somewhat along the “database libraries” that craftyjon mentioned.
It also overlaps with:
In short:
Starting something like this as a merge request is a bad idea. There are multiple solutions to this problem, and one solution chosen by a single person does not imply that would be the best solution for man KiCad users. Starting with a merge request, which obviously has taken a significant amount of time and effort to make, also sort of implies a closed mind to other solutions, as this would invalidate the effort already done. There are some guidelines written for stuff like this. Significant changes should always start with a discussion before any implementation is done.
If you have a schematic where the inverting pin is on the bottom, and then exchange the graphics for a symbol for which the non-inverting pin is on the bottom, than you just connected whatever wire there was at that location to another pin of the opamp, and this silently breaks the schematic.
The current solution is to simply mirror the schematic symbol in the X direction. Nothing extra is needed in KiCad.
This is clear to me after several attempts. But the message is still gibberish. To make sense, it should read something like:
"Add alternative symbol to this component [component name]?
The original connection lines will be shown for convenience and should be left where they are, otherwise existing schematics will not be able to use the new symbol correctly."
The terms “pins” and “body style” are extremely misleading, making you think of either PCB libraries or fitness studios.
The terms could preferably be:
“Component” (top level = the library part number)
“Symbol” = the full graphic layout
“Symbol shape” = the shape graphic (eg, OR, AND, NOR, FF etc.) without connection lines
“Connection lines” = the I/O and power lines to the symbol
I’d suggest dropping the “DeMorgan” terminology completely, including the symbol buttons at the top of the screen. Just rename them to “1” and “2” or “A” and “B” or “Pri” and “Alt”.
I hope this is taken as it is meant: constructive criticism in a positive spirit.
This is extremely interesting. The whole “alternative symbol” thing has three issues to my mind:
1: Logic functions: relatively easy, already partially covered by the “DeMorgan” function for basic gates. Not for complex functions, though, where “datasheet” and “IEEE” symbols reside in two different libraries. I’d like to see both in one symbol library as alternatives. Changing the symbol will break connections, but perhaps a “rats nest” function could cover that? Otherwise, a warning message could be a first simple solution.
2: Discrete parts, eg, diodes, transistors, MOSFETs, switches, capacitors, resistors, etc. Having just one library symbol plus alternatives (everyone has a preference for a specific symbol) without pin assignments for each basic device, and then automatically assigning the pin numbers after selecting the specific device would completely eliminate the RGB/GBR/BRG… (for LEDs) and GDS/DSG/SGD… (for MOSFETs) and BCE/CBE/ECB… (for transistors) etc. etc. etc.
3: cleaning up the library is way overdue. When I see CDP1802 as microprocessor (it hasn’t been produced since 40 years), something is really wrong. I estimate that half of the 16k+ devices in the library can be eliminated immediately. If someone wants to work with the CDP1802, he should create his own part. To everyone else it’s noise and clutter.
My main idea is in #2. Generic symbols that are only assigned pin numbers when the actual device is selected. That would clean up a lot, and make work easier for designers.
I’m sure I’ve missed something here, but take it as an idea.
I’ve split the multiple alternate shapes (excluding B source symbols) into own generic symbols. The number of symbols increases from 27 symbols to 106 variant symbols, though, plus some additional symbols at 50% size. (They were alternate shapes because they map to the same SPICE device for simulation.)
Looking forward (I guess 2021 is probably too optimistic) to the alluded to superior KiCad release to neatly group and handle them…
).
