All Forums  Help For Easy-PC Users  Libraries and Components  New Library Manager Functionality - a possible way

Note: You must be registered in order to post a reply.
To register, click here. Registration is FREE!

Screensize: 640 x 480 800 x 600 1024 x 768 1280 x 1024 UserName: Password: Format Mode: Basic  Help  Prompt  Format: Font Andale Mono Arial Arial Black Book Antiqua Century Gothic Comic Sans MS Courier New Georgia Impact Lucida Console Script MT Bold Stencil Tahoma Times New Roman Trebuchet MS Verdana   Size 1 2 3 4 5 6   Color Black Red Yellow Pink Green Orange Purple Blue Beige Brown Teal Navy Maroon LimeGreen Message: * HTML is OFF * Forum Code is ON Smilies [quote][i]Originally posted by KevL[/i] [br]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 [/quote]   Check here to include your profile signature. Check here to subscribe to this topic.