apluscw wrote:
> > > Here is the standard we are adhering to at work: > > Description > Packaging > Tolerance > Rating > Manufacturer > Mnfg PN > DK PN > Library > > DK PN is Digi-Key part number. Library is the library file the part > came from, which can be useful. > > Might I suggest that we make an attempt to standardize the usage of > those fields so that we might build libraries that take advantage of > these fields? The way KiCad works right now those fields exist but > managing them is quite cumbersome. > > Also, if you have more than one component with the same name KiCad > becomes very confused. I should think that the internal name to > KiCad should include the library name, ie. "device/inductor" vs. > just "inductor". We had problems when we had two definitions for an > LM324. Capacitors also led to trouble. > > Regards, > > apluscw > And here we run straight away into the problems. For example, given that there is allready a footprint field, I put Packaging, along with Tolerance and rating, in the Desription string. The reason is that it is almost impossible to build a set of standard parameters for electronic components, there would be two many and it is difficult to understand what is important. I put in the description what is relevant to the component. For eaxample, take 2 capacitors: Capacitor A is switchmode electolytic: Value=100uF Footprint=C2V10 Description=25V, ESR=0.2, Iripple=500mA, 105C Capacitor B is a timing capacitor: Value=33nF Footprint=C2 Description=Polystyrene 1%, 100ppm, 30V Put bluntly, the description should contain just the information that would normally be required to find a component in it's typical application. If I had some strange requirement, like 2% tolerance on capacitor 'A' (resonant converter?!) then I would regenerate the component with that description. Another issue you raise is libraries. Using compnents directly from standard libraries is a very risky business. Most people like to have a specific home made library for each board. Some do this by dumping the library when they have finished the board, some EDA packages automatically build a cache. I have not even bothered looking what KiCAD does because I always build up my own library as I draw the schematic. Each time I put a new component I look for one in the standard libraries, or draw my own, and then put it into my library. It is at this point that add/modify properties and put the footprint (which I also select design as I build the scematic, as I have the data under my fingertips). Of course selecting footprints when designing the schematic is not common as it is only approriate for people who both design the schematic and layout thier own boards. Nonetheless the principle is the same even if done in two stages. This approach makes sharing compnents more flexible and less messy. It would be nice if in the future eeschemas libedit, and PCB's, could be configured to include external libraries (i.e. via ftp) which we could browse and then insert into our board libraries. Everybody can then export to thier own website components which may be generally usefull. Obviously the key/values pairs is a great help this respect. When reviewing the component we have just grabbed we can modify the set to suit our requirements. But it requires that a) We have an unlimited list of key value pairs and b) We avoid ambiguity and duplication. On the face of it, issue A) is the most important. If the list is unlimited then users can adapt to thier own requirement. The second most important issue is that of being easily able to browse and pull components from fellow users on the net. As component definitions are essentially ASCII files then what better than simply putting them up on webpages with keywords and/or Meta tags to allow the library editors to browse them easilt. That way we could all stick our exportable components on e.g. our providers free homepages or whatever, that way we avoid the hassle of admistrators, securetty etc. etc. A component bazzar! So how would our work scenario go? When building up a schematic we would get most of our components from our own libraries of previous designs, after all most of generally use a restricted set of components. If we have a part we have not used before, then we would set the librarary editor to browse other users sites. Our search would start with users which we know who design similar circuits, who use the same suppliers (likely to have the code for the suppliers we use), and who we know to be reliable (the actual KiCAD libraries have some very badly done components). Regular users would be able to build up a search list of other users with similar requirements. Of course if we did not find anything to our liking, then we design it ourselves and shove it onto our hompage. We may also post improved versions of components we have taken. Each user advertises thier component site on the Wiki, so new users have somewhere to start. So, in this scenario we would not need to have rigidly defined fields. Conventions useful, but not essential. Any which way, the user base would decide. Those wanting specific rigid descriptions would be sharing thier sites with like minded users! What we do need is the internet enabled library editor and the unlimited field list with a grid list on the component properties page. Thoughts anybody?
