Is there a way to use generic editable power symbols in the schematics, instead of the un-editable library presets ?
AFAIK, every new power symbol has to be created as an unique, permanent, and immutable library item.
I don’t want to work this way, if I can avoid it.
I would like to be able to :
choose a generic PWR symbol shape in the lib.
edit the symbol name in the and have the connected wires get that name as net label
The reason :
for example : “+15V_Audio_Switched” . Such a specifically named item, definitively project specific, should not have to be in a library.
This just makes the number of power symbols grow over time, and the accumulated PWR symbols clutter the components chooser interface.
It’s already the case in the default Kicad libs : I just counted 95 PWR symbols in the 5.0 lib !
Right now power symbols do not take the netname form the value (=symbol name) field. They get that from the single invisible power input pin.
The only way to have something similar to what you want is to use global labels instead of power symbols.
With luck a better option will be implemented sometime in the future. The earliest it could be included is with version 6 which might still be two to three years in the future. Check if there is already a fitting feature request at the bugtracker. If not you might want to create one. (I doubt it will get a high priority as it is at most a minor inconvenience)
Currently, if you need a special power symbol for a board that you don’t want cluttering up your power library for other boards, put it in a symbol library in your project folder and use the project specific library tab of the symbol library manager to link to it. You can mix and match regular symbols and power symbols in the same library (what makes the power symbols different is in the symbol itself, not the library).
The per-project libs are normally not my way to go : I’m biased by years of using company-wide common libraries, with connections to other management systems and/or databases, but for the power symbols, it may be the only way to achieve what I’ve described.
I understand your point, but I don’t think I’m overthinking
Just a (proven) design method/habit that doesn’t translate out-of-the-box into Kicad .
Now, I’ve to adapt to the actual capabilities of the tool, indeed !
Another use case for the project libraries are with microcontrollers. If you want on your schematic the GPIO pins labeled how that project’s firmware will be using the pins, you can copy the µC symbol to the project library and then change the pin names there. Just remember to update the schematic if you change pin functions in the firmware… Granted, if you are changing the pin function in the firmware, you are likely to want to change the circuitry connected to that pin, so it isn’t like it is much of an extra step… Just remember that now that µC symbol’s other attributes are locked in that schematic if the global library’s symbol is changed (for example, new company part number to reflect a change in ordering).
That sounds like the problem of teaching old dogs new tricks. KiCAD isn’t Eagle, and will never behave like Eagle. Same is true for KiCAD and Altium. And OrCAD. And Zuken. And P-CAD. And PADS. It even departs from some “standard” ways that a host of Windows programs operate.
When I first picked up KiCAD I was crippled by my expectation that it should operate like something else. Over time, I came to accept that KiCAD was different. Sometimes better; sometimes worse; sometimes just different. I had to create a mind-set that accepted the fact that it was different, then learn the differences. It took longer to get accustomed to KiCAD than any other toolset changeover I can recall. Perhaps that’s a problem within KiCAD; perhaps it’s a characteristic of my chronologically gifted condition; perhaps it’s just how things are. It’s been almost 6 months since I have done a project in KiCAD, and I’m resigned to the expectation that I’ll have to re-learn many things about KiCAD when I pick it up again.
Keep an open mind, and concentrate on what the tool actually is, not what it isn’t.
During the past few years, I’ve mostly dealt with XMOS processors, and there are quite a few multi-role pins, specially on the multi-core USB+Ethernet chips.
Moreover, just like a FPGA, most ports are user defined (you don’t have a dedicated SPI port, and an I²C port, etc…).
For µC, it’s sometimes possible to add all the pin’s role (in abbreviated form) in the pin label. Can be really cluttered !
But in the XMOS symbols, we use the the crude X-D-- pin numbering.
To address the obvious lake of readability, I make an habit to add meaningful local labels on each pin connection, to make the intended use perfectly clear.
I even write text comments on the schematics sheet, if I feel it will help later.
And I produce a spreadsheet with annotated pinouts. In fact, I always begin here for that kind of component.
Anyways, in a professional context, a lot of documentation has to be written (and sometimes, it’s a chore !).
The same in large Open Source projects, I guess.
Granted, if you are changing the pin function in the firmware, you are likely to want to change the circuitry connected to that pin, so it isn’t like it is much of an extra step… Just remember that now that µC symbol’s other attributes are locked in that schematic if the global library’s symbol is changed (for example, new company part number to reflect a change in ordering).
).
