On 03:18 PM 22/01/2003 -0800, Buck Buchanan said:
Hi all,Yep - many people work this way. A read only (Sch Lib) field holds the company part number and can then be used as key to everything else.
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 part (a different footprint is not really necessary, or at least many companies don't go this far. They will have, for instanc, one 0805 footprint or maybe one 0805REFLOW and one 0805WAVE etc. I use this technique but am quite explicit in my footprint naming - eg SO20.3WAVE for a wave footprint version of an S0-20 with a 0.3 inch body.
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?
Not that I know of.
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.
300 should not be an issue I would think.
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.P99SE does *not* support VB scripts. It has its own internal Client Basic macro language (looks like traditional BASIC essentially). But this is very limited in what access you can get to internal database data. For deeper work you need Delphi (V5 for P99SE SP6).
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.I wrote a server that allows you to update all non-readonly fields for Sch components from an Excel spreadsheet. This includes footprints etc. It works *much* faster than the DB linking feature in P99SE. It can key off essentially any field but is most useful when you have the unique company part number in a SchLib (read-only) field. This allows you to bring in all the descriptions, footprints etc from the external Excel database.
Server can be found at http://www.considered.com.au/Protel01.html
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.Delphi is needed for any significant work at the component level - either that or some small servers (in Delphi) that can expose the data you want to the Client Basic scripts.
Works to its limits and is very slow. It does not allow the footprint to be updated, for instance.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.There is one issue that has not real upstream solution, it can be found by downstream checking but this is not as good as a system that prevents an error in the first place. P99SE does not allow the part fields, value, footprint etc to be locked. So ... if another user (or yourself at 2:00 am on a rush job) makes an edit to one of these fields on the Sch rather than by replacing the component with the desired one from the library, you have got an inconsistency between the data in the component fields and the data in the data base for that company part number. This can be checked for in downstream processing but you can see that it is not ideal. DXP allows much better parameter locking at the lib level - so helping to prevent this sort of error.
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.
Bye for now,
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
* To leave this list visit:
* Contact the list manager:
* mailto:[EMAIL PROTECTED]
* Forum Guidelines Rules:
* Browse or Search previous postings:
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *