gEDA-user: Seeing pin numbers in PCB
Being lazy I am importing footprints other folks kindly made for pcb. Unfortunately, I am not very trusting, so I want to check they are correct. I can measure the size of stuff using gerbv (there may be a better way to do this in pcb), but I can't tell if the right pin numbers have been assigned very easily. Is there a way to see this in PCB? Oliver ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Resistor values…
On Wed, 29 Dec 2010 13:24:18 +0100 Levente Kovacs wrote: > On Sat, 25 Dec 2010 00:50:07 -0600 > Vanessa Ezekowitz wrote: > > > * If the part in question can usually be described by a single value, > > for the purposes of the signal flow in the schematic that is, then > > give it a default of "value=0". > > That is bad. You have to think twice that "is it a 0 Ohm resistor, or do I > missed to attach normal value of that device?" True, which is why I later suggested using a string like "0.0" - something that no one would deliberately type. Then the computer could use that as a trigger to highlight the symbol or whatever. > > * If it is a discrete part that is specified entirely by its part > > number rather than a measurement, like a diode or a transistor, then > > pick a reasonable default; "value=1N914" or "value=2N". > > Again. Is it the default or real? Nobody knows. The idea was to save some work for the majority of use cases (assume for the moment the most popular parts as defaults, rather than the ones I mentioned above). Default or not, the string would still be valid - it remains the responsibility of the user to decide if his or her schematic specifies the right parts. > > * If none of these fits, then leave the "value=" attribute off > > entirely, since the user would have no choice but to get creative > > anyway. > > That will make gnetlist to crash! :-) Believe me I tried! I spent nights > manually seeking for this. Don't do it. In that case, gnetlist should be crashing all the time, since the current symbol library is pretty much devoid of this attribute now. I'm suggesting, in this instance, that symbols that meet this condition simply remain as they are today (don't add or remove anything from the symbols). -- "There are some things in life worth obsessing over. Most things aren't, and when you learn that, life improves." http://starbase.globalpc.net/~ezekowitz Vanessa Ezekowitz ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Resistor values…
On Mon, Dec 27, 2010 at 3:56 AM, Vanessa Ezekowitz wrote: > On Sun, 26 Dec 2010 23:55:04 -0500 > al davis wrote: > >> On Saturday 25 December 2010, Vanessa Ezekowitz wrote: >> > * If the part in question can usually be described by a >> > single value, for the purposes of the signal flow in the >> > schematic that is, then give it a default of "value=0". >> >> No. Zero is almost always wrong. > > Exactly my point - it is *supposed* to be wrong. > > I chose zero here because anyone who sees it in their schematic file should > instantly think, "Oops, I forgot to set the value of that part". From my own > experience, it is easier to spot something that is visibly flat out wrong > than to look for something that is just not there. > > Setting it to zero by default could even be used to signal Gschem to add an > extra highlight to those symbols bearing it. Perhaps the default, > highlight-sensitive string should be exactly "0.0" or some variation of that, > since no sane user would type anything but a single "0" when they mean "zero". > No valid number should be used for a "default" in such a generic symbol. I use 0 ohm resistors often, they are stuffing shorts. a default of ? is obvious, it clearly shows a value that has not been assigned. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Resistor values…
>> >> Setting it to zero by default could even be used to signal Gschem to add an >> extra highlight to those symbols bearing it. > > Yuck. Keep tools simple and clean. Agreed, but if you wanted a DRC highlighter, a ? highlighted would be a great thing to highlight. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Resistor values…
On Wed, 29 Dec 2010 13:18:24 -0500 DJ Delorie wrote: I regret that I made that comment. > I wish it weren't so common. Such wars are a pointless waste of time > and serve only to drive valuable contributors away. Soon, the only > people "working" on gEDA/PCB will be those who enjoy complaining, as > there will be nobody left willing to wade through the bitter arguments > and actually write code. I agree with you. But I think that it is a fact that there are lots of wars. We should really concentrate on "work". > So let me make this perfectly clear - if you're not willing to write > code, your complaints about how others write code will fall on deaf > ears. As far as I know, those of us who DO write code, do it for > purely selfish reasons - we benefit from our own work. We've said > this before, it should be no surprize to anyone. I think in an open source domain, users and "code writers" are pretty much the same. I consider myself a user, but there is code in PCB of mine. I've written a few scripts for gEDA/PCB as well. It is not much, I know. I am willing to write code, but I'm not good at code writing (Never tried it seriously though). > OTOH if you have suggestions on how to make gEDA/PCB better - easier > to use, more functional, etc - feel free to voice them. If you can > back them up with a solid design and usability models, that's even > better. Discussions about the details and caveats are to be expected! Yes! I meant "war" that I feel everyone dumps their experience, favourite tool, etc. without working the problem. > But as soon as the discussion degrades into yet another bikeshedding, > the instigators of said bikeshedding have lost all credibility with > me. > > New users - ask your questions without regret. There are no bad > questions. Harvest the answers that are useful and ignore the crap. Yes. The "let us start a Vi vs. Emacs" comment was a joke. -- Levente Kovacs http://levente.logonex.eu ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: scripting (was Resistor values???)
On Wed, Dec 29, 2010 at 08:51:19PM +0100, Stephan Boettcher wrote: > John Doty writes: > > > On Dec 29, 2010, at 6:23 AM, Stephan Boettcher wrote: > > > >> I can imagine that it's not a lot, since this is really a classical > >> case for said design pattern. > > > > The real difficulty here is the complexity of the Guile<->C > > interface. The functions and data on the C side are accessible to the > > midlayer only to the extent that somebody does the (difficult) work of > > exporting them. The C front end is very procedural, performing much > > semantic processing regardless of whether the back end ever requests > > the results. Not a good match to the factored, functional approach. > > Than that is the interface that needs to be morphed according to the > prescribed pattern: the C<->Guile interface. > > And when that's the case, a clean C-API that can be exported to Guile, > Python, Ruby, C++, Fortran, ... just dreaming. I once started to do that to PCB usign libgpmi, and got a plugin that exports a small portion of PCB internals through some sort of higher level APIs to any scripting language libgpmi supports (10 at the moment). After scripting 1-2 plugins I really needed, development stalled, as I am the only user of the plugin. I think you'd get the same for a similar project around gschem, as gschem developers already speak guile so having other scripting languages will be interesting only as a theoretical possibility, not as a practical feature. At least, with my pcb-gpmi plugin feedback always was "wow, very nice, very interesting, will try some day". Btw, I still use it weekly, since I have a nice (partial) HPGL exporter written in awk. Regards, Tibor ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Resistor values…
On Dec 28, 2010, at 7:32 PM, John Griessen wrote: > On 12/28/2010 06:21 PM, John Doty wrote: >> Well, the plug-in wasn't that difficult. > > Thanks for contributing some code John. I'm in the midst of a > lot of obligations and low cash. I'll try to give it a look before January > is gone. Well, I think it belongs on my gedasymbols page. It isn't core functionality: it's a special-purpose add-on, so it doesn't belong in the basic release. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Resistor values…
As one of the principal troublemakers, let me comment. On Dec 29, 2010, at 11:18 AM, DJ Delorie wrote: > > Levente Kovacs writes: >> So don't regret it, it is getting common. > > I wish it weren't so common. Then show a real commitment to the toolkit, not just to pcb for hobbyists. Lip service to the idea that you won't damage the toolkit doesn't count. My own work flow has been damaged by thoughtless changes, most seriously by the "promote footprints by default" change. > Such wars are a pointless waste of time > and serve only to drive valuable contributors away. You assume contributions are good. But "there's no bottom to worse". gEDA is pretty good as is: there are a lot more ways to damage it than improve it. If the current crop of developers actually used the tool to some approximation of its breadth of application, I'd feel much better. > Soon, the only > people "working" on gEDA/PCB will be those who enjoy complaining, as > there will be nobody left willing to wade through the bitter arguments > and actually write code. Those of us actually using the toolkit to its limits, and extending it with scripts and plugins, don't count in this valuation. But gEDA's unique strength lies there, I think. There are plenty of free/cheap alternatives for hobbyist use, but not so many when you really need the breadth of gEDA's capabilities. This doesn't mean I am opposed to hobbyists: indeed, much prototype/experimental work I do is functionally indistinguishable from a hobby approach, so the effectiveness of gEDA for such an approach is important to me personally. I hope we can welcome hobbyists, but I also hope we can avoid channeling the toolkit into hobbyist-specific flows. There's a difference. > > So let me make this perfectly clear - if you're not willing to write > code, your complaints about how others write code will fall on deaf > ears. How about complaints about how others *break* working flows? And could easily do so again in the future? > As far as I know, those of us who DO write code, do it for purely > selfish reasons - we benefit from our own work. We've said this before, > it should be no surprize to anyone. > > OTOH if you have suggestions on how to make gEDA/PCB better - Divorce gEDA from pcb. Create a schematic plugin for pcb, since that seems to be what pcb users want. The flexibility of the gschem/gnetlist flow is unnecessary to hobbyists. The current developers are dangerously pcb-centric. > easier to > use, more functional, etc - feel free to voice them. If you can back > them up with a solid design and usability models, that's even better. > Discussions about the details and caveats are to be expected! Top-down thinking. Inappropriate for a toolkit with unlimited extensibility. The end point will be a tool, full of fat and sugar, useful only to hobbyists. One of the greatest resources for gEDA is gedasymbols.org. Thank you very much for setting that up. We can't agree on how good symbols should be constructed, but we can nevertheless share them. And it has grown beyond symbols and footprints to other sorts of add-ons. That's the way to proceed, I think: keep gEDA clean, lean, and mean, and solicit contributions that optionally extend it. The core developers should not be gatekeepers for "features". This approach works very well for other free software: TeX, Perl, Python, ... The barriers to further "grassroots" improvement of gEDA are failures of factored, orthogonal design. The kind of suggestions you want are superficial. We already know where the source of gEDA's limitations lies: no more suggestions are required. Implementing suggested features piecemeal will only make the tool less flexible, more arcane, and more difficult to repair when repairs are needed. And if you're really serious about having more developers working on extending the toolkit, the benefits of bottom-up refactoring should be obvious. > > New users - ask your questions without regret. Yes. Please. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Resistor values…
On Dec 29, 2010, at 12:51 PM, Stephan Boettcher wrote: > John Doty writes: > >> On Dec 29, 2010, at 6:23 AM, Stephan Boettcher wrote: >> >>> I can imagine that it's not a lot, since this is really a classical >>> case for said design pattern. >> >> The real difficulty here is the complexity of the Guile<->C >> interface. The functions and data on the C side are accessible to the >> midlayer only to the extent that somebody does the (difficult) work of >> exporting them. The C front end is very procedural, performing much >> semantic processing regardless of whether the back end ever requests >> the results. Not a good match to the factored, functional approach. > > Than that is the interface that needs to be morphed according to the > prescribed pattern: the C<->Guile interface. > > And when that's the case, a clean C-API that can be exported to Guile, > Python, Ruby, C++, Fortran, ... just dreaming. Will you settle for a clean Haskell API that can be exported to Scheme and Lua? Things get a bit eccentric when you have a logician coding for a physicist ;-) John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Resistor values…
John Doty writes: > On Dec 29, 2010, at 6:23 AM, Stephan Boettcher wrote: > >> I can imagine that it's not a lot, since this is really a classical >> case for said design pattern. > > The real difficulty here is the complexity of the Guile<->C > interface. The functions and data on the C side are accessible to the > midlayer only to the extent that somebody does the (difficult) work of > exporting them. The C front end is very procedural, performing much > semantic processing regardless of whether the back end ever requests > the results. Not a good match to the factored, functional approach. Than that is the interface that needs to be morphed according to the prescribed pattern: the C<->Guile interface. And when that's the case, a clean C-API that can be exported to Guile, Python, Ruby, C++, Fortran, ... just dreaming. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Resistor values…
Levente Kovacs writes: > So don't regret it, it is getting common. I wish it weren't so common. Such wars are a pointless waste of time and serve only to drive valuable contributors away. Soon, the only people "working" on gEDA/PCB will be those who enjoy complaining, as there will be nobody left willing to wade through the bitter arguments and actually write code. So let me make this perfectly clear - if you're not willing to write code, your complaints about how others write code will fall on deaf ears. As far as I know, those of us who DO write code, do it for purely selfish reasons - we benefit from our own work. We've said this before, it should be no surprize to anyone. OTOH if you have suggestions on how to make gEDA/PCB better - easier to use, more functional, etc - feel free to voice them. If you can back them up with a solid design and usability models, that's even better. Discussions about the details and caveats are to be expected! But as soon as the discussion degrades into yet another bikeshedding, the instigators of said bikeshedding have lost all credibility with me. New users - ask your questions without regret. There are no bad questions. Harvest the answers that are useful and ignore the crap. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Resistor values…
On Dec 29, 2010, at 6:23 AM, Stephan Boettcher wrote: > > John Doty writes: > >> A better netlister for simulation is difficult as long as the gnetlist >> front end has hard-coded semantics, especially for hierarchy and >> slotting. > > Last year (June 2009) LWN published a very nice series by Neil Brown > about successful design pattern in the Linux kernel. A lot of that is > applicable to any sizeable project. > > One pattern is to define (midlayer) interfaces like the gnetlist backend > interface in terms of library functions. > > http://lwn.net/Articles/336262/ > > To fix gnetlist, the hardcoded semantics shall not be pushed to the > backend, but offered as a library function, to be pulled in by the > backend. The infrastructure provided by the library shall offer various > levels to access the netlist data. The toplevel shall provide the > current hardcoded semantics to the existing backends, but future backends > may choose to use replace the top level call by copies where some > critical second level calls are replaced. Such copies, when universally > usefull, can be moved from the backend to the library at some point. > > Somebody who (unlike me) actually knows how that interface looks like > right now, may comment on how much actually needs to change. Well, a typical net-centric flat netlist back end may conveniently grab a list of the nets it needs to process from the variable all-unique-nets, defined in gnetlist-post.scm. That's great, but in fact it's just a trivial extract from the primitive (gnetlist:get-all-unique-nets). Then, there's the primitive (gnetlist:get-all-nets) that doesn't check for uniqueness. So, while there's a bit of incipient pattern like you describe, it's not very deep, and it's strangely tangled. Why have *two* primitives here? *Neither* of them is really a primitive operation. At the very least (gnetlist:get-all-unique-nets) could be defined in terms of (gnetlist:get-all-nets). Then, why always invoke (gnetlist:get-all-unique-nets) to construct all-unique-nets whether it's needed or not? One answer here is that the front end has already done the heavy work beforehand, so it costs very little, but shouldn't the front end only be doing this on demand? > I can > imagine that it's not a lot, since this is really a classical case for > said design pattern. The real difficulty here is the complexity of the Guile<->C interface. The functions and data on the C side are accessible to the midlayer only to the extent that somebody does the (difficult) work of exporting them. The C front end is very procedural, performing much semantic processing regardless of whether the back end ever requests the results. Not a good match to the factored, functional approach. The existing API, despite all this chaos, is truly excellent for small-scale flat printed circuit board netlisting, and unusually extensible beyond that. But it falls down in places where it inappropriately inflicts the semantics of small-scale flat printed circuit board netlisting on different flows, especially DRC and simulation. I cannot think of *any* semantic processing of schematics that is universally appropriate for all flows. A truly well-factored gnetlist would thus have only one primitive function for processing schematics: parse a schematic file. The schematic semantics would all be in midlayer functions. The back end and other plugins could use these (or not) as needed. But that's a fair amount of work. At Noqsi, we're playing around with the beginnings of something like this at https://github.com/xcthulhu/lambda-geda. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Resistor values…
2010/12/29 Levente Kovacs : > On Sat, 25 Dec 2010 22:01:43 +0100 > "Johnny Rosenberg" > wrote: > >> Hm… I start to regret that I asked the question in the first place… > > We are very good at making wars. We make wars on "what kind of fileformat to > use", "what kind of documentation tool to use", "what is gschem used for" etc. > > So don't regret it, it is getting common. > > Lets make a vi vs. emacs war! Yes, that's do that! He he he… Or maybe not… I used Emacs a lot in the early 1990's, especially for IRC and playing MUD an things like that, but these days I don't use any of them. I found that with a few plugins and some configuration, gedit does everything I need a text editor for, so far at least. Well, off topic in any case. Johnny Rosenberg > > Levente > > -- > Levente Kovacs > http://levente.logonex.eu > > > ___ > 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: Resistor values…
John Doty writes: > A better netlister for simulation is difficult as long as the gnetlist > front end has hard-coded semantics, especially for hierarchy and > slotting. Last year (June 2009) LWN published a very nice series by Neil Brown about successful design pattern in the Linux kernel. A lot of that is applicable to any sizeable project. One pattern is to define (midlayer) interfaces like the gnetlist backend interface in terms of library functions. http://lwn.net/Articles/336262/ To fix gnetlist, the hardcoded semantics shall not be pushed to the backend, but offered as a library function, to be pulled in by the backend. The infrastructure provided by the library shall offer various levels to access the netlist data. The toplevel shall provide the current hardcoded semantics to the existing backends, but future backends may choose to use replace the top level call by copies where some critical second level calls are replaced. Such copies, when universally usefull, can be moved from the backend to the library at some point. Somebody who (unlike me) actually knows how that interface looks like right now, may comment on how much actually needs to change. I can imagine that it's not a lot, since this is really a classical case for said design pattern. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Resistor values…
On Sat, 25 Dec 2010 22:01:43 +0100 "Johnny Rosenberg" wrote: > Hm… I start to regret that I asked the question in the first place… We are very good at making wars. We make wars on "what kind of fileformat to use", "what kind of documentation tool to use", "what is gschem used for" etc. So don't regret it, it is getting common. Lets make a vi vs. emacs war! Levente -- Levente Kovacs http://levente.logonex.eu ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Resistor values…
On Sat, 25 Dec 2010 00:50:07 -0600 Vanessa Ezekowitz wrote: > * If the part in question can usually be described by a single value, > for the purposes of the signal flow in the schematic that is, then > give it a default of "value=0". That is bad. You have to think twice that "is it a 0 Ohm resistor, or do I missed to attach normal value of that device?" > * If it is a discrete part that is specified entirely by its part > number rather than a measurement, like a diode or a transistor, then > pick a reasonable default; "value=1N914" or "value=2N". Again. Is it the default or real? Nobody knows. > * If the part is something like a logic IC, use the standard name of > the part in the fastest commonly available series for that particular > gate; "value=74F74" or "value=74HCT245". > > * If none of these fits, then leave the "value=" attribute off > entirely, since the user would have no choice but to get creative > anyway. That will make gnetlist to crash! :-) Believe me I tried! I spent nights manually seeking for this. Don't do it. What I do is I keep my symbols light. Sometimes it doesn't even have pin-numbers! After I made my design, I update all my symbols, and attributes with an updater script, which pulls everything from a MySQL database. Levente -- Levente Kovacs http://levente.logonex.eu ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: bugs, warts and feature requests (3)
On Thu, 23 Dec 2010 12:43:45 +0100
kai-martin knaak wrote:
> • pcb feature request: Please put all the gerbers in a dedicated
> subdir of the working directory by default. The name of the subdir
> should be configurable.
>
> • pcb feature request: Optionally zip all gerbers and the cnc files
> to yield a single file that can be sent to the fab. The name of the
> zip file might contain the current date.
The two can be done by hand or scripts or Makefile, etc. Like I did (a
Makefile snipet):
gerber: ${PCBNAME}.pcb
${PCB} -x gerber --gerberfile ${PCBOUTDIR}/${FILEBASE} ${PCBNAME}.pcb
later in the Makefile:
output: clean_output gerber pdf
cp ${FILEBASE}.pdf ${PCBOUTDIR}
tar -jcvf ${FILEBASE}_${DATE_S}.tar.bz2 ${PCBOUTDIR}
rar a ${FILEBASE}_${DATE_S}.rar ${PCBOUTDIR}
Levente
--
Levente Kovacs
http://levente.logonex.eu
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: How to make a foot print
On Wed, 22 Dec 2010 17:29:24 -0800 Colin D Bennett wrote: > You are not alone. Making footprints in pcb takes a lot of practice, > for me a least. I have made many footprints in pcb over the past > couple of years and still I have to refer to guidelines, if I haven't > made a footprint for some time and have gotten rusty. I recommend using footprint generators for the majority of the footprits. I use the footgen.py python script. I have created most of my footprints with the script. The inputs for footgen can be found here: http://git.logonex.eu/?p=library.git;a=tree;f=electronic/autolib/footprints;hb=HEAD All of my footprints including the generated and the manually drawn ones is located here: http://git.logonex.eu/?p=library.git;a=tree;f=electronic/footprint;hb=HEAD Levente -- Levente Kovacs http://levente.logonex.eu ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
