Eescheema GUI feature request - basic device button


#1

I thought I’d toss this idea up here to get feed back before I actually make a real feature request on the repo.

IMO, Eescheema could really use a 'Place Basic Device" to go along with the “Place Power Port” button. Most of what people are doing on the schematic is putting down a few large semiconductor parts, IO, a few power rails and a ton of jellybean capacitors and resistors. I think it’s safe to say that probably 80-90% of the parts placed in schematics are bog standard R and C components.

The Place Power Port button is really useful - it means we don’t have to place a part, open up the Power accordion and start searching from there. Just click the Place Power Port button and you’re there.

But when you place plain R and C components, you’re still having to drill down into the part menu, scroll down to Device and then go through a long list of obscure parts to get to R or whatever. (This is especially offputting to newcomers to KiCad who have to spend a ton of time scrolling through the huge parts list, trying to figure out where a resistor is at. I recall I spent probably at least 15 minutes the first time I used KiCad. It did not give a good first impression.)

What I think should be added is is a Place Basic Device (or common device or part or whatever) button that operates similarly to Place Power Port. When you click it, it has a short list of the most commonly used parts. My suggestion would be [C, CP, D, D_Schottky, D_Zener, L, LED, POT, R]. This way you can just pull up the components that make up 90% of schematics quickly and without scrolling through accordion popups and long lists every time.

If the implementer is feeling their oats, the list could be editable so an individual user can add and remove parts from the quick list to fit their individual needs.

What do people think?

Edit - I wanted to add the idea that the best way to pick out the parts on this list would be to just go through GitHub, collect data on all the KiCad projects out there and sort out the 10 (or whatever) most commonly used schematic parts and used that as the default quick list.


Atomic or Not? What are you DOING with KiCad?
#2

Use HotKeys?

Open Eeshcma, on the keyboard press the “a” key (release), then the “r” key (release), followed by the “enter” key.

Also, one can simply press the “Insert” key to add another item of the last part.

For changing parts, it is simple to hover the mouse cursor over a symbol already on the board, and press the “c” key.

If you absolutely must have a graphic to click, then I suggest creating a new library, name the library “0_Parts” and place the components that YOU personally want.


#3

By that logic, we should get rid of the Place Power Port button then. You can just hit ‘a’, ‘gn’ to get a ground symbol or ‘a’, ‘5v’ to get a 5V power rail. Hell, most of the buttons in Eescheema could be eliminated and we could just tell people to use the hotkeys instead.

If we’re going by how often the average user will use a given feature, the GUI button for placing a not-connected flag (which also has a hotkey) is certainly going to be used far less than something like this.

The vast majority of users prefer a GUI interface. Especially new users and occasional users. If KiCad is going to expand the user base and encourage more users, there needs to be some thought given to industry standard GUI design principles. Matching the most commonly used user operations with a GUI element is definitely one of those.


#4

I always wondered why this is there. Maybe in early versions power symbols really where something separate of other symbols. (Or the developers knew that the current implementation is just a hack and always planned to implement them in a better way but never got around to do it.)

I disagree here. I think everyone who uses any program for more than one project will learn the shortcuts. It is always a good idea to have a good gui for beginners though. (Maybe i am the exception here. I used vim until i discovered atom. I even thought about switching to emacs. F12 opens a fullscreen terminal on all of my systems.)


#5

I’m not an expert at this, and sometimes I read conflicting information and don’t always know the true truth.

However, it is my understanding that these “symbols” are very common in use, and do NOT have a “footprint” associated with them. As not having the same software library requirements, these items got separated to make writing the initial source code easier.

The PWR FLAG is also included in this section of code, and AFAIK the only reason for the power flag is for the DRC source code to function without error.

And, I may be wrong on some or all of the above. I’ve seen discussions with different answers and that is my understanding as I applied my own mental filters. If anyone can correct me on any point, I’d appreciate it.


#6

I’m going to have to disagree back. I have to use dozens of different programs in my work and hobbies. I have no desire to have to memorize the different hotkeys for every single one of them. Decades of UI research have definitively shown that users overwhelmingly prefer GUI interfaces as they do not require the cognitive overhead of having to remember various arcane command-line or hotkeys for a program.

Yes, a regular user that is using KiCad all the time will learn and love the hotkeys. But I’m also willing to wager that is not the majority of people who would use KiCad. There are tons of hobbyists that are going to use it for a couple weeks to design a PCB or two and then put it down for 6 months before using it again. They are going to use the GUI. It makes sense to streamline and optimize the GUI for that large user group. It’s not like making improvements to the GUI requires the removal of hotkeys.


#7

A number of resistors and capacitors on a board often are of the same type, using the same footprint and 3D model. A rational thing to do then is to assign footprint and 3D model to the first one of the kind, and then copy that to all the other locations on the schematic. It saves a lot of work.


#8

Such a function would be nice to have (I think) … but I think it really makes sense if it is coupled with a tag on the components in the lib. What I mean is this: When we have the new format, we should enabled marking them as “BASIC” (or something like that, much the way Power-symbols are marked). Then the special button should display a list filtered for these marked symbols. This way, if you build your own lib, you can mark whatever you wish … e.g. your super-standard 0805-100nF-cap … your your belovedPackaged-1N4148-derivative

Best,
JAN


#9

How about something like a component bin (see the right side)? When you first start designing a schematic you add your most used parts to the “component bin/cart”, then you simply drag&drop them from there. This would also solve the discussion of what should be in the “basic device” list.


#10

Would also be a good solution (I think) and does not require changes in the lib :-)))


#11

I don’t understand the request here. You open the part selector and type the name of what you’re looking for, then hit enter. The “basic devices” in the library have really short, simple names, so that’s a piece of cake. I don’t see how hotkeys even factor into this. Typing a query into a search field isn’t “hotkeys”…

As for it logically following that the “power port” shortcut could be removed too - I would do just that if I had the authority to make that decision… again, you just open the part selector and type the voltage you want. And if you want to browse them, you can just type “power” to filter the browser.


#12

Also there is the history section.
As soon as you put a symbol into your design it is listed there. In most cases this history is filled very fast with what you need in this design.


#13

The current push towards “atomic” parts kinda muddies the water here. Resistors and capacitors would have preassigned values and part numbers. Even copying components becomes a problem.


#14

There is no such push among the core KiCad developers that I am aware of - I think I am the only one of us who is in favor of that, and I have little to no say in the library management aspect (especially considering I deviate so far in that area from the others).


#15

Can you describe a little more about this push to atomic parts? This and other discussions on here have been making me think about how components would really benefit from more of an OOP-style data structure and I think that might be along the lines of something like atomic parts. Is there a good discussion thread to reference?


#16

The “push” comes from users (like myself) with a professional background. There are dozens of threads here which end up devolving into whether one should use CvPCB or whether one should build a library with “fully described” or “atomic” parts, where the schematic symbol includes the footprint and a part number.

With atomic parts, the assumption is that the user builds his/her own libraries, and makes sure that the part numbers, the footprints, the symbols are all correct. This makes BOM generation a LOT easier because there is only one step. With the CvPCB flow, the BOM doesn’t have anything but generic information, so the designer has to go and match the generic parts with real things that can be bought.

Suffice it to say that the developers are leery of removing the flexibility afforded by CvPCB (assigning footprints to symbols after finishing the schematic). The current set-up allows for users to choose either workflow, so the arguments are mostly philosophical.


The point, I think, is that if the user prefers atomic parts, the idea of the “basic device” button is rather pointless. What is a basic device? Let’s start with capacitors, and the various types of capacitors one might use in a design. They’re no longer so basic, right?


#17

You would not want to have a capacitor symbol for each type of footprint like in Eagle, and as has been written above there is no push for it. Personally I never use CPCB; I assign everything from general symbol libraries in the schematic editor and then at some stage before I lay out the board I assign footprints to the symbols in my schematic. By atomic parts I would understand that there for instance was a footprint for every single resistor value, with an associated 3D model with realistic color bands or other markings on the part indicating the value. This quickly breaks down as the number of footprints to select from becomes enormous, and yes my strategy would not work for that. However once a symbol has been added to the schematics, I can add or edit the footprint and 3D model assignment to the first kind of the part in the schematic editor without changing the symbol in the library, and then keep copying that part. This also works if there originally was an incorrect footprint assigned to the symbol. There is no need to make a special symbol version in the library for it, although for special parts that can also work.


#18

I agree that if it were a more inherently atomic part model in KiCad, it wouldn’t make much sense to have a basic device button. But given that the schematic portion of KiCad is built to be more generic, it makes sense to be able to just drop in generic parts into the schematic as easily as possible and then fill in details as necessary.

Regarding the atomic/CvPCB argument, I’m sure this ground has been covered very heavily, but I think that it’s a false dichotomy. Really both approaches fail to capture what is actually going on.

Really, there’s several sets of data associated with a part that are all at least somewhat orthogonal to each other:

  • the symbol - this captures the high-level logic associated with a part - e.g.: all 74HCT245s will be the same in this regard - 8 A<->B level shifters, an enable, a direction and power ports.
  • the footprint - The physical layout of a part, both in terms of 2D board layout as well as 3D models.
  • the electrical characteristics - pin capacitance, max/min voltages, signal propagation times, etc. This is a logical place to also store manufacturer info as the electrical characteristics are generally tied to a given manufacturer part number.
  • The BOM - info about supplier price, availability, what the user has ordered in the past, future order planning, etc.

Really, any atomic part strategy that captures all the useful info has to tie these 4 things together. It’s not just a footprint-symbol linkage with a part number tacked on. Eagle basically does that and I know that trying to capture the intricacies of buying parts from different suppliers, dealing with varying electrical properties on different models, etc was terrible.

If there were a sufficiently well-populated set of default libraries for these 4 datasets, even existing tasks like linking footprints to symbols is going to be taken care of in a lot of cases. E.g.: I pick out a 74HCT245 part for my project. KiCad can then follow the symbol-electrical/manufacturer links to give a list of different 74HCT245s available from different manufacturers with notable differences in electrical properties as well as the available footprints for each. I put some edge conditions on the acceptable electrical characteristics and select an available footprint from the manufacturere parts that match my criteria. That takes care of the footprint association and now I’ve got project-level data that allows constraints on the specific manufacturer part numbers that match what I want. When it comes time to deal with part ordering and management, it’s easy for Kicad to just give me a list of compatible manufacturer part numbers and can search across suppliers to give me price breakdowns and availability all collated in one place for me to look at. I can also use KiCad to keep track of past part purchases to have a complete supply chain management system built right in.

Also, having things like electrical properties brought in as a separate units allow KiCad to add a bunch of very useful functionalities. For example, you could have the individual signal paths from a chip with characterized capacitance and driving power going to another chip with certain rise-time requirements. A built-in SPICE simulator can then easily tell the user if a trace connecting those two pins is too long, generating too much parasitic capacitance to meet the receiver’s rise-time needs. Kicad can then look at alternate version of the chips with different drive power or rise-time requirements where the other electrical characteristics meet the user’s requirements and selected footprint and list out suppliers, availability and pricing.

I realize that this is such a radical reworking of how Kicad would work that it’s never going to be implemented. Even if the devs were willing to retool the program logic to that leve, it would require large numbers of automated data sources from the manufacturers to get all that data and make sure it’s up to date. However, I think that it’s still valuable to rethink the whole problem in terms of each part being decoupled into many datasets, not just a linked footprint and symbol.


#19

That’s the idea.

This would be a waste of time. The reason some use atomic parts is that they use kicad not only to design the pcb but also for the material management. Atomic parts help there by having the order numbers or some house part number already assigned in special symbol fields.

That’s the drawback behind having every part as an atomic part.
I don’t use atomic parts for resistors and other devices where the value is the only difference. My house part number has the value of the resistor in it. This way i theoretically could use a python script to generate the correct house part number from the fields in my resistor symbol in combination with the value. (Currently i just fill out the hpn by hand for each resistor value i use. But i plan to create such a script as soon as i have a bit more time.)

But for parts like integrated circuits, or even diodes i currently use atomic parts.


#20

I worked at two employers where there was indeed one library part for each individual resistor value. Hypothetically, it seems unwieldy; in practice, it was manageable, mainly because it could be sorted by resistor value and not every possible E96 resistor value was in the library (or even in the ERP system).

That said: there are ways to create an atomic library system which allows for such things as resistors. Here is how it’s done at my day job. We use Altium and have a single company standard integrated library, and I took this idea and use it for my Kicad stuff.

Every part used in a design is assigned a house part number. A symbol for each part is made. The symbols all have a PN (for Part Number) field which is populated with the correct number. A footprint and a 3D model are found or created, and the new part is compiled into the integrated library. This works well enough for op-amps and other linear parts, digital parts like micros and FPGAs, as well as discrete transistors and whatnot. If my design requires an OPA1652, that is what I place on the schematic. We do not place “generic dual op-amp” on the schematic and figure out what real part we want to use later. If we decided to use a different op-amp, the schematic is changed – the old part is deleted and the new part put in its place.

Now, resistors. For suchlike parts, the Part Number is family part number. One symbol (with footprint and 3D model) is created for the entire family. The part value field is populated at schematic entry time with the desired value. When the BOM is generated by Altium or Kicad, it obviously includes both the part number and the value, and a simple post-processing program sucks in the BOM, and using the part number and value it builds a full family part number and looks that up in the master parts database to generate something the buyer can order.

There is a rule with family part numbers: only one variable is allowed. In the case of resistors, it’s obviously the value. That means we have separate symbols (and family part numbers) for 0805 resistors, 0603 resistors, 0402 resistors. 0603 1% resistors are a different symbol from 0.1% resistors. So, basically with a little thought and a post-processing program, we’ve reduced the number of resistor symbols in the library from a metric shitload to a half dozen.

As for different 3D models which show the resistor value as the correct color bands, or perhaps imprint it on top of the 0805 resistor, well, that’s ridiculous eye candy and a waste of time.