| T O P I C R E V I E W |
| KevL |
Posted - 26 Aug 2010 : 12:31:08
Having grappled with many of the problems outlined above I will now outline what I would change if there was such a thing as an EPC SDK.
1. Tools for fixing the mess present in my libraries.
Having a whole bunch of components in various libraries with non identical primitive styles and drawing standards is a real pain and is wasteful of time trying to fix them. It makes EPC (which is very reasonably priced) unnecessarily expensive to run.
My solution to this would be to add new functionality.
a. Add a button which allows all schematic symbols and PCB footprints to be taken from the respective libraries and dumped on a very large schematic/PCB workspace. This should allow 1 library, all libraries or selected items from 1 library to be automatically placed. The placing function should put the parts on a large grid so that no parts overlap. They should, of course, have component origins aligned with the current user working grid. The auto place algorithm might be pressed into service here though it should just plonk the parts down in neat rows and columns for ease of location of parts. Place them in library list order for example. No need to try to fit them in minimum area or anything algorithmically challenging.
b. Provide a tool to decompose the library shapes into primitives BUT with primitives labelled as belonging to a group named after the symbol/footprint.
c. Provide access to the goto bar in this editing environment - and in the case of Footprints allow items to be filtered by visible layer. Excellent use of the primitive styles lists in this dialog can be made. I can for example select all line types called LineStyle0_1.
So now I can effortlessly place all symbols and footprints in a suitable editing space and have them appear as grouped clumps of primitives. In the case of PCB items I can select all lines on the silkscreen layer and set them to have style name - SilkscreenOutlines - or whatever. Using the goto bar to display primitives I can route out and eliminate any spurious styles that have crept in and generally purge the underlying technology file of untoward style definitions. Similarly I can set the fonts and characteristics of the S, R, and V symbols once and for all and make all the library items placed in a schematic/PCB items behave the same way in an editing activity that can be measured in minutes rather than weeks. I can add or delete primitives to from a group to modify components.
d. Provide a new button to do something with the naming of pads. Now that it is possible to put a whole library (or several libraries) worth of footprints in 1 file with an underlying technology file that has full knowledge of all pad style names - it ought to be possible to have a renaming / reordering function to remove names like PadStyle487_1_1_1. Not sure what the pads should be called but suspect my example can be improved upon.
e. Provide a button which reads the file and writes grouped items back into the library file as proper symbol/footprints. Any item tagged as belonging to R 0805 etc gets written to a footprint item of the group name - and what is more assumes the characteristics of the technology file underlying the editing file - except for working area size (which should be set to best fit for each item).
So the above new tool set would make library management really quick and easy and there would be easily enforced consistency. I also don’t think much new code needs writing just a few new dialogs, buttons and a few lightweight scripts to reuse existing functionality. Decomposing/reforming library items into/from groups would seem to be the only really new functionality and that doesn’t sound too hard.
This tool set would also provide the ideal opportunity to get EPC working in a best practice manner. Layer names, layer properties etc can be standardised to a “best practice” way of working - whatever that turns out to be.
2. Change the way that Styles work in libraries.
It is far too easy to have new styles appearing when what was needed was a few styles being used for consistency. Except for pads of course where new styles of pads need to be whatever that datasheet says they need to be. But even if this cant be achieved then with the above tool set at hand the problems can be fixed easily. Make the user aware that a new line style, font definition etc is being specified when the item is saved. At the moment one gets the notification that the technology file has changed do you wish to overwrite? This is insufficient and I’m still not really sure what happens when a new style gets added to the tech files underlying a library. Does it get added to the tech file (say Footprint tech file) which is the only one I use for footprints and next time I edit a different footprint will the modified tech file transfer the added style into it? Not really sure. I asked a question on the forum re this and no-one seems to know. Again the above tools help here because finally we can have some confidence that the styles present in the re-formed libraries will be only the styles present in the underlying tech file from the whole library placement editing operation.
3. Library Item Control
Many users have drawn attention to the problems they currently have with components acquiring new symbol/footprints when loaded into EPC. This is because the symbol and footprint info is stored separately and is referenced only by name. Put two footprints in the search path with the same name and the first one found is used - even if it is not the intended one.
This has been discussed and two main solutions have been suggested. The reason it has not been fixed already is that it is really complicated.
a. Embed symbols and footprint info into components.
This has the problem that there will be massive duplication. If a symbol or footprint needs changing then since it is duplicated throughout the library then the editing task is now multiplied. Inevitably there would be differences emerging between what should be identical symbols/footprints.
b. Adopt a database structure for symbols, footprints and components
This might well fix all the problems but if the database becomes corrupt then all is lost.
There is a solution which might fix all problems and requires only a minor change to the existing library arrangements.
Currently we have
Symbols.lib
Footprints.lib
Components.lib.
Create a new library format of the type Iain has advocated. Call this Integrated.lib. Give it a new filename extension and give EPC the ability to create this new format by combining the information from all 3 of the standard formats I.e. A new button called form integrated library. Components are created as they are at present and components still call the footprints and symbols by name as they do at the moment. So we have no duplication. Running the form integrated library function translates the info into Iains ideal format with all parts effectively nailed down. But we can still change a footprint once and when we create a new Integrated library all instances of that changed footprint get changed and a new integrated library overwrites the old.
Then give the library manager the ability to look at only integrated libraries or use the old format at user discretion. I think this fixes the problem and doesn’t create any new problems. So when having to deal with multiple customers libraries they can be placed in a temporary directory and an integrated library can be made from them. This can then be moved into the library search path. Even if there were duplicate component names in 2 integrated libraries there would still be no problem as symbol/footprint correspondence is still guaranteed.
Might work...............
K
|
| 2 L A T E S T R E P L I E S (Newest First) |
| KevL |
Posted - 27 Aug 2010 : 15:18:05
I think the integrated lib format is exactly what you want. I'm jsut suggesting a way it can be created from the existing format component lib with the press of a button. Once you have that lib you have locked everything down and your problem is fixed.
Re different manufacturers recommending different footprints for say sot-23 packages. This is because there are many flavours of such parts and indeed the IPC specify multiple sot-23 patterns. We have multiple sot-23 patterns defined in our libs and when making up a component we select the one from our footprint lib which has the nearest physical size to the package under consideration. This is easy for us to do because all our footprints have a mechanical drawing of the real package outline so we simply relate the datasheet to see which footprint is best.
Haven't been caught out yet by this issue. Might have been lucky though.
Yes for different solder processes you need different land patterns. We would currently bodge this issue by having multiple footprint libs with identically named footprints with differnt pad sizes. Placing these carefully in the lib search path (and using the way the libs work at the moment) then pcb patterns change accordingly. Have to say we dont use this often as our processes dont change.
Kev
|
| Iain Wilkie |
Posted - 27 Aug 2010 : 08:34:56
Kev....
Duplication is not a problem .... In the solution I am proposing (the all in one component) ......Take any generic footprint ... and you will find that 9 times out of 10 each manufacturer will specify a different pad size/shape on their datasheet .. also wether the reflow or wave soldering is used etc etc., so you sometimes need to adjust/edit the footprint/s when creating the component.
So now each component can have a host of footprints all slighty different. This why you simply cannot alter footprints and then pass that new edited footprint back into all other components in a database that use the same generic footprint.
Iain
|
|
|
