Re: gEDA-user: Parts!

[Levente Kovacs <leventelist@xxxxxxxxx>]

On Fri, 15 May 2009 13:32:12 -0500
Bill Gatliff <bgat@xxxxxxxxxxxxxxx> wrote:

> I think we're in violent agreement, but might be talking about subtly 
> separate things.
> 
> A given device e.g. a particular transistor may be available in one
> or more specific physical _packages_, i.e. TO220, DPAK, etc.  If you
> had a collection of such devices in different packages, then they'd
> be different part numbers--- but you'd probably capture the basic
> name of the transistor device in the description fields of your
> database i.e. "2N7002", "n-channel", "transistor" so you could later
> ask for "a transistor in a TO200 package, any vendor".  You'd have
> two or more rows with that same description (hence the need for a
> description convention), each of which differed only by the package
> and part number for the device(s) you bought.
> 
> There are several PCB layout _footprints_ that are compatible with a 
> TO220 _package_, but that's information that's tied to a specific
> part number only through what package the device referred to by that
> part number came in.  PCB doesn't care that it's a 2N7002, or even
> that it's in a TO220 package--- it just wants to know what footprint
> you want, and you want to make sure that the footprint that you tell
> it to use  will actually work with the package the physical device
> came in.
> 
> So your device table needs a package field, which reflects the actual 
> physical package the device came to you in.  Then you need another
> table that maps package types to compatible layout footprints.  Then
> you select from that list of footprints based on the characteristics
> of your circuit board.
> 
> (Actually, since Fairchild has their own naming conventions for 
> packages, which will be different names but the same physical 
> characteristics as those offered by other vendors, you might want the 
> schema to be slightly more complicated than the above.  You could
> even have a schema that fills in some of the package and other
> information for you based on the header and footer of the part
> number.  But I digress).
 

OK. I understand, but I guess it doesn't worth the trouble to implement such
complicated stuff. To be honest, I don't see why one would combine some device
coming in different packages into one part. I've seen some commercial
implementation of this, but we rarely used it. I have one example in my mind.
It's the IRF540 hexfet. It is in TO220, but there is a DPAK2 package. I think
we could live with it if it was two different part, or whatever we call it.

On the other hand however, I have a few footprint variant so far for certain
packages. With the current architecture, I don't know how could we implement
a footprint selector at gschem level. Maybe my dbsym_update could be
interactive... but it is awkward.

> >> I don't think you are using your schema very effectively,
> >> however.  I think your description field should at most contain
> >> the word "resistor", since you are capturing things like footprint
> >> and value in other fields. 
> >
> > That is why I have the category and subcategory tables.
> >   
> 
> Yup.  But I'd give them more specific names, so that you don't miss a 
> search because the "resistor" was in a field other than the one you 
> searched in, perhaps due to an entry error.  It's a taxonomy thing.

Yup. That is why it would be nice to have some UI, which looked up the
category and subcategory fields to names, and you have the "resistor" string.
Or at least, I planned so.

> > Well well. This system is still a "quick and dirty hack"... :-)
> > What you can do is a query for category=1, subcategory=1,
> > value=10R. That is what I do day by day. However, you are probably
> > right. This is my first SQL database, and one may see that I don't
> > have experience with it. :-) 
> 
> Me neither.  I've done only two or three myself, but I've looked over
> a lot of shoulders and had to deal with a lot of databases that
> weren't set up to my liking.  :)
> 
> 
> > The next step with this system is to write some (G)UI for those
> > tables. I usually use the phpmyadmin interface. It is OK, but could
> > be better. Or even better... integrate it in gschem.
> >   
> 
> Gschem and PCB could both incorporate sqlite, and then we could set
> up a community database somewhere that as we bought parts we could
> enter the part numbers/packages information into.  And then as we
> created footprints, we could put those into another database.  Then
> later on, when I had a particular part number (perhaps from a
> device=) then a tool could show me a list of compatible, predefined
> footprints.
 
> Kind of like a next-generation version of what gedasymbols already
> is. Or could be.
> 
> > Any volunteers? :-)
> >   
> 
> Not me!  I'm more of an "idea guy", especially when it comes to 
> databases.  :)
> 
> I would be happy to supply the IP address, however.

:-)
 
> b.g.
> 
> -- 
> Bill Gatliff
> bgat@xxxxxxxxxxxxxxx
> 
> 
> 
> _______________________________________________
> geda-user mailing list
> geda-user@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
> 


-- 
Levente Kovacs
http://logonex.eu



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user