On Sun, Aug 30, 2009 at 3:51 PM, Andy Eskelson<[email protected]> wrote: > There is a web based lib system for kicad see > http://www.kicadlib.org/
That works OK, but not great. For example, I searched for a random part, the ATTiny13, I find several different versions of the same part, and without downloading the library I have no way to know whether one is wrong or has other issues. But it is better than nothing. > This subject has been discussed; some might say done to death :-) several > times. Ok, well I'll add my feedback, but I'll try to keep from going on too long. :-) > The main problem with any system that uses 1000's of different items is > keeping things organised, and that is generally a user problem more than > anything else. That seems like a poor argument. Databases are very good at organizing things. As you noted, there is already a searchable database of the libraries, this would just make it into a more accessible format. > The next problem is that the way kicad uses libs and modules does not > currently lend itself to easy management. One the flip side, doing things > as kicad does is quite fast. Well, if it isn't very manageable already, that seems like a great argument for improving it, doesn't it? And if it needs to be fixed anyway, perhaps rethinking the whole paradigm is not a bad idea. :-) > This next point is the killer... > it is a VERY VERY VERY BAD idea to have part libraries (or ANY > critical documentation for that matter) based on web storage, UNLESS it is > IMPOSSIBLE for a part that you used in a design not to be held locally > without user interaction. (I say that coz users will happily use anything > they find on the web and will not think about keeping a copy). I agree. There are two big issues here, accessibility and security. The libraries need to be easily downloadable, so people with unreliable (or without) internet connections can use it. That part is easily solved. Just make it so users can download either the entire database or just the parts they want at any time. The security issue is primarily that we need to know whether we can trust parts or not. The "trustworthy rating" that I mentioned before helps with that, but we also would need to be sure that no one could maliciously replace the trusted part with a broken one. That's a fairly simple web security issue, though, so it should be easily dealt with. > Different people prefer different symbol types, that needs catering for. > Some devices need different modules and libs for the same device and > package. Microcontrollers have been discussed several times, where you > can define pins to be different functions at will. So one lib will never > fit in such cases. That needs to be catered for. All these are simple variants. There's no reason at all my proposed system couldn't have variants. But unlike the current system, those variants could easily be shared, rather than requiring each user create his own variant. > The part about updating is a problem, one that we have to > watch out for already. If you install kicad from new, it will overwrite > any changes to the libs and mods that you have made, which is why you > should create your own libraries and put your modified parts there. Users > are going to be very unhappy if they spend time modifying a part for > their own use, only to find that it gets overwritten due to some update. Updating is an issue with the current system, but not with my proposal. The old versions of the parts never go away, so it will never become an issue. When a part is inserted into a schematic or board, both the part ID and the revision number are stored, and the part is automatically added to my local library. If someone updates the part in the central repository, I would be quietly notified, but nothing would be updated in my files without my explicit permission. There should be a way to flag old versions as broken in which case the notification would be much more forceful, but even then nothing would change without my permission. If I ever share the schematic or board files, the parts do not need to be embedded into the file, since the recipient of the file can automatically download just the parts they need from the repository, even if those parts are old versions. > Next you have the legal aspects, say someone took the eagle libs, > converted them to kicad format and uploaded them? You then run into > copyright issues for a start. Now I know that some companies will not > mind, but others will, so that has to be catered for. These are valid issues, but not as significant as you are making them out to be. Sites like Wikipedia deal with these issues everyday. You have a license agreement, an address for people to send takedown notices, and volunteers to take things down if necessary. In practice, I don't see this as being much of an issue. Unless Eagle makes their schematic symbol for some part in a unique way, how is they going to recognize the part as theirs? And while you can copyright a unique symbol, the generic schematic symbols are not copyrightable anyway. > Please NOT WIKI I end up going around in circles trying to find things, > click link, click next link, click another link end up where you > started.... :-) The only mention of a Wiki was with regard to versioning. I could have said CVS style versioning or Subversion style versioning... > I have no objection to a web based repository for parts and modules, and > kicadlib is such, and is a useful place to keep things. > > However I think that there would be a lot of admin needed for such a > system to work as you describe. Not impossible, but it would become a > project in it's own right. Yes, but it would be a very worthwhile project. And being Open Source, there is no reason that other programs couldn't also use it. And if enough other programs use it, the manufacturers would be encouraged to make their own part libraries in the system. That would be great for everyone involved. But it has to start someplace, and KiCAD seems to be as good a place as any. :-) > I also think that some rather fundamental changes would be needed in how > kicad manages it's libs and modules before you could contemplate doing > something like this. But then you have sort of a chicken and egg problem. You can't have this new system without fixing these problems, but if you fix the problems, the new system probably won't be any more conducive to this proposed system... Unless you plan ahead for such a system, which is why I'm proposing it. > I think you really need to have a system that can work with individual > parts and modules, but manage the inclusion of such things into the combined > libraries that kicad uses automatically. Yes, this was assumed in my proposal. As I said, I am not proposing just dumping the current system right away. In the long run, it probably makes sense to get rid of the current libraries, but obviously not until this new system was really up and running. And even if the old libs were phased out, as I've said, you can always have a local copy of the web database if you wish. > It also needs to sort out the > user/supplied lib situation in some sane manner. Easily handled with a simple database field, though the 'trustworthy rating is really a better solution. Just because a library comes with the program doesn't mean that it's accurate. I've heard of numerous issues with Eagle's supplied libraries, so even the supplied libraries should have the trustworthy rating. > If you had that then you could set things up in the way that you describe > with individual parts, then again someone will want to grab ALL the parts > from a particular range, so you had better cater for that as well :-) Yup. As I noted above, users could download the entire database, or any subset, at will. Again, this is all pretty simple web programming. > > On Sun, 30 Aug 2009 14:46:09 -0700 > Mike Payson <[email protected]> wrote: > >> I'm curious about something. I'm an Eagle user, but I recently >> subscribed to this list out of curiosity. I've played with KiCAD for a >> few minutes, but not yet tackled any real projects with it. One of the >> main roadblocks has been the lack of libraries, though I recently >> found out you can convert Eagle Libraries which makes things easier. >> >> Anyway, I have an idea for what I think would be a much better way to >> support part libraries, so I thought I'd throw it out and see what >> people think. In my experience, part libraries are a huge pain. You >> have to search for the correct part, which may or may not be listed as >> being present in a particular library. If you find it, you can't count >> on it having been done correctly, so you have to compare the part to >> the datasheet to double check. Even if you find a good part, there is >> a good chance that the schematic symbol is badly designed, etc. And if >> you manage to fix any of these problems in your local copies, you need >> to start over when a new version is released. Libraries are great if >> they are coming from a definitive source who does a good job >> assembling them (such as if Atmel released and maintained their own >> AVR library), but when they are OS, their are a ton of potential >> issues. >> >> Instead of having traditional monolithic libraries, it seems to me >> this is the ideal place for a web-based system. In this system, the >> part footprint would be separated from the part itself, so all TQFP32, >> .8mm pitch parts would use the same footprint (I think KiCAD already >> does this). Right there you eliminate a lot of potential issues. For >> the parts themselves, instead of having an AVR library (for example), >> each individual part would be available via a web-based service. >> Instead of downloading the AVR library, you would download the >> ATMega32 part. This makes it much easier to find your exact part, and >> also means that only one person ever needs to create a particular >> part. >> >> If that part is not already available, you create and submit it as >> normal, and it's available for the next guy, however it is marked as >> an untested part. Each part will have a 'trustworthy' rating, and >> until a certain number of people vote that the part is correct, it >> will remain flagged as suspect so people will know to double check the >> datasheet. If there are problems with a part, anyone can update the >> part to fix them, and their changes would automatically be shared. The >> parts are versioned Wiki-style, so the old version always remains >> available if changes are made. The user would be prompted that the new >> version is available and allowed to change or not, so this would not >> break existing designs due to minor corrections. >> >> Some other thoughts: >> * Though the footprint is standardized, the individual part does have >> the ability to override each layer of the standard part if necessary, >> so if a particular part has a specific solder mask requirement, for >> example, you can modify that layer while still using the standard >> footprint. >> >> * This allows people to easily share part documentation and tips, >> reference schematics, etc, since they can be easily attached to the >> part itself. >> >> * This would be web-based, but there would be a browser integrated >> into the library browser, so you could add any part directly from >> within the program. >> >> * This would not replace the existing library system, at least not at >> first. You can easily export the web-library for off-line usage. >> >> * The parts would still be organized into library-like categories, to >> make things easy to find. Parts could also be tagged to make things >> even easier. >> >> So any thoughts or comments? >> >> >> ------------------------------------ >> >> Please read the Kicad FAQ in the group files section before posting your >> question. >> Please post your bug reports here. They will be picked up by the creator of >> Kicad. >> Please visit http://www.kicadlib.org for details of how to contribute your >> symbols/modules to the kicad library. >> For building Kicad from source and other development questions visit the >> kicad-devel group at http://groups.yahoo.com/group/kicad-develYahoo! Groups >> Links >> >> >> > > > ------------------------------------ > > Please read the Kicad FAQ in the group files section before posting your > question. > Please post your bug reports here. They will be picked up by the creator of > Kicad. > Please visit http://www.kicadlib.org for details of how to contribute your > symbols/modules to the kicad library. > For building Kicad from source and other development questions visit the > kicad-devel group at http://groups.yahoo.com/group/kicad-develYahoo! Groups > Links > > > >
