← Back to team overview

kicad-developers team mailing list archive

Re: Some schematics library structure ideas

 

> On Jan 10, 2015, at 10:35 PM, Fat-Zer <fatzer2@xxxxxxxxx> wrote:
> 
> Hi, I've got a some ideas how to improve some parts if kicad schematics library. 
> 
> 1. A common schematics:
> There are a bunch of compomets with nearly the same schematics but different in pin order/numbers. Also there are several variants of components which are supposed to look the same e.g there are 4 or 5 different OpAmps images. (and as I was told none of them comply current kicad library conventions). The same thing about transistors.
> 
> So it would be nice to have only one image and map it to the concrete component with pin reordering/renaming.

I'm gonna get on my "CvPCB is a disaster" soapbox again.

A component with (nearly) the same symbol but with different pin ordering or numbering is a DIFFERENT PART.

The MUCH better solution would be to have different schematic library symbols, each with the correct footprint already set in the Footprint field. So the common case is the same part which comes in DIP-8 and SOIC-8. Thus your library will have, say, an OP134PA and an OP134UA; the former is in DIP and the latter is in SOIC-8. Now you place the desired part on your schematic, and everything is done for you. You don't have to select the footprint after the fact before you do the layout. And if you're really clever, you'll put a vendor (or in-house company) part number in the schematic symbol, too, and this ensures that the part you place on the schematic puts the correct footprint on the board and you order the right part!

Spend the time setting up the libraries in advance, and you do this all once. If you go the CvPcb route, you end up doing the same work (part selection, symbol/footprint marriage, etc) for every board. That's too much work and inevitably results in errors.

Honestly, at every company for which I've worked, there is a company standard library which includes vetted parts, and everyone uses only that library. That library is set up as I describe above. There's nothing worse than ordering a batch of boards where one footprint was used for a part only to receive the parts in a different package.


> 2. Different images of the same schematic component.
> There are already such variants for some common components like CP, also there are "small" variants for some components.

Who cares about a symbol variant? Pick the one you prefer and use it. 

> In both such cases we can keep information about the component in single symbol.
> Also as a bonus we can easily support both IEC and US symbols and use it in some other cases.

Why? I think that a lot of advanced users will choose one symbol type and leave it at that, and not go the route of switching between one symbol variant and another.

> 3. To store pin number of component in additional field.
> Now cvpcb guesses pin number according to the pins displayed on the schematics. Which is wrong if some pins are not connected/not present in the schematics at all.

That problem is solved by not using CvPCB at all, and doing as I suggest above.

> It would be great to store an overall pin number of component too (as an option).

For what benefit?

---------------

OK, I realize that the point is to somehow improve library sharing. I think that's an excellent goal. But I also think that at some point, it breaks down. Unless all shared libraries adhere to the same standards, inevitably you have problems. And I know you can't please everyone, so perhaps the correct way to go is to support the hobbyists who don't want to create a complex library system for a small design, and the advanced/professional users will build company/vetted libraries.




Follow ups

References