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:
* Forum Guidelines Rules:
* http://www.techservinc.com/protelusers/forumrules.html
* Browse or Search previous postings:
* http://www.mail-archive.com/proteledaforum@techservinc.com
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to