Re: gEDA-user: Reinventing the wheel
Kai-Martin Knaak k...@lilalaser.de writes: Stephan Boettcher wrote: My colleagues use eagle. I review their gerbers with gerbv. They envy my hierachical schematics and scripting fu, Funny. I got the impression, the scripting abilities of eagle are one of the few things eagle really excels at. I've heard so, yes, one of our engineers does eagle scripting once in a while. But he had to learn how to script eagle. I did not learn any new language, I script in sed, awk, python, gnumeric. Both are good things. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Broken TO92 footprint
Vanessa Ezekowitz vanessaezekow...@gmail.com writes: The TO92 footprint included with PCB does not work with the schematic importer therein. Try to reference it and the importer complains about missing pins, because it uses numbered pins instead of the B-C-E lettering used in gschem's transistor symbols. The TO92 package has well define pin numbers. The mapping from transistor pins to footprint pins should happen in the schematic. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Broken TO92 footprint
The TO92 package has well define pin numbers. The mapping from transistor pins to footprint pins should happen in the schematic. Worse, the mapping from EBC to 123 is *different* for different transistors using the TO-92 case. Compare 2N3904 - E-B-C 2SC2631 - E-C-B ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Broken TO92 footprint
DJ Delorie d...@delorie.com writes:
The TO92 package has well define pin numbers. The mapping from
transistor pins to footprint pins should happen in the schematic.
Worse, the mapping from EBC to 123 is *different* for different
transistors using the TO-92 case.
Compare 2N3904 - E-B-C
2SC2631 - E-C-B
The package pin numbers are well defined: 1-2-3. The Symbol on the
schematic should tell which (numeric) package pin conects to which
transitor contact. There are also FETs in that package.
I'd still use slotting for this in generic symbols. I've made a quick
generic NPN symbol that demonstrates how I think generic symbols may
work.
gschem GUI may need an additional feature in the attibute editor: When
editing an attribute NAME, it shall offer a dropdown menu of choices
given in the attibute NAMEs (or some other less ambiguous mangling of
NAME).
v 20110115 2
P 600 1000 600 800 1 0 0
{
T 500 850 5 6 1 1 0 0 1
pinnumber=1
T 700 850 5 6 0 0 0 0 1
pinseq=1
T 400 850 5 6 0 1 0 0 1
pinlabel=C
T 700 950 5 6 0 1 0 0 1
pintype=pas
}
P 600 200 600 0 1 0 1
{
T 500 50 5 6 1 1 0 0 1
pinnumber=3
T 700 50 5 6 0 0 0 0 1
pinseq=3
T 400 50 5 6 0 1 0 0 1
pinlabel=E
T 700 150 5 6 0 1 0 0 1
pintype=pas
}
V 500 501 316 3 0 0 0 -1 -1 0 -1 -1 -1 -1 -1
T 900 700 5 10 0 0 0 0 1
device=NPN
L 600 200 400 400 3 0 0 0 -1 -1
L 600 800 400 600 3 0 0 0 -1 -1
L 400 700 400 300 3 0 0 0 -1 -1
P 0 500 184 500 1 0 0
{
T 100 550 5 6 1 1 0 0 1
pinnumber=2
T 200 550 5 6 0 0 0 0 1
pinseq=2
T 0 550 5 6 0 1 0 0 1
pinlabel=B
T 200 650 5 6 0 1 0 0 1
pintype=pas
}
L 400 500 184 500 3 0 0 0 -1 -1
L 600 200 564 272 3 0 0 0 -1 -1
L 600 200 528 236 3 0 0 0 -1 -1
L 528 236 564 272 3 0 0 0 -1 -1
T 900 500 8 10 1 1 0 0 1
refdes=Q?
T 1300 500 5 10 0 0 0 0 1
footprint=?
T 0 1500 8 10 0 0 0 0 1
numslots=6
T 0 1300 8 10 0 1 0 0 1
slotdef=1:1,2,3
T 0 1100 8 10 0 1 0 0 1
slotdef=2\:1,3,2
T 700 1100 8 10 0 1 0 0 1
slotdef=3:2,1,3
T 700 1300 8 10 0 1 0 0 1
slotdef=4:2,3,1
T 1400 1300 8 10 0 1 0 0 1
slotdef=5:3,1,2
T 1400 1100 8 10 0 1 0 0 1
slotdef=6:3,2,1
T 1400 1500 8 10 0 0 0 0 1
slot=1
T 900 300 8 10 0 1 0 0 1
footprints=SOT23,TO92,TO220
T 0 1700 8 10 0 0 0 0 1
slotmode=alternatives
T 0 1900 8 10 0 0 0 0 1
promote=slot,device,refdes,footprint
--
Stephan
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB crash on rotating polygons in buffer
On Thu, May 19, 2011 at 06:19:05PM +0100, Peter Clifton wrote: On Thu, 2011-05-19 at 14:26 +0200, Gabriel Paubert wrote: In the meantime, I have a 100% reproducible bug with the following backtrace: Program received signal SIGSEGV, Segmentation fault. r_delete_entry (rtree=0x0, box=0x7d8c60) at rtree.c:1101 1101r = __r_delete (rtree-root, box); Now fixed with this commit: commit c12cc6f769b5ccc603a75361fae3adc930934506 Author: Peter Clifton pc...@cam.ac.uk Date: Thu May 19 18:13:43 2011 +0100 buffer.c: Update polygon r-tree when adding a polygon to the buffer. This resulted in a crash when rotating a buffer containing a polygon, as the polygon r-tree associated with the buffer was NULL despite the polygon count being non-zero. Thanks a lot. Gabriel ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Broken TO92 footprint
On Fri, 20 May 2011 08:31:46 +0200 Stephan Boettcher boettc...@physik.uni-kiel.de wrote: Vanessa Ezekowitz vanessaezekow...@gmail.com writes: The TO92 footprint included with PCB does not work with the schematic importer therein. Try to reference it and the importer complains about missing pins, because it uses numbered pins instead of the B-C-E lettering used in gschem's transistor symbols. The TO92 package has well define pin numbers. The mapping from transistor pins to footprint pins should happen in the schematic. Perhaps, and as DJ says the actual mapping varies from one transistor type to another. However, this particular footprint simply doesn't work for any Gschem-PCB use case, hence my replacement. I can't fix the actual bug, so I fixed the symptoms. :-) -- There are some things in life worth obsessing over. Most things aren't, and when you learn that, life improves. http://digitalaudioconcepts.com Vanessa Ezekowitz vanessaezekow...@gmail.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
Colin D Bennett wrote: Not to get into the whole light/heavy symbol debate Maybe, it is time to look at this issue again. When I first read geda documentation, there were already references that this had been discussed ad nauseam. As a result, the default lib was the way it was and is. This is six year back now. Since then, this topic has not been raised on the mailing list. But there are Except for some bug fixes, the default lib stayed the same for all the years. No symbols were added, none was removed, nothing was restructured. If the default lib is to be changed now, then there should be some kind of new consensus on the heavy/light issue. Else, the effort might end in religious war and, or frustration. ---)kaimartin(--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Broken TO92 footprint
Perhaps, and as DJ says the actual mapping varies from one transistor type to another. However, this particular footprint simply doesn't work for any Gschem-PCB use case, hence my replacement. I think, if we were to accept such a change, what we'd need is a range of TO92 packages with all the permutations of EBC and SGD, like TO92_EBC.fp, TO92_ECB.fp, TO92_SDG.fp, etc. Likewise for SOT23, SOT323, SOT523, SOT723, TO220, etc. We'd probably need variants for regulators, like TO220_IGO.fp (in,gnd,out) vs TO220_IOG.fp (7805 vs 3.3v LDO). I suggest using a script :-) (geek points if it's an M4 script ;) The unadorned footprint should match industry standard pin numbering. IMHO a footprint which obviously breaks everything is better than a footprint that silently breaks some things. I don't want to lull newbies into a false sense of security. *I* have been burned by that. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Broken TO92 footprint
DJ Delorie wrote: what we'd need is a range of TO92 packages with all the permutations of EBC and SGD, like TO92_EBC.fp, TO92_ECB.fp, TO92_SDG.fp, This is, what I ended up with, after I had my first TO92 transistor disaster. In my not so private library on gedasymbols.org there are both: TO92 footprints with named pins and a footprint with generic 1-2-3 numbers. ---)kaimartin(--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Solving the light/heavy symbol problem
[Subject changed to start new thread] When I first read geda documentation, there were already references that this had been discussed ad nauseam. Sigh, yes. It's not an easy problem to solve, and I would consider any solution a major effort because it touches everything from gschem to pcb to sim. Ideally, it would move pcb-specific stuff out of gschem, although the ability for the user to manage their library from either gschem or pcb would be ideal. Bonus points for backwards compatibility, but I think that would only make things much harder for us. I'm willing to start fresh with the caveat that old designs would need to point to old libraries. In the past the desire for backwards compatibility was a stumbling block for this, but perhaps we just need to accept the breakage. I'm also willing to consider a new method for auto-generating families of footprints. I think M4 is not the preferred method for anyone anymore, despite a general disagreement about what *is* preferred :-) If the default lib is to be changed now, then there should be some kind of new consensus on the heavy/light issue. IIRC there are a few proposals and/or active solutions in play: * Standard library is light, users heavyify them (we need a better verb for that ;) into a project-specific (or even site-global) heavy symbol library. * Standard library is heavy, users either use those as-is or modify them to alternate heavy symbols. * Standard library is light, the tools automatically heavyify them based on some database somewhere (both static and dynamic conversions have been seen/suggested). * Standard library is some mix of heavy/light. I think this is what we have now, although not ideally implemented. In all cases, one key problem is that there are so many potential heavy symbols that we cannot possibly have all of them. The solutions either accept a common subset of heavy symbols or defer the problem to the user, who only puts effort intothe symbols they needed. My own proposal (posted in the past) is here: http://www.delorie.com/pcb/component-dbs.html It moves the problem out of gschem and into the netlister, which gives PCB the opportunity to be part of the process as well (the netlist can accept input from both gschem and pcb), but adds the requirement for back-annotation for those who prefer the master schematics to have that info in them. It is also an optional step in the flow, so it doesn't block other solutions (like a heavy-only library). Note that any solution should have these attributes: * It should be easy to go from a light symbol to a heavy one, so that users can add, say, a generic resistor to a schematic and later allocate a specific part to it. While text editing is technically easy, it doesn't streamline into a gui-centric flow, mor is it readily scriptable. * New users should find it easy to make their first PCB. This might mean a starter set of heavy symbols, or it might mean the GUI is streamlined for heavyifying light ones. * It should be equally easy for newbies to, say, do their first simulation. This might mean an alternate database for sim vs layout with modes, or it might mean distinct domains for heavyifying so that one schematic can hold both sets of information, or it might mean storing flow-specific heavy data elsewhere and merging in the netlister. * Massively scripted flows should remain massively scriptable, while gui-centric flows should remain gui-centric. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: translucent tracks in PCB-head!
On Fri, 20 May 2011 21:02:51 +0200 Kai-Martin Knaak kn...@iqo.uni-hannover.de wrote: Hi. A few minutes ago, I fetched the latest PCB sources from git and recompiled. Surprise: The resulting binary includes translucent tracks and polygons! This is both, beautiful and very useful. See the attached screenshot. Some of these days, Peter Clifton must have been silently pushing his patches to the main tree. -- Extra friggin big THANK YOU !! Agreed - thanks a bunch for pushing those changes through, Peter! -- There are some things in life worth obsessing over. Most things aren't, and when you learn that, life improves. http://digitalaudioconcepts.com Vanessa Ezekowitz vanessaezekow...@gmail.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: translucent tracks in PCB-head!
why do you have a through hole ic On Fri, May 20, 2011 at 12:02 PM, Kai-Martin Knaak kn...@iqo.uni-hannover.de wrote: Hi. A few minutes ago, I fetched the latest PCB sources from git and recompiled. Surprise: The resulting binary includes translucent tracks and polygons! This is both, beautiful and very useful. See the attached screenshot. Some of these days, Peter Clifton must have been silently pushing his patches to the main tree. -- Extra friggin big THANK YOU !! Note, this is real transparency like it should be. Not like the composite colors that eagle, kicad and protel99 use to make hidden objects visible. IMHO, the more physical model of GL transparency adds to the usability. ---)kaimartin(--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key: http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: translucent tracks in PCB-head!
Yea!! This is fantastic! On Fri, May 20, 2011 at 2:02 PM, Kai-Martin Knaak kn...@iqo.uni-hannover.de wrote: Hi. A few minutes ago, I fetched the latest PCB sources from git and recompiled. Surprise: The resulting binary includes translucent tracks and polygons! This is both, beautiful and very useful. See the attached screenshot. Some of these days, Peter Clifton must have been silently pushing his patches to the main tree. -- Extra friggin big THANK YOU !! Note, this is real transparency like it should be. Not like the composite colors that eagle, kicad and protel99 use to make hidden objects visible. IMHO, the more physical model of GL transparency adds to the usability. ---)kaimartin(--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key: http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user -- http://evanfoss.googlepages.com/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
On Fri, 20 May 2011 12:01:59 -0400 DJ Delorie d...@delorie.com wrote: [Subject changed to start new thread] [...] When I first read geda documentation, there were already references that this had been discussed ad nauseam. If the default lib is to be changed now, then there should be some kind of new consensus on the heavy/light issue. IIRC there are a few proposals and/or active solutions in play: * Standard library is heavy, users either use those as-is or modify them to alternate heavy symbols. I say go with this - because users already have to modify nearly all the symbols they use in a schematic when using the existing library. This way, most of the symbols will have default footprints and other attributes that will do just fine. At the very least, I don't think it would make the end user's workload any worse. If it breaks someone's workflow temporarily, they'll have to adapt. Such things are commonplace with far more major upgrades than an EDA package. I think of office suites and even whole OSs, which often end up requiring formal re-training when upgraded. -- There are some things in life worth obsessing over. Most things aren't, and when you learn that, life improves. http://digitalaudioconcepts.com Vanessa Ezekowitz vanessaezekow...@gmail.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
Oh boy am I glad y'all are having this conversation, and I hope you don't mind some comments from the peanut gallery. On Fri, May 20, 2011 at 11:01 AM, DJ Delorie [1]d...@delorie.com wrote: [Subject changed to start new thread] When I first read geda documentation, there were already references that this had been discussed ad nauseam. Sigh, yes. It's not an easy problem to solve, and I would consider any solution a major effort because it touches everything from gschem to pcb to sim. No it isn't easy but for the reasons mentioned above has the potential to improve gEDA usability (ergo adoption) in significant ways. ...the ability for the user to manage their library from either gschem or pcb would be ideal. Yes please! (right click and or hotkey - attach footprint to symbol) Bonus points for backwards compatibility, but I think that would only make things much harder for us. I'm willing to start fresh with the caveat that old designs would need to point to old libraries. In the past the desire for backwards compatibility was a stumbling block for this, but perhaps we just need to accept the breakage. I'm also willing to consider a new method for auto-generating families of footprints. I think M4 is not the preferred method for anyone anymore, despite a general disagreement about what *is* preferred :-) Put me down for intense dislike of M4. Sorry. I'm sure it's a fine choice for some, but I've never had to touch or know anything about M4 for anything else, ever. Which means that on some occasion that all I had wanted to do was make a printed circuit board; now I have to go and learn enough about M4 to make my little footprint(s). It also means that I'll probably do something wrong, or in a non-optimal way, since I'll never use it enough to achieve any sort of proficiency. tl;dr I would love an easier way to generate footprints. If the default lib is to be changed now, then there should be some kind of new consensus on the heavy/light issue. There are many perfectly reasonable occasions / individuals who would prefer the heavy option. It is also reasonable to say that the light option gets you the most flexibility. After years of watching this debate go nowhere, may I suggest that you must either find a way to do both, or tell some of us to bugger off. IIRC there are a few proposals and/or active solutions in play: * Standard library is light, users heavyify them (we need a better verb for that ;) into a project-specific (or even site-global) heavy symbol library. * Standard library is heavy, users either use those as-is or modify them to alternate heavy symbols. * Standard library is light, the tools automatically heavyify them based on some database somewhere (both static and dynamic conversions have been seen/suggested). * Standard library is some mix of heavy/light. I think this is what we have now, although not ideally implemented. In all cases, one key problem is that there are so many potential heavy symbols that we cannot possibly have all of them. Nobody needs all possible heavy symbols, and disk space is cheap. The solutions either accept a common subset of heavy symbols or defer the problem to the user, who only puts effort intothe symbols they needed. Which puts many (often novice users) to the task of creating their own symbol/footprints, and probably doing it wrong. This is bad for so many reasons, not the least of which is that there will be so much duplicated effort spent on a very mundane task, like creating a symbol/footprint for some three-terminal regulator, or TTL logic gate or something. My own proposal (posted in the past) is here: [2]http://www.delorie.com/pcb/component-dbs.html It moves the problem out of gschem and into the netlister, which gives PCB the opportunity to be part of the process as well (the netlist can accept input from both gschem and pcb), but adds the requirement for back-annotation for those who prefer the master schematics to have that info in them. It is also an optional step in the flow, so it doesn't block other solutions (like a heavy-only library). Note that any solution should have these attributes: * It should be easy to go from a light symbol to a heavy one, so that users can add, say, a generic resistor to a schematic and later allocate a specific part to it. While text editing is technically easy, it doesn't streamline into a gui-centric flow, mor is it readily scriptable. * New users should find it easy to make their first PCB. Yes! New users, casual users, experienced users, all users. This might mean a
Re: gEDA-user: Solving the light/heavy symbol problem
I say go with this - because users already have to modify nearly all the symbols they use in a schematic when using the existing library. This way, most of the symbols will have default footprints and other attributes that will do just fine. Ok, then how do we generate the thousands, if not millions, of symbols we'll need? How do we choose what the default set of parts should be? Just among the few of us here, we've already found out that just picking through-hole vs smt is not a clear choice. If we come up with a way to do that, we'll also have a way for the user to do it. No matter how complete a heavy-only library is, it won't be complete enough, so we *still* need to make sure the user has a way to add to their library. And consider that, no matter how heavy a symbol is, you can always make it heavier. Let's say we ship a symbol for a 4.7k 0603 resistor. Does it include manufacter's part numbers? Vendor name? Tolerance? These are additional data the user could add. Where does it come from? How do they add it? Should we add it up front? Why? I like the idea of including a set of heavy symbols as a starter pack - maybe a few sets of them (through-hole vs smt, for example) - but I think we need to also allow for a set of light symbols too, and think about the process of user-heavyifying them. This, along with how do I create new symbols/footprints is a common stumbling block for new users. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
And consider that, no matter how heavy a symbol is, you can always make it heavier. Let's say we ship a symbol for a 4.7k 0603 resistor. Does it include manufacter's part numbers? Vendor name? Tolerance? These are additional data the user could add. Where does it come from? How do they add it? Should we add it up front? Why? Yes users must be able to add metadata, ie: company internal part numbers, document numbers, etc. I like the idea of including a set of heavy symbols as a starter pack - maybe a few sets of them (through-hole vs smt, for example) - but I think we need to also allow for a set of light symbols too, and think about the process of user-heavyifying them. This, along with how do I create new symbols/footprints is a common stumbling block for new users. How about (right-click, attach footprint to symbol?) Heck, it would also be nice to be able to switch footprints from within PCB; for example, when changing a board from thru-hole to SMT. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
I would love an easier way to generate footprints. Now that we're pre-parsing all the M4 footprints anyway, perhaps we could allow for a range of scripting options in the Makefiles that generate the library? There have been a few footprint-specific languages developed over the years. In all cases, one key problem is that there are so many potential heavy symbols that we cannot possibly have all of them. Nobody needs all possible heavy symbols, and disk space is cheap. No, but if we choose a subset, we pretty much guarantee that there will be users who need something we left out. I don't want to be replicating Digikey's database, for example, but any part I leave out is a part someone else might need. defer the problem to the user, who only puts effort intothe symbols they needed. Which puts many (often novice users) to the task of creating their own symbol/footprints, and probably doing it wrong. Hmm... but does this mean we should do the work for them, or does this mean we need to come up with a better way for them to do the work? * New users should find it easy to make their first PCB. Yes! New users, casual users, experienced users, all users. This is why I see no clear win between just heavy and just light - different users at different levels need different solutions. A new (to geda) user should be able to pick common parts from a list and make *something* that works, but an experienced user will eventually need to make their own. Don't ship gSchem or PCB with any. At first run, and in preferences, and in config files, give users the ability to choose their own poison. Use git to If we go with the idea of more than one library, we can ship a starter library (like, Radio Shack 500-in-1 parts list, or Spice 101 with examples) and let the user import libraries from, say, gedasymbols. With my scheme, that would be a starter database instead, but similar results. Actually, with gedasymbols, *anyone* can make a small self-contained heavy symbol library. The problem happens when you want to make a self-contained *light* symbol library, then you need more logic in the tools to heavyify them. synchronize with a (set of) master symbol and or footprints, and or something else databases. Include options to use others' symbols / parts (gedasymbols, luciani, etc). Include options for users to share their own symbols via git. Create online symbol and footprint generators that create standard footprints (at least for JEDEC standard stuff) properly (according to best practices). hmmm... think about how a simple http:// changed the way we share information across the Internet. Think of how Facebook changed the way people manage their social lives. Are we prepared to put the effort into making something of *that* scale, for EDA? It would be cool if we got it right, but a pain if we didn't. This also allows for footprints-by-cgi, another level of scripting them. Or script://$prefix/pcb/dip-generator.pl?pins=16width=300mil etc. By the way, if you guys decide to tackle a big re-write, the IPC and NIST tried to tackle this problem a few years ago. We've been using standard names for new footprints at least. When we can :-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: translucent tracks in PCB-head!
yamazakir2 wrote: why do you have a through hole ic These are TDA2030 that drive the peltier -- These are reliable, powerful and and cheap. To tap their power, they need to be screwed to a sizable cooler. 15 W heat cannot be easily dissipated into a copper polygon plane. ---)kaimartin(--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
I'm have no a lot of expirience in PCB creation, so may be I don't know something, but I have following suggestions: Just now my workflow is the next: 1. I draw scheme in gschem. 2. I run gsch2pcb and look for errors like this: WARNING: C5 has no footprint attribute so won't be in the layout. C5: deleted element 0805 (value=20pF) 3. I go again to gschem and manually fix missed footprints. As I understend on the last step gattrib coud be used But for me it is useless, 'cos I just can enter value and don't see the preview of footprint. So, may be it would be usefull to add for gattrib preview feature vith library navigation and add to gschem somekinde of bridge to new gattrib utility? 2011/5/21 DJ Delorie [1]d...@delorie.com I would love an easier way to generate footprints. Now that we're pre-parsing all the M4 footprints anyway, perhaps we could allow for a range of scripting options in the Makefiles that generate the library? There have been a few footprint-specific languages developed over the years. In all cases, one key problem is that there are so many potential heavy symbols that we cannot possibly have all of them. Nobody needs all possible heavy symbols, and disk space is cheap. No, but if we choose a subset, we pretty much guarantee that there will be users who need something we left out. I don't want to be replicating Digikey's database, for example, but any part I leave out is a part someone else might need. defer the problem to the user, who only puts effort intothe symbols they needed. Which puts many (often novice users) to the task of creating their own symbol/footprints, and probably doing it wrong. Hmm... but does this mean we should do the work for them, or does this mean we need to come up with a better way for them to do the work? * New users should find it easy to make their first PCB. Yes! New users, casual users, experienced users, all users. This is why I see no clear win between just heavy and just light - different users at different levels need different solutions. A new (to geda) user should be able to pick common parts from a list and make *something* that works, but an experienced user will eventually need to make their own. Don't ship gSchem or PCB with any. At first run, and in preferences, and in config files, give users the ability to choose their own poison. Use git to If we go with the idea of more than one library, we can ship a starter library (like, Radio Shack 500-in-1 parts list, or Spice 101 with examples) and let the user import libraries from, say, gedasymbols. With my scheme, that would be a starter database instead, but similar results. Actually, with gedasymbols, *anyone* can make a small self-contained heavy symbol library. The problem happens when you want to make a self-contained *light* symbol library, then you need more logic in the tools to heavyify them. synchronize with a (set of) master symbol and or footprints, and or something else databases. Include options to use others' symbols / parts (gedasymbols, luciani, etc). Include options for users to share their own symbols via git. Create online symbol and footprint generators that create standard footprints (at least for JEDEC standard stuff) properly (according to best practices). hmmm... think about how a simple http:// changed the way we share information across the Internet. Think of how Facebook changed the way people manage their social lives. Are we prepared to put the effort into making something of *that* scale, for EDA? It would be cool if we got it right, but a pain if we didn't. This also allows for footprints-by-cgi, another level of scripting them. Or script://$prefix/pcb/[2]dip-generator.pl?pins=16width=300mil etc. By the way, if you guys decide to tackle a big re-write, the IPC and NIST tried to tackle this problem a few years ago. We've been using standard names for new footprints at least. When we can :-) ___ geda-user mailing list [3]geda-user@moria.seul.org [4]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:d...@delorie.com 2. http://dip-generator.pl/?pins=16width=300mil 3. mailto:geda-user@moria.seul.org 4. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
On 20/05/11 17:01, DJ Delorie wrote: * Standard library is light, users heavyify them (we need a better verb for that ;) into a project-specific (or even site-global) heavy symbol library. Personally, I'd say that this is a sensible way to go. I'd then suggest having an extra set of options somewhere (perhaps even have an entire beginner mode), and this guides people through the heavification of symbols. For example, when you select a component to add to the schematic, it offers some help by suggesting a set of frequently used footprints (probably generated from the user's MRU list), along with suggesting addition of other attributes. The other thing that I find insanely useful is gedasymbols. I don't suggest for a single moment that shipping the entire gedasymbols library with gEDA/PCB is a good idea, but perhaps the following should be considered (no idea if it's actually possible): - gEDA has a way of detecting a network connection. - If connected, search will also search gEDAsymbols, and on request download the sym (and possibly its associated footprint). This, again, would certainly help with streamlining my workflow, as I tend to spend a fair amount of time opening tabs and browsing to gedasymbols. I don't think shipping heavy symbols is a good idea - it is easier to go from light - heavy, than the other way, even if it's only a few mouse clicks away. One final comment about this: Perhaps the proposed sym+metadata+fp is the way forward - the metadata is basically a set of overrides on the sym and fp data, and everything gets dealt with that way. Just my 2 cents. Chris ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
On Fri, May 20, 2011 at 12:01:59PM -0400, DJ Delorie wrote: My own proposal (posted in the past) is here: http://www.delorie.com/pcb/component-dbs.html I like this idea a lot. Allowing pcb and gschem to use different (multiple) databases with different backends gives us a lot of freedom. It would let us ship, say, a sqlite database with a bunch of defaults (after bickering endlessly about what such defaults might be), while shops or even gedasymbols.org might have a real SQL db so that everyone has the same footprint data. It would also greatly simplify packaging and versioning, since these database backends can be changed by sql scripts, can store metadata, etc. It moves the problem out of gschem and into the netlister, which gives PCB the opportunity to be part of the process as well (the netlist can accept input from both gschem and pcb), but adds the requirement for back-annotation for those who prefer the master schematics to have that info in them. It is also an optional step in the flow, so it doesn't block other solutions (like a heavy-only library). -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
It would let us ship, say, a sqlite database with a bunch or OOo spreadsheet, or CSV text file, or even a web server CGI. See also: http://www.gedasymbols.org/csv.html ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On Sat, May 21, 2011 at 1:26 AM, Kai-Martin Knaak kn...@iqo.uni-hannover.de wrote: Colin D Bennett wrote: Not to get into the whole light/heavy symbol debate Maybe, it is time to look at this issue again. When I first read geda documentation, there were already references that this had been discussed ad nauseam. As a result, the default lib was the way it was and is. This is six year back now. Since then, this topic has not been raised on the mailing list. But there are Except for some bug fixes, the default lib stayed the same for all the years. No symbols were added, none was removed, nothing was restructured. If the default lib is to be changed now, then there should be some kind of new consensus on the heavy/light issue. Else, the effort might end in religious war and, or frustration. There will always be a place for both heavy and light. People's work flows vary too much to limit gEDA to just one. One thing worth thinking about is closer integration of gschem and pcb with gedasymbols.org. If our programs obtained symbols directly from there it would get people out of the mind-set that there is just one library of symbols. The reality is that our community provides a bazaar of different symbols and philosophies of symbol creation. It would be great if we also had an easier way to contribute symbols back (perhaps with just a mouse click or two). ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
On Fri, May 20, 2011 at 4:14 PM, DJ Delorie [1]d...@delorie.com wrote: Yes users must be able to add metadata, ie: company internal part numbers, document numbers, etc. Do they add meta-data to the symbol, the footprint, or store it elsewhere? Well, as an example, I insert some unique identifier (company part number), or keyword, etc in some field, or even as a comment in the symbol or footprint file. Later, I can grep for the unique identifier, and find all the places I've used it. This kind of thing has been helpful for building BOMs that the purchasing folk won't try to have you tarred and feathered for. We *do* have the option of changing our symbol-footprint library into a symbol-metadata-footprint scheme. Maybe gnetlist is feeling left out, and wants its own library and GUI :-) Heck, it would also be nice to be able to switch footprints from within PCB; for example, when changing a board from thru-hole to SMT. I've considered that too. It means either pcb has to be able to talk to gschem, or gschem and pcb need to share a separate metadata container. I.e. a project would be schematics+metadata+layout, not just schematics+layout. It looks to me like the schem + metadata + layout is where you're headed. I can't see how else to integrate all that stuff, and still have gSchem + PCB remain separate entities (which is as it should be). Couldn't you consider maintaining some backwards-compatibility by having the metadata file simply contain references to the symbol files (plus other garbage, spice, kitchen sinks, etc), and footprint files? That should only require a minimal effort on the part of gSchem to read the new metadata file. Here's another link to the IPC-2581 stuff. [2]http://webstds.ipc.org/2581/2581intro.htm References 1. mailto:d...@delorie.com 2. http://webstds.ipc.org/2581/2581intro.htm ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Broken TO92 footprint
On Thu, May 19, 2011 at 4:25 PM, Colin D Bennett [1]co...@gibibit.com wrote: On Thu, 19 May 2011 14:02:58 -0400 Vanessa Ezekowitz [2]vanessaezekow...@gmail.com wrote: The discussion about reinventing the wheel reminded me: The TO92 footprint included with PCB does not work with the schematic importer therein. Try to reference it and the importer complains about missing pins, because it uses numbered pins instead of the B-C-E lettering used in gschem's transistor symbols. Copy and edit the footprint to use those letters and the importer complains about pin numbers ending in letters. Isn't a word of caution in order, since not all TO-92 transistors use the same order of B/C/E pins? Yes, I think there is supposed to be a TO-92A, TO-92B, and TO-92C (the different orders) but nobody paid enough attention, and I'm not sure if this is standard, or merely convention. see attached gif that was stolen from [3]http://www.kss.sd23.bc.ca/chalmers/robotics10/Labs/ComparePNPNPN/how Explained.htm References 1. mailto:co...@gibibit.com 2. mailto:vanessaezekow...@gmail.com 3. http://www.kss.sd23.bc.ca/chalmers/robotics10/Labs/ComparePNPNPN/howExplained.htm attachment: tranlead.gif ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
Chris Malton wrote: On 20/05/11 17:01, DJ Delorie wrote: * Standard library is light, users heavyify them (we need a better verb for that ;) into a project-specific (or even site-global) heavy symbol library. Personally, I'd say that this is a sensible way to go. This is the way it is since at least six years. Unfortunately, it does not fit three of the four attributes on DJs wishlist. ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
On Fri, 20 May 2011 16:54:20 -0400 DJ Delorie d...@delorie.com wrote: I say go with this - because users already have to modify nearly all the symbols they use in a schematic when using the existing library. This way, most of the symbols will have default footprints and other attributes that will do just fine. Ok, then how do we generate the thousands, if not millions, of symbols we'll need? I've been thinking about that, and to be blunt, I have no frickin' clue. ;-) Maybe some clever scripting against a set of generic parts (similar to what I did with those footprints I just submitted). How do we choose what the default set of parts should be? Just among the few of us here, we've already found out that just picking through-hole vs smt is not a clear choice. The only fair way to handle this is to use gschem to conduct a sort of extended poll - the program itself could submit a data point to some central site each time the user instantiates a symbol or adds an attribute that affects the final build of the device (but only in ways that matter for this vote), with some kind of mechanism for changing one's vote when an attribute is changed. The server would compile all that data into a list of symbol - (footprint, device, manufacturer, ...) mappings and whatever floats to the top for any given symbol after, say, 6 months becomes the default for that symbol. If we come up with a way to do that, we'll also have a way for the user to do it. No matter how complete a heavy-only library is, it won't be complete enough, so we *still* need to make sure the user has a way to add to their library. For that, I'd say keep the existing mechanism for now, but suggest a default location for such creations (.gEDA/symbols/ and .gEDA/footprints/ sound fair). Let the user override these settings in the programs' respective config files, or make a couple of symlinks, if they want to use something other than these proposed defaults. I have Gschem and PCB set to use the two directories where my gedasymbols.org symbols and footprints are stored, so that those files are always available no matter what project I'm working on. And consider that, no matter how heavy a symbol is, you can always make it heavier. Let's say we ship a symbol for a 4.7k 0603 resistor. Does it include manufacter's part numbers? Vendor name? Tolerance? These are additional data the user could add. Where does it come from? How do they add it? Should we add it up front? Why? Choose attributes that result in an easy-to-hand-assemble board. That way a quick schematic-to-PCB export will result in a board that one could at least fab, even if it means the user has to flip back and forth between the schematic and hard-copy BoM sheets to find part values. The idea is to get from schematic to board-in-hand with as little trouble as possible. I like the idea of including a set of heavy symbols as a starter pack - maybe a few sets of them (through-hole vs smt, for example) - but I think we need to also allow for a set of light symbols too, and think about the process of user-heavyifying them. This, along with how do I create new symbols/footprints is a common stumbling block for new users. Sounds fair, but I could see a situation where this could overload the user. How about adding these options to the library browser: - Show symbols where footprints are... [ ] Through-hole [ ] Basic SMT -- catch-all for single resistors, caps, SOTs, etc. [ ] PLCC [ ] SOIC [ ] SSOP/TSSOP [ ] BGA [ ] Board-edge devices [ ] Unspecified - We *do* have the option of changing our symbol-footprint library into a symbol-metadata-footprint scheme. Maybe gnetlist is feeling left out, and wants its own library and GUI :-) Careful, you'll incur John Doty's wrath. ;-) -- There are some things in life worth obsessing over. Most things aren't, and when you learn that, life improves. http://digitalaudioconcepts.com Vanessa Ezekowitz vanessaezekow...@gmail.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
On Fri, May 20, 2011 at 4:09 PM, DJ Delorie [1]d...@delorie.com wrote: I would love an easier way to generate footprints. Now that we're pre-parsing all the M4 footprints anyway, perhaps we could allow for a range of scripting options in the Makefiles that generate the library? There have been a few footprint-specific languages developed over the years. In all cases, one key problem is that there are so many potential heavy symbols that we cannot possibly have all of them. Nobody needs all possible heavy symbols, and disk space is cheap. No, but if we choose a subset, we pretty much guarantee that there will be users who need something we left out. I don't want to be replicating Digikey's database, for example, but any part I leave out is a part someone else might need. You could collect users' statistics anonymously and let it be a popularity contest. Especially if the databases were centralized. defer the problem to the user, who only puts effort intothe symbols they needed. Which puts many (often novice users) to the task of creating their own symbol/footprints, and probably doing it wrong. Hmm... but does this mean we should do the work for them, or does this mean we need to come up with a better way for them to do the work? I'm hoping for a better way for them to do the work or even, machine does most of the work Teach them to fish and all that. * New users should find it easy to make their first PCB. Yes! New users, casual users, experienced users, all users. This is why I see no clear win between just heavy and just light - different users at different levels need different solutions. A new (to geda) user should be able to pick common parts from a list and make *something* that works, but an experienced user will eventually need to make their own. Don't ship gSchem or PCB with any. At first run, and in preferences, and in config files, give users the ability to choose their own poison. Use git to If we go with the idea of more than one library, we can ship a starter library (like, Radio Shack 500-in-1 parts list, or Spice 101 with examples) and let the user import libraries from, say, gedasymbols. With my scheme, that would be a starter database instead, but similar results. Actually, with gedasymbols, *anyone* can make a small self-contained heavy symbol library. The problem happens when you want to make a self-contained *light* symbol library, then you need more logic in the tools to heavyify them. synchronize with a (set of) master symbol and or footprints, and or something else databases. Include options to use others' symbols / parts (gedasymbols, luciani, etc). Include options for users to share their own symbols via git. Create online symbol and footprint generators that create standard footprints (at least for JEDEC standard stuff) properly (according to best practices). hmmm... think about how a simple http:// changed the way we share information across the Internet. Think of how Facebook changed the way people manage their social lives. Are we prepared to put the effort into making something of *that* scale, for EDA? It would be cool if we got it right, but a pain if we didn't. Here's some pie-in-the sky for you. I can imagine a database with which a small number of users has full commit privileges, others' symbols / footprints (perhaps even by default / automatically) will be submitted, which would in turn generate a vetting request whereby a user with full access could approve or deny the new or modified files. Some effort would also be spent getting a machine to look for common mistakes and automatically reject them. I'd love to see it get all Web2.0-ish, and I think it could work very well. (if I only knew how to make it so). This also allows for footprints-by-cgi, another level of scripting them. Or script://$prefix/pcb/[2]dip-generator.pl?pins=16width=300mil etc. Yes, this too. I've naively wished a thousand times or more for a machine that could take as its input a pdf datasheet, and produce as its output, symbols and footprints in some magically standardized format. By the way, if you guys decide to tackle a big re-write, the IPC and NIST tried to tackle this problem a few years ago. We've been using standard names for new footprints at least. When we can :-) Don't take any of this personally. I have a great affection and appreciation for gEDA and it's principles and goals. References 1. mailto:d...@delorie.com 2. http://dip-generator.pl/?pins=16width=300mil ___ geda-user mailing list geda-user@moria.seul.org
Re: gEDA-user: An opportunity to fix the symbol library
Ales Hvezda wrote: The symbols in the current default lib fail for both. Why don't you use gedasymbols.org to show us how you would fix the current gEDA/gaf shipped symbol library. In a way, I already do ;-) See my section at gedasymbols.org. Of course, the actual choice of components was guided by the kind of projects I do. And I did not strive for completeness beyond what I actually need. Create your ideal library, IMHO, we all agree, that there is no such thing in a general sense. No size fits all. That does not preclude improvement over the current situation. no limits, or restrictions. Also, feel free to use as much disk space on gedasymbols.org (I have explicit permission from DJ) as you need. Size wouldn't be an issue, anyway. In fact, I believe, the default libs should be cut down to essentials -- Few instances, but excellent quality, ready to use. Given the availability of gedasymbols.org, there is no point to have several GND symbols and three kinds of BC247. Such a lib can act as a starting point for first projects and for a localized set of libs. Let people know it exists, use it, and comment on it. Then, we can compare your symbol library to the broken shipped symbol library and see if it makes sense to switch. I consider to bite... ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
It would be great if we also had an easier way to contribute symbols back (perhaps with just a mouse click or two). The only limit I put on gedasymbols is accountability. I want to make sure that if a symbol or footprint is up there, you know who's responsible for it. Solutions which meet that need would be acceptable to me Well, my time is limited too, they'd have to be easy solutions :-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
Couldn't you consider maintaining some backwards-compatibility by having the metadata file simply contain references to the symbol files (plus other garbage, spice, kitchen sinks, etc), and footprint files? That should only require a minimal effort on the part of gSchem to read the new metadata file. My thought on that would be that PCB gives gnetlist information about the layout (pin swapping, package changes, etc) and gnetlist reads the schematics, applies the metadata and layout changes, and generates updates for the layout. Or, reads it all and generates an annotated schematic. No reason why gschem couldn't run the netlister itself, with a different backend that gives it the same metadata in a gschem-friendly format. That way, you can make changes in pcb and not worry about getting them out of sync with the schematics, and you an have both light and annotated schematics, or you can back-annotate your schematics. It seemed like it would cover all the bases. For backwards compatibility, you just have an empty (or no) metadata, so you get whatever's in the schematics. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
Metadata can be a parallel task. In gschem you pick your resistor. You have two buttons, place lite, place heavy. Place heavy brings up a second wizard to populate the heavy symbol, probably from your database. Then place your symbol. In pcb, when you import a schematic. Any parts without footprints gets listed. Then you can populate the right footprint. And a back annotation mechanism to update upstream schematics. As a third tool for series workflows sch in to output updated sch, bom, and netlist. Perhaps with features like, general remapping of footprints to the smallest package in your library. Or to your preferred hand soldering size for that type of component. Like ranking 0603 first, 0805 second, and 0402 third. Based on parameters like value and tolerance. Option to use only the heavy part specified, i.e. Don't change out this part. Steve On May 20, 2011, at 6:34 PM, Cullen Newsom cullennew...@gmail.com wrote: On Fri, May 20, 2011 at 4:09 PM, DJ Delorie [1]d...@delorie.com wrote: I would love an easier way to generate footprints. Now that we're pre-parsing all the M4 footprints anyway, perhaps we could allow for a range of scripting options in the Makefiles that generate the library? There have been a few footprint-specific languages developed over the years. In all cases, one key problem is that there are so many potential heavy symbols that we cannot possibly have all of them. Nobody needs all possible heavy symbols, and disk space is cheap. No, but if we choose a subset, we pretty much guarantee that there will be users who need something we left out. I don't want to be replicating Digikey's database, for example, but any part I leave out is a part someone else might need. You could collect users' statistics anonymously and let it be a popularity contest. Especially if the databases were centralized. defer the problem to the user, who only puts effort intothe symbols they needed. Which puts many (often novice users) to the task of creating their own symbol/footprints, and probably doing it wrong. Hmm... but does this mean we should do the work for them, or does this mean we need to come up with a better way for them to do the work? I'm hoping for a better way for them to do the work or even, machine does most of the work Teach them to fish and all that. * New users should find it easy to make their first PCB. Yes! New users, casual users, experienced users, all users. This is why I see no clear win between just heavy and just light - different users at different levels need different solutions. A new (to geda) user should be able to pick common parts from a list and make *something* that works, but an experienced user will eventually need to make their own. Don't ship gSchem or PCB with any. At first run, and in preferences, and in config files, give users the ability to choose their own poison. Use git to If we go with the idea of more than one library, we can ship a starter library (like, Radio Shack 500-in-1 parts list, or Spice 101 with examples) and let the user import libraries from, say, gedasymbols. With my scheme, that would be a starter database instead, but similar results. Actually, with gedasymbols, *anyone* can make a small self-contained heavy symbol library. The problem happens when you want to make a self-contained *light* symbol library, then you need more logic in the tools to heavyify them. synchronize with a (set of) master symbol and or footprints, and or something else databases. Include options to use others' symbols / parts (gedasymbols, luciani, etc). Include options for users to share their own symbols via git. Create online symbol and footprint generators that create standard footprints (at least for JEDEC standard stuff) properly (according to best practices). hmmm... think about how a simple http:// changed the way we share information across the Internet. Think of how Facebook changed the way people manage their social lives. Are we prepared to put the effort into making something of *that* scale, for EDA? It would be cool if we got it right, but a pain if we didn't. Here's some pie-in-the sky for you. I can imagine a database with which a small number of users has full commit privileges, others' symbols / footprints (perhaps even by default / automatically) will be submitted, which would in turn generate a vetting request whereby a user with full access could approve or deny the new or modified files. Some effort would also be spent getting a machine to look for common mistakes and automatically reject them. I'd love to see it get all Web2.0-ish, and I think it could work very well. (if I only knew how to make it so). This also allows for
Re: gEDA-user: Solving the light/heavy symbol problem
Ok, then how do we generate the thousands, if not millions, of symbols we'll need? I've been thinking about that, and to be blunt, I have no frickin' clue. ;-) Maybe some clever scripting against a set of generic parts (similar to what I did with those footprints I just submitted). Yup, I also figured you'd need some sort of database-driven scripting to generate them all. Then I realized, you don't need to run the script at build time, you only need to be able to run the script as needed by the user - then we don't have thousands of resistor symbols, we have one (or a few) resistor symbols and thousands of lines in a database. Then we replace the database with a CGI at digikey... ;-) Of course, we just reversed this for the M4 footprint library. Mostly because M4 is a bad choice these days, though, not because scripting itself is bad. The only fair way to handle this is to use gschem to conduct a sort of extended poll I wouldn't want information about user's schematics leaked, the privacy issues are too dangerous. However, we could collect stats about things downloaded from, say, gedasymbols. Perhaps we could have a small number of starter libraries on gedasymbols, and the geda installer prompts you to pick one to download. We track how many downloads of each, and use that to decide which to include in the distribution. Or we include them all in the distro, let the user pick, and who cares which one is more popular :-) And consider that, no matter how heavy a symbol is, you can always make it heavier. Let's say we ship a symbol for a 4.7k 0603 resistor. Does it include manufacter's part numbers? Vendor name? Tolerance? These are additional data the user could add. Where does it come from? How do they add it? Should we add it up front? Why? Choose attributes that result in an easy-to-hand-assemble board. Well, yes, but that wasn't the point I was trying to make. If the user *wants* to add more info to a part, they need a way to do it. That way should be easy for them. Sounds fair, but I could see a situation where this could overload the user. How about adding these options to the library browser: - Show symbols where footprints are... [ ] Through-hole [ ] Basic SMT -- catch-all for single resistors, caps, SOTs, etc. [ ] PLCC [ ] SOIC [ ] SSOP/TSSOP [ ] BGA [ ] Board-edge devices [ ] Unspecified - Well, this looks like either (1) multiple available libraries, pick one, or (2) what I proposed for the component database model. It sounds like we're agreeing that geda needs a way to manage libraries, at least, rather than having a library. We *do* have the option of changing our symbol-footprint library into a symbol-metadata-footprint scheme. Maybe gnetlist is feeling left out, and wants its own library and GUI :-) Careful, you'll incur John Doty's wrath. ;-) I've always thought of gattrib as gnetlist's GUI but they're not *that* related. The component database (i.e. netlister's metadata) idea *would* make then that related, though. Gattrib would become the metadata GUI. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
I'm hoping for a better way for them to do the work or even, machine does most of the work Teach them to fish and all that. Teach them to fish, yes, but make them figure out how to make a fishing pole from scratch? *I* might like that, but most users wouldn't. Hence the it should be easy part. (if I only knew how to make it so). That's the problem, yes. We can all come up with great ideas, but someone has to be able to turn them into reality. Yes, this too. I've naively wished a thousand times or more for a machine that could take as its input a pdf datasheet, and produce as its output, symbols and footprints in some magically standardized format. My twopad and dilpad CGIs were designed for this, sort of. You fill in whatever parameters the datasheet decided to give you, it generates a suitable footprint. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: An opportunity to fix the symbol library
In a way, I already do ;-) See my section at gedasymbols.org. Feel free to post a tarball or other installer, so that the users can replace geda's library with yours. John Luciani did that on his site, you can do it on gedasymbols if you want. Make it a copy of the library you actually use, doesn't require much work, just make it available to others. Create your ideal library, IMHO, we all agree, that there is no such thing in a general sense. No size fits all. That does not preclude improvement over the current situation. Surely, you could come up with a library that at least fits *your* needs? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
On Fri, 20 May 2011 22:37:58 -0400 DJ Delorie d...@delorie.com wrote: Ok, then how do we generate the thousands, if not millions, of symbols we'll need? I've been thinking about that, and to be blunt, I have no frickin' clue. ;-) Maybe some clever scripting against a set of generic parts (similar to what I did with those footprints I just submitted). Yup, I also figured you'd need some sort of database-driven scripting to generate them all. [...] Then we replace the database with a CGI at digikey... ;-) At first, I laughed, but then I began to wonder about that Of course, we just reversed this for the M4 footprint library. Mostly because M4 is a bad choice these days, though, not because scripting itself is bad. The only fair way to handle this is to use gschem to conduct a sort of extended poll I wouldn't want information about user's schematics leaked, the privacy issues are too dangerous. I suppose that's true. However, we could collect stats about things downloaded from, say, gedasymbols. Perhaps we could have a small number of starter libraries on gedasymbols, and the geda installer prompts you to pick one to download. We track how many downloads of each, and use that to decide which to include in the distribution. That's a good idea, as long as the symbols are easy to install - probably a good idea to add an option to download and install them, sorta like Firefox's add-ons manager. How about adding these options to the library browser: - Show symbols where footprints are... [...] Well, this looks like either (1) multiple available libraries, pick one, or (2) what I proposed for the component database model. It would probably require a database, yeah. Still, I was thinking of it in terms of filtering the view against the entire library, and the user could have all checkboxes ticked if they want to see everything all at once (i.e. like now). It sounds like we're agreeing that geda needs a way to manage libraries, at least, rather than having a library. We *do* have the option of changing our symbol-footprint library into a symbol-metadata-footprint scheme. Maybe gnetlist is feeling left out, and wants its own library and GUI :-) Careful, you'll incur John Doty's wrath. ;-) I've always thought of gattrib as gnetlist's GUI but they're not *that* related. True, but in this case I was thinking of his argument that adding GUI options to something automatically breaks it. :-) -- There are some things in life worth obsessing over. Most things aren't, and when you learn that, life improves. http://digitalaudioconcepts.com Vanessa Ezekowitz vanessaezekow...@gmail.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
However, we could collect stats about things downloaded from, say, gedasymbols. Perhaps we could have a small number of starter libraries on gedasymbols, and the geda installer prompts you to pick one to download. We track how many downloads of each, and use that to decide which to include in the distribution. That's a good idea, as long as the symbols are easy to install - probably a good idea to add an option to download and install them, sorta like Firefox's add-ons manager. I think we should start thinking in terms of libraries, not individual symbols. Adding a gedasymbols library should be as simple as downloading some metadata about the library (title, author, url, copyright, index, description) and then choosing if you wanted to download a tarball for local access, or talking to gedasymbols directly (automatic updates might break your schematic though). Such libraries can be as small as a few parts, or as big as a digikey database, but we should expect them to include both symbols and footprints, and if we got the metadata route, the metadata. I.e. make them self-contained. or libraries could have a depends-on tag in them for other libraries, I suppose. A Renesas MCU symbol library could depend on a generic chip package footprint library. We should still support individual symbols and footprints, of course, but I'm thinking the expectations work better if we prefer groups of self-consistent symbols and footprints. For example, a transistor from the Vanessa library would use footprints from the Vanessa library, even if same-named footprints were available elsewhere. Hmmm... we'd have to keep track of the chain of origin for each symbol/footprint, so if you modify a Vanessa footprint and store it in your local library, the tools know to use that one instead of the original Vanessa one. It would probably require a database, yeah. Still, I was thinking of it in terms of filtering the view against the entire library, and the user could have all checkboxes ticked if they want to see everything all at once (i.e. like now). Yup. I figured you could have site rules, project rules, and if that doesn't narrow it down, a popup telling you what choices remained. The project rules would be your checkboxes, either a custom menu that turns into a database query, or data-driven pick from the following like digikey's search engine. With clever database choices, they'd both be the same anyway :-) But if we're adding support for multiple libraries, that complicates things. I'm not sure if such a feature (multiple libraries) belongs in geda/pcb themselves, or hidden behind some data server that combines the available libraries and presents one unified library to the tools. But enabling/disabling libraries could serve the same function as your filter box, if the libraries are set up right. Maybe we'll end up needing both. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: An opportunity to fix the symbol library
Kai-Martin Knaak, [snip] No size fits all. That does not preclude improvement over the current situation. DJ and I are asking you to improve the current situation by creating, distributing, and maintaining a better default symbol library than the one that is currently shipped with gEDA/gaf. -Ales ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
