Re: [kicad-users] Something Complex & Cool on KiCad
Am 30.04.2009 um 21:32 schrieb Tobias Gogolin: > > > >"Wishing" for a component I think is NOT the best solution. Just a > mechanism > >for "Sharing" components would be good. So if I have a Library of > components > >I want to share then I just click "Share" and that goes to the > repository. > >If I would then want to search for a components I would search > (from KiCad) > >in that repository. > > What I mean with 'wishing' components is more like 'how many like to have that component' to see which components one could create / publish. It is not meant barely, who makes me this component. This explicit wish is usually a paid service I think. So just get a glue, which components are required the most. And then even funded component creation could be done easy. > I agree and congratulate on the uptake of these efforts! > I also wonder how these remote components, (schematic symbols, > padstacks, and 3D models) could be integrated with what is currently > managed as Packages (I would almost prefer something like directory > structures (user manageable) similar to Jar files)? > There may be an interface for the plugin: a virtual library package > remoteLibrary.xyz ? > > Aren't there cases that I search for a specific part with a specific housing - eg. DIL40 or PLCC44? If all the components are packaged into some 'library's, the network traffic would be very high :-) What about an interface that pulls a specific componet + the required package out of the 'web service' and delivers it as TGZ or what ever? I have created a small PDF file about my thinking of a database centric solution. The end product that will be carried around would be any format, because it could be packaged dynamically. Here is the file I uploaded: http://groups.yahoo.com/group/kicad-users/files/KICADDBLibMan.pdf With a database you could do much more things, eg. add vendor information, reseller information and even prices. When the database is at a public place, we will get very fast an overview, where we could get the cheapest parts for our BOM. (Simply issue an SQL query and enrich the BOM) I hope my ideas are not too crazy :-) Lothar -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de Lothar Behrens Heinrich-Scheufelen-Platz 2 73252 Lenningen
Re: [kicad-users] KiCad regrettably still is history free and not parametric!
> A more standardized way of behaving would be that by default a drag done on > a component does just that dragging the symbol or padstack on which the drag > is performed and connections with it! What standard is that? Would that be the Tobias standard by any chance? Personally I rarely use Drag, so it wouldn't be part of the Robert standard. > If a right click is performed: access to methods of the selected objects > should be given, and applied to the whole selection as applicable! But that's exactly what right-click does. Have you tried it? Regards, Robert.
Re: [kicad-users] Something Complex & Cool on KiCad
A few thoughts about this... You do NOT want a database anywhere near Kicad. Fair enough if you want to create a database that REFERENCES parts and modules, but such a system should play no part in the operation of Kicad. I have seen far too many situations where over engineered systems fail, particularly during upgrade operations, where database links get broken and it's almost impossible to get them working again. Kicad is used by many different types of people of different abilities, and if there is one thing that I have come to appreciate over the years, is that the KISS principle of operation is much safer. A separate system that helps manage things is fine, something that Kicad becomes DEPENDANT on is not. The ability to manage libs and modules is already built into Kicad. Both parts and modules can be imported and exported individually. Also entire libs can be added. So it really comes down to a choice, the used can either select an entire library to be downloaded or get the individual libs and modules. I would agree that the method of adding libs and modules and various parts within them could do with some improvement, to make the process a little easier, that would be nice, but that's a fairly minor requirement. The biggest problem at the moment is when you download a lib, say during an upgrade, this overwrites any parts that you may have added to that lib. Once you learn to keep parts that you have added in a different lib then the problem goes away, but it's still a problem. It would be better in terms of part management to have a method that allowed a lib or mod to be updated without overwriting additions and modifications. With any system that shares things, there is a very important area that MUST be managed CAREFULLY. That is the issue of copyright. Without getting into all the possible issues, lets me just say that you must be VERY VERY careful as to the source of any part shared in such a system. As one crude example, just think if some kind soul converted the parts and modules from another PCB design package and then decided to share them. Even collections of parts and modules published for use by manufacturers have a copyright to them. Just be careful on this aspect. Another issue that comes to mind, is what I would call the "fittness for purpose" A part and module that I design, while perfectly suitable for my needs may well not be suitable for someone else. How can any particular part or module be certified and for what use? Andy On Fri, 1 May 2009 09:57:30 +0200 Lothar Behrens wrote: > > Am 30.04.2009 um 21:32 schrieb Tobias Gogolin: > > > > > > > >"Wishing" for a component I think is NOT the best solution. Just a > > mechanism > > >for "Sharing" components would be good. So if I have a Library of > > components > > >I want to share then I just click "Share" and that goes to the > > repository. > > >If I would then want to search for a components I would search > > (from KiCad) > > >in that repository. > > > > > What I mean with 'wishing' components is more like 'how many like to > have that component' > to see which components one could create / publish. It is not meant > barely, who makes me this > component. This explicit wish is usually a paid service I think. > > So just get a glue, which components are required the most. And then > even funded component creation could be done easy. > > I agree and congratulate on the uptake of these efforts! > > I also wonder how these remote components, (schematic symbols, > > padstacks, and 3D models) could be integrated with what is currently > > managed as Packages (I would almost prefer something like directory > > structures (user manageable) similar to Jar files)? > > There may be an interface for the plugin: a virtual library package > > remoteLibrary.xyz ? > > > > > Aren't there cases that I search for a specific part with a specific > housing - eg. DIL40 or PLCC44? > > If all the components are packaged into some 'library's, the network > traffic would be very high :-) > > What about an interface that pulls a specific componet + the required > package out of the 'web service' > and delivers it as TGZ or what ever? > > I have created a small PDF file about my thinking of a database > centric solution. The end product that will > be carried around would be any format, because it could be packaged > dynamically. > > Here is the file I uploaded: > http://groups.yahoo.com/group/kicad-users/files/KICADDBLibMan.pdf > > With a database you could do much more things, eg. add vendor > information, reseller information and even prices. > When the database is at a public place, we will get very fast an > overview, where we could get the cheapest parts for our BOM. > (Simply issue an SQL query and enrich the BOM) > > I hope my ideas are not too crazy :-) > > Lothar > > -- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de > Lothar Behrens > Heinrich-Scheufelen
[kicad-users] Pinout & Pin Numbering Confusion
Hi, I've been using KiCad for a few weeks, but I've just run into a problem with the libraries I've built up. Some devices that use the same package have different pinouts, and some devices have different (numeric) pinouts in different packages. For example, an FDN337 FET in a SOT-23 package places G on pin 1, S on 2 and D on 3. However, another FET in a TO-92 places S on 1, G on 2 and D on 3. So, although I'd like to have just one schematic symbol for N-channel FETs, I can't name the pins in a way that works for SOT-23 and TO-92 devices. (This is a simple example, but I hope you can see what my problem is.) It appears that the distributed libraries just have multiple identical footprints with differently-named pins for various devices, so you'd have an SOT-23 with numbered pins, another with pins named GDS, another with BCE, another with AK, and so on. Is this the best way to go about it? Clearly, it'll work, but if I ever want to go back and adjust the solder pads to work better with an SOT-23, I'll have to find and change all of them, rather than just one. Thanks!
Re: [kicad-users] KiCad regrettably still is history free and not parametric!
It seems to be the standard ever since the Mac brought the Xerox interface to the mainstream... It is the case on pretty much every program that supports dragging of objects even word for windows... Maybe you don't now, but wouldn't you use it when laying out a board? I would also like to see the wildcard * implemented when placing components like give me all resistors one after the other by R* ... Right click of course does that I know, but read my description of the standard again, it should also be able to do it on multiple items selected - but selecting multiple items isn't even supported yet! " The marque 'lasso' as it turns up currently should _only happen_ when the drag is initiated above clean deskspace (nothing to select)! It should not by default result in a question to move, but if a drag follows on one of the selected components the drag should be performed on all selected components! If shift or control is pressed: further refining of the selection should be possible! If a right click is performed: access to methods of the selected objects should be given, and applied to the whole selection as applicable! " On Fri, May 1, 2009 at 2:57 AM, Robert wrote: > > A more standardized way of behaving would be that by default a drag done > on > > a component does just that dragging the symbol or padstack on which the > drag > > is performed and connections with it! > > What standard is that? Would that be the Tobias standard by any > chance? Personally I rarely use Drag, so it wouldn't be part of the > Robert standard. > > > If a right click is performed: access to methods of the selected objects > > should be given, and applied to the whole selection as applicable! > > But that's exactly what right-click does. Have you tried it? > > Regards, > > Robert. > > > > > 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 > > > > > > -- Tobias Gogolin Tel. Movistar (646) 124 32 82 Tel. Telcel (646) 160 58 99 skype: moontogo messenger: usert...@hotmail.com You develop Sustainable Ranch Technology at http://tech.groups.yahoo.com/group/SURA-TECH an Open Source Electric Motor/Alternator at http://groups.yahoo.com/group/Performance_Axial_Flux and an Open Source Motor Controller at http://groups.yahoo.com/group/GoBox
Re: [kicad-users] Something Complex & Cool on KiCad
>The biggest problem at the moment is when you download a lib, say during >an upgrade, this overwrites any parts that you may have added to that >lib. Once you learn to keep parts that you have added in a different lib >then the problem goes away, but it's still a problem. It would be better >in terms of part management to have a method that allowed a lib or mod to >be updated without overwriting additions and modifications. maybe a Library merge and diff command would be the solution... >That is the issue of copyright. Without >getting into all the possible issues, lets me just say that you must be >VERY VERY careful as to the source of any part shared in such a system. yes but that appears to be something that can be solved by disclaimer: "Content to be uploaded must be original art created by the uploader. The library server constitutes a temporary depository of user contributions." And if some party claims that their rights are violated than the elements in questions can be removed... On Fri, May 1, 2009 at 4:53 AM, Andy Eskelson wrote: > A few thoughts about this... > > > You do NOT want a database anywhere near Kicad. > > Fair enough if you want to create a database that REFERENCES parts and > modules, but such a system should play no part in the operation of Kicad. > I have seen far too many situations where over engineered systems fail, > particularly during upgrade operations, where database links get broken > and it's almost impossible to get them working again. Kicad is used by > many different types of people of different abilities, and if there > is one thing that I have come to appreciate over the years, is that the > KISS principle of operation is much safer. A separate system that helps > manage things is fine, something that Kicad becomes DEPENDANT on is not. > > > The ability to manage libs and modules is already built into > Kicad. Both parts and modules can be imported and exported individually. > Also entire libs can be added. So it really comes down to a choice, the > used can either select an entire library to be downloaded or get the > individual libs and modules. > > I would agree that the method of adding libs and modules and various > parts within them could do with some improvement, to make the process a > little easier, that would be nice, but that's a fairly minor requirement. > The biggest problem at the moment is when you download a lib, say during > an upgrade, this overwrites any parts that you may have added to that > lib. Once you learn to keep parts that you have added in a different lib > then the problem goes away, but it's still a problem. It would be better > in terms of part management to have a method that allowed a lib or mod to > be updated without overwriting additions and modifications. > > With any system that shares things, there is a very important area that > MUST be managed CAREFULLY. That is the issue of copyright. Without > getting into all the possible issues, lets me just say that you must be > VERY VERY careful as to the source of any part shared in such a system. > As one crude example, just think if some kind soul converted the parts > and modules from another PCB design package and then decided to share > them. Even collections of parts and modules published for use by > manufacturers have a copyright to them. > > Just be careful on this aspect. > > Another issue that comes to mind, is what I would call the "fittness for > purpose" A part and module that I design, while perfectly suitable for my > needs may well not be suitable for someone else. How can any particular > part or module be certified and for what use? > > > Andy > > > > > > > > > > On Fri, 1 May 2009 09:57:30 +0200 > Lothar Behrens wrote: > > > > > Am 30.04.2009 um 21:32 schrieb Tobias Gogolin: > > > > > > > > > > > >"Wishing" for a component I think is NOT the best solution. Just a > > > mechanism > > > >for "Sharing" components would be good. So if I have a Library of > > > components > > > >I want to share then I just click "Share" and that goes to the > > > repository. > > > >If I would then want to search for a components I would search > > > (from KiCad) > > > >in that repository. > > > > > > > > What I mean with 'wishing' components is more like 'how many like to > > have that component' > > to see which components one could create / publish. It is not meant > > barely, who makes me this > > component. This explicit wish is usually a paid service I think. > > > > So just get a glue, which components are required the most. And then > > even funded component creation could be done easy. > > > I agree and congratulate on the uptake of these efforts! > > > I also wonder how these remote components, (schematic symbols, > > > padstacks, and 3D models) could be integrated with what is currently > > > managed as Packages (I would almost prefer something like directory > > > structures (user manageable) similar to Jar files)? > > > There may be an interface for the plugin: a
