| T O P I C R E V I E W |
| KevL |
Posted - 26 Aug 2010 : 12:28:11
Currently the library management functionality and library organisation of EPC is its weakest feature.
It suffers from a number of issues.
1. Duplicate footprints and the in-ability to control which footprints end up on the PCB
Iain’s problem - I.e. he cannot control how EPC chooses which symbols to load when one or more libraries are loaded - and loading multiple libraries is essential when dealing with his customer’s schematics and libraries. His solution which involves duplication of footprints in components will correct this problem - but would create others especially when (2) is considered.
2. Difficulty of being able to control which styles for lines, pads etc, layers, configurations (colours, grids) are used in symbols. A symbol/footprint assumes the settings in the technology file underlying it at the instant of creation (I think). The fact that the technology file changes over time means that symbols/footprints end up all having slightly different settings as new parts are added to the library.
There is currently no way of policing a consistent set of these settings and once it has been observed that incorrect styles have been applied then the only way of fixing the situation is to manually open each and every affected symbol and painstakingly change them. When a single set of libraries are in-use in a multi-seat setup and a number of engineers are involved in the creation of symbols - then library styles rapidly become a total mess. Having to open large numbers of symbols for corrective editing is a tedious, un-necessary, expensive operation. The irony of the warning message - you are about to open many symbols - this may take some time - are you sure? - is not lost on me.
The issue of styles always strikes me as something which sounded like a good idea and is logically consistent (from a software architecture point of view). It lends the utmost in flexibility. One can override styles at a number of levels in a hierarchy and thus it is possible to have the almost complete control at the lowest level. For better of for worse. I’d suggest the latter.
In actual practice this has worked about as well as Microsoft’s implementation of formatting styles in MS Word. That is to say it doesn’t work well at all. To the point where MS has a button so that you can delete all styles in a document and re-apply styles to sort out the mess. You need to use this where a number people contribute to a word document and style proliferation has occurred. Try to have a standard set of styles defined for all users on a network say. Good luck with that… each users style sheet needs to be accessible to Word and attempts to have a single read only style sheet don’t work. Similarities then with EPC technology files. The “clear all styles” button in Word is usually employed after one has spent a good while chasing tabs and indentations around a document and then given up. But even here MS has a tools to sort out the inevitable mess that results from carelessly permitted flexibility. They have the concepts of remove all styles and search and replace for styles. EPC has no such functionality.
What still causes me maximum confusion is the concept of pad styles - I suppose it is the most confusing idea (to me) about the whole technology file thing. Technology files make some sense when you realise that they are really just exotically named configuration files. When creating a new footprint one usually slavishly follows the recommended pattern in the datasheet. The guys who wrote it knows far better than I what shape and size of pads work best for their component. Pad dimensions have to work with complicated issues such as solder flow characteristics, surface tension effects, the thermal conductivity of the leads, weight of the component etc … which is probably a real science. Best thing to do (with a few caveats) is to just copy what the datasheet says.
But then EPC wants to give the pad style a name. Why? What use is this to me? Is some-one thinking I’m going to start changing them at PCB level? If it used names such as pad_SOT-23 then I suppose I could (though I wouldn’t - as it contravenes the fundamental rule - Symbols and Footprints MUST be correct at library level) but not when it gives them names such as Padstyle487_1_1. Not only that but Padstyle487_1_1 might be used in several footprints. What is going on here? Why does EPC do this? What is the point of a huge list of encrypted pad names (shared by multiple parts) in my PCB technology file? Not only that I have to explain this when new guys turn up and need training to use the software. Even if I wanted to bodge footprints at PCB level and I do change pad size, the act would mean I changed perhaps several component pads - unrelated to the offending footprint I had taken exception to. This is unlikely to be what I had in mind when bodging a footprint.
Maybe once upon a time when Gerber plotters had a finite set of apertures then there was merit in setting up a list of pads which could be flashed. It made the Gerber file smaller. But now we don’t care how big the file is. Gerber files are now almost always plotted without worrying about aperture tables, they convert the apertures to other data structures. Even so when I design a footprint am I really going to deviate from say the specified 1.2mm x 0.8mm rectangular pad just because I already have a 1.2mm x 0.9mm pad. Why would anyone want to do that? The way pad styles work the pad style name is really philosophically problematic. Even if you had pads named after their dimensions and characteristics e.g. ROUND TH 70/32 (say) for round through hole 70thou pad 32mil hole then this name is sitting in a table with presumably the sole intention that you could change it somewhere else to be say 60thou diameter. This is not very sensible. If pads are going to get named then the only name you could have is the name of the footprint and an identifier for pad number so if I had a 5 way 0.1inch style connector with a square 70thou pad for pin 1 and round 70thou pads for pins 2-5 then the only pad name that would make any sense would be
FootprintName-1, FootprintName2-5. But now we have the very real possibility that there could be many pads with identical dimensions and differing style names. This part of EPC needs a serious rethink/rework. Maybe only display names if they have been given names by the user. Or dream up some auto-naming functionality which names pads by characteristics - so name changes if size changes.
K |
| 2 L A T E S T R E P L I E S (Newest First) |
| KevL |
Posted - 03 Sep 2010 : 12:23:18
quote:
2) You have control over the technology file used for symbol creation/editing (see [Tech Files] button in library manager).
Yes that is what I thought...... but see this post
http://www.numberone.com/forum/topic.asp?TOPIC_ID=463
quote:
A technology file won't change by itself - there's no automatic update. The closest to this is the prompt, "Technology file settings have changed. Save changes?". Answering 'No' to this loses nothing. Answering 'Yes' add extra information to the technology file.
We have a single set of tech files on our network. These are shared by multiple users in a mult seat setup. In order for the tech files remain the same then every user has to always press No to the above question. Also the YES/NO question is a very course setting ... one is never sure about what has caused the tech file to think it needs changing.... is it that the visible layers has changed, grid step changed or has a user decided to add Linestyle_new_unwanted_1_1_1 to the tech file. In practice the tech files do change. To get round this we keep a backup set and overwrite the files fairly regularly with our "standard" tech files.
I guess the way to fix this would be to have a tickbox saying. Dont change the library tech file under any circumstances ever, please.
Kev |
| Peter Johnson |
Posted - 31 Aug 2010 : 12:59:05
1) Duplicate symbol names are a problem, especially since it's not easy to avoid them. There are management tools in place, but I have to agree that it would be better if they weren't required. The best strategy is often to rename one symbol of a duplicate pair, then re-link the component to the renamed symbol.
Where duplication has been necessary (e.g. in supplementary libraries, which have to be self contained) we've tried hard to ensure that all instances of a symbol with the same name are identical.
2) You have control over the technology file used for symbol creation/editing (see [Tech Files] button in library manager).
A technology file won't change by itself - there's no automatic update. The closest to this is the prompt, "Technology file settings have changed. Save changes?". Answering 'No' to this loses nothing. Answering 'Yes' add extra information to the technology file.
The real question about styles should be, "Does it matter". You've made the assumption that the style name is always important, when in many cases it isn't.
e.g. In a design you have a pad using 'Style 1'. You add a component which uses a different size pad, also called 'Style 1'. The incoming pad is renamed to 'Style 1_1' to differentiate it from the existing Style 1. That rename is local to that design, and won't affect the libraries or technology files.
The reason for some of the odd style names is that you are adding pads to new symbols, then changing the pad style in Design Technology. When you answer yes to save settings, the program adds an '_1' to the redefined style to differentiate it from an existing one, so you get repeated _1's being added to the technology file style names.
I can see why you're having trouble with proliferation of meaningless style names, but a large part of this is probably due to misunderstanding how the program works rather than any serious deficiency in style handling. You have raised some important issues regarding how this can be managed, however, so I'll be putting your requests forward to the programmers. |
|
|
