kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #16406
Re: Some schematics library structure ideas
2015-01-14 18:53 GMT+03:00 Andy Peters <devel@xxxxxxxxx>:
>
> > 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.
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>
References