Hi all,
I have several questions oriented around the general theme of library
organization and component data tracking (part #, distributor, price,
etc.). I don't expect anyone to answer all of these, but opinions
regarding any points here are most appreciated. One way or another, any
re-organization will be labor intensive so we're looking for "gotcha's"
first. We're using Protel99SE SP6.
As we all know, component data tracking in Protel is awkward.
Currently, we're using a convoluted procedure of tracking data in Sch
Part Fields and importing/exporting the database via the Protel
spreadsheet editor (performing sweeping changes in Excel external to
Protel). While this does work and allows speadsheet format editing,
it's labor intensive and leaves the door wide open to major errors upon
re-import. The list of work-arounds involved is endless. We'd like to
come up with new techniques that are as bullet-proof as possible.
We're considering changing to a system where each Sch component's data
is tracked in its Library Fields. This means that each value of a
resistor (for example) will have to have a different Sch library entry.
A benefit here is that we research the part info just once when we
make the Sch component and that data is always brought to the schematic.
Furthermore, each component (in Sch lib) will have only one footprint
assigned to it (with the same name as the Sch component). A separate
footprint then exists for each Sch component. This gets around several
possible errors that can occur when one footprint is assigned to
multiple Sch symbols. Obviously, a major drawback to this technique is
that we make a zillion footprint entries - many identical except for the
name. That's not quite as bad as it sounds as we don't use *that* many
different components.
The main question regarding this technique: Is there a limit on the
number of symbols in a schematic library or footprints in a PCB library?
We don't want to get mostly done to find that Protel has a weird bug
with too many components in a library. I would guess we're still
talking fewer than 300 components per library but I'd be interested to
know if there's any amount that's problematic.
We've also been considering use of software called Parts and Vendors
(http://www.trilogydesign.com/main.htm). Does anyone out there have any
experience with this or are currently using it with Protel? It appears
to cross reference to your own in-house part # and allows many component
data tracking options. I don't know yet if it can be linked to Protel
other than through more manual interactions with the spreadsheet
function. It looks like it will take notable time even to evaluate this
software so I thought I'd ask here first.
How about the Visual Basic scripts that Protel supports? Although doing
complex macros seems like a big undertaking, is this how many people are
solving these problems? I've heard about one script that does something
with library fields but can't remember who made it or what it actually
does. From the looks of it, knowledge of VB seems mandatory for getting
into this side of Protel. Any opinions or info on scripts and their use
is invited.
And the dBase database linker: does it even work? Does it work *well*?
Or is it an unusable feature like the 3D PCB viewer. We're wondering
if switching to dBase and using the linker is a better overall alternative.
I realize lots of this has been covered here in the past but it was hard
to narrow down the archive search engine to bring it all up.
In general, any commentary on component data tracking or related is
greatly appreciated - how you do it, would like to do it, whatever.
Thanks one and all!
Buck Buchanan
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
*
* To leave this list visit:
* http://www.techservinc.com/protelusers/leave.html
*
* Contact the list manager:
* mailto:[EMAIL PROTECTED]
*
* Forum Guidelines Rules:
* http://www.techservinc.com/protelusers/forumrules.html
*
* Browse or Search previous postings:
* http://www.mail-archive.com/proteledaforum@techservinc.com
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
- Re: [PEDA] text editor buglet Matt . VanDeWerken
- Re: [PEDA] text editor buglet Dennis Saputelli
- Re: [PEDA] text editor buglet Dwight Harm
- Re: [PEDA] General component data tracking and... Buck Buchanan
- Re: [PEDA] General component data tracking... Ian Wilson
- Re: [PEDA] General component data trac... Ian Wilson
- Re: [PEDA] General component data trac... Christopher Brand
- Re: [PEDA] General component data... Ian Wilson
- Re: [PEDA] General component ... Christopher Brand