Thanks @bobc for your voluntary efforts on this library. Looks good.
These “revolutionary changes”, as you put it, don’t seem to change much at all other than eliminate the troublesome implicit connections. I don’t think there is any reason to wait, if the new library format allows additional features to be implemented then it can be revisited
if and when that ever happens.
Use an arc in place of the “bar”, 3 sizes of arc/bar for 2,3 and 4 inputs, but keep the symbol body the same size. Beyond 4 inputs, I’ve often seen multiple arcs used or one arc extended with straight lines as @davidsrsb suggested.
I do think it is rather ironic that the main reason for a separate power unit is to lessen “clutter” on the schematic and yet the power unit itself it so much larger than other units.
The main reason for separate power unit is to remove hidden pins, the hidden pins were designed to reduce clutter. Removing the hidden pins puts the clutter back, I can’t see a good way round that.
I could reduce the size of the power unit if I break some KLC rules
Because it was quick to do, I reduced size for 2/3 input AND/OR gates.
That’s true, but I meant the reason for having power units as opposed to the following example. This would maintain interchangeability, the power pins would move but that is fairly easy to deal with. Those opposed to this usually cite “clutter” as the reason.
I’m about testing the unit-interchangeable functions. So assumed we have an IC with two NAND and two NOR gates. Swapping the NANDs among each other and the NORs among each other is allowed. If the check “units are not interchangable” is off, nothing prevents me from swapping a NAND with a NOR, right ?
If you select units are not interchangeable you loose the unit interchange function for that symbol. (at least in the 4.0.2 stable release)
This is a small price to pay to get rid of the hidden power pins nonsense.
Sorry i seem to have understood it the wrong. (need more coffee.)
Yes if you have different gates in one part you need to select all units are not interchangeable otherwise kicad will assume it can interchange all units.
Sadly in the current format there is no way to tell kicad that gates 1 and 2 are interchangeable and gates 3 and 4 are interchangeable but not 2 and 3.
Hopefully the new library format will support this usecase. (But we will need to wait a bit to get this new format.)
ok, thanks for the clarification. To dwell on the subject, here another issue:
The file bel_test.lib contains a single component with a dedicated text “OR” for unit D. It applies for this unit exclusively. Later in schematic the text “OR” does not appear unit D. What is wrong ? bel_test.lib (863 Bytes)
The usual reason for mismatch between library and schematic is that the cache has got out of sync, or there are more than one library with the same component name. Restarting KiCad usually fixes cache issues, unless there is something in project-cache.lib, in which case deleting (or renaming just in case) that file helps.
As @bobc said, there could be a symbol name conflict. In kicad a symbol name needs to be unique over all loaded libraries. (otherwise the symbol from the lib with the highest priority is taken.)
More details:
When adding the unit I see the text “OR” in the preview. So there seems the correct library selected. Just try with the library file I have provided and see …
Nope, the preview knows what the library is, but the schematic does not, it uses the first one in the library list, so it depends on search order. It is probably finding the standard 74xx.lib before yours. This is very easy to verify.
In eeschema, right click over component, then select Edit Component->Edit (or E key)
Click “Test” button. This tells you which library eeschema is actually using.
@MarioBlunk An or gate has a different gate shape. I would advice you really change the outline to be correct. (or use the IEC symbols if you want text)
From wikipedia:
Hi there,
I got the point that KiCad takes the component from the topmost library in the library list. The “test” button shows me that indeed the component has been taken from the wrong library (at least not the one I want).
But why does it offer me to select the component from the lower priority library and even offer a preview ?
Is there a way to force eeschema to take the particular component from a lower priority library ? (The “select” button does not do the job, by the way.)
edit: I’m aware of logic symbols. The “OR” text is just part of evaluating and playing.
This is because of the way the library system and the file format are structured. As @bobc explained the dialog for adding a symbol has the information about which library is open. There is no place in the eeschema file format to store this information. This means once you add the symbol into the schematic this information does no longer exist.
Yes there should at least be an error message.
The future file format will (hopefully) contain the information from which lib a symbol came from. But i fear we will need to wait until v6. (I think it is not part of v5. But i could be wrong here.)
I don’t think so. you can move the lib in question up. (or simply rename the symbol.)
I had to share my last project with the guy that created the circuit. (Fortunately he finally capitulated and gave up on Eagle after the last license change.) To do that I moved the project specific cache library up to the top of the list. That allowed me to make sure he had the symbols I used and I knew which ones I was working from. Any changes are for that project only. That can be good or bad. Not much of an issue to alter the library, save, and then change to another library and save again though.
I used a polyline, but I generate it within the script, it’s too hard to draw by hand… KiCad automatically close the polygon to fill, so you can have the outline open. I had to adjust the other arcs so that they do not spill out of the outline.
