[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: Parts!
Levente wrote:
> Bill Gatliff wrote:
> [...]
>
>> Gosh, I think it almost does. You have a footprint column in your
>> device table, and it seems as though only one footprint would apply to a
>> specific device--- an 0603 resistor is always going to use the 0603
>> footprint. So if you had resistors with other footprints, they'd be
>> different entries in the table, right?
>>
>
> Right. Wrong! What about a TO220 transistor? You have standing and
> laying version, I do have an SMD version too. You may have a footprint
> for other technologies of soldering... such as reflow, wave, etc. You
> may have different resist opening version... etc. I think it might be a
> good idea to have a separate footprint table for footprint variants.
>
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).
>> 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.
> 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