Re: gEDA-user: Idea/suggestion for improving the gschem GUI
On Mon, 26 Apr 2010 12:08:05 -0600, John Doty wrote: Please remember that features and capabilities are largely opposed in software. No matter how often you repeat this statement, it is still wrong. Features and capabilities are orthogonal concepts, not exclusive. ---)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: Idea/suggestion for improving the gschem GUI
On Apr 27, 2010, at 7:26 AM, Kai-Martin Knaak wrote: On Mon, 26 Apr 2010 12:08:05 -0600, John Doty wrote: Please remember that features and capabilities are largely opposed in software. No matter how often you repeat this statement, it is still wrong. Features and capabilities are orthogonal concepts, not exclusive. In principle, yes. That's why I said largely. In practice, it's difficult, especially if you don't put the problem at the top of your list of concerns. Remember, the bare hardware without any software at all has the greatest potential. Every line of code added to the software system takes away from that potential. This is necessary, of course. You have the hardware for specific purposes, and the software serves these. But one should not ignore the cost in lost capability. gEDA has an unusually good combination of breadth of capability and usability. That breadth goes far beyond what any individual user experiences. But we have a variety of needs: that breadth serves us collectively even if it doesn't serve us individually. If you don't perceive the size of that universe, you will ask for damaging things. If we don't appreciate gEDA's strengths, we will lose them. Don't it always seem to go That you don't know what you've got Till it's gone They paved paradise And put up a parking lot 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: Idea/suggestion for improving the gschem GUI
On Apr 27, 2010, at 11:26 AM, Armin Faltl wrote: Remember, the bare hardware without any software at all has the greatest potential. Every line of code added to the software system takes away from that potential. This is necessary, of course. You have the hardware for specific purposes, and the software serves these. But one should not ignore the cost in lost capability. Let's assume you got an operating system, that let's an application take total control of the hardware, like DOS did. Clearly the OS provides a service by loading the application. Then the application overwrites the OS with data, so as to not waste any space before it delivers the result and after producing the output it terminates by going into an undefined state, so as not to waste any space for termination code. So how does this OS limit the hardware? - sure it limits the program length available for the application, That's one. It may even prevent the use of minimal hardware: the application may require fewer resources than the OS. Another disadvantage of an OS is that booting straight into the application is faster. It's not so much that potential slips away rapidly with added code, but modern programmers are so good at producing vast volumes of code and so poor at producing well-factored code. This seems to be a particular problem for pcb, where there's a constant drumbeat of questions, both here and on the chat, of the form why doesn't feature x work with feature y? but in practice this opposed, orthogonal, features, capabilities is all ... How do you define a capability of a program with 0 (zero) features? Potential versus capability. Potential is essential for capability. So are features. But features take away potential. This is especially true for features considered in isolation, without consideration of factoring. The bare hardware 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: gattrib
I guess part of my problem with gschem, pcb, and gsch2pcb is that I never understood what gattrib was for. I though it was an internal function used by gschem and gsch2pcb to get the values of symbols attributes out of the schematic file. I never realized it was intended for humans to use. And I DEFINITELY did not understand that it entered new values into the tables. Perhaps if it were called editattrib or setattrib it would be more obvious to newcommers to use it after creating light symbols in gcshem to add pcb footprints and other 'heavy symbol' attributes that are more easily handled in text. Also, this might be more clearly explained in the tutorials. But I still think that some tool, between gschem and pcb so that neither needs to change and John Doty can be happy, that matches up the graphics PCB footprints with the symbol, maybe a text compare of pin names or functions to see if pin 1 of the symbol matches pin A of the footprint. I also like the idea of a database of component part numbers, critical specs like capacitance, resistance, wattage, peak reverse voltage, and also had a footprint for that part. I just cower at the sheer scale of building such a database from many different distributors supplying parts from so many different vendors, each using different styles for their spec sheets, only most of which are online and in PDF form. If we can build such a database, that would help tremendously. But creating it and maintaining it, even with just static data like that listed above, would be a tremendous amount of work. Mike Not because of the bugs I ran into but since choosing a footprint is a difficult process in it self I was longing for a footprint browser. The easiest place to start a clean implementation may be gattrib, that I found conventient to duplicate footprint choices, once one has been assigned gschem. However, the best overview of what is what and therefore choose the right footprint is probably gschem. With gschem open, gattrib should work however, if one remembers, that gschem is in read only then. The problem could be split out of gschem, if it were better supported, to assign a physical part to the symbol. This will probably help other tools too, since e.g. a Spice model is tied to a part, not to a bunch of lines with pins (symbol). I first thought device were the thing to use, but in the standard library it's occupied by names like CAPACITOR_POLARIZED which says noting about rated voltage or ESR. Any ideas? Just my 2 cents ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gattrib
On Apr 27, 2010, at 12:26 PM, Mike Bushroe wrote: Not because of the bugs I ran into but since choosing a footprint is a difficult process in it self I was longing for a footprint browser. My personal view is that schematics should use the conventions in the gEDA documentation: http://geda.seul.org/wiki/geda:pcb_footprint_naming_conventions These refer to the device, not the pattern of copper on the board. The pattern of copper corresponding to a given device footprint should be chosen in the layout process, because it depends (like other layout parameters) on the manufacturing processes. A database-driven tool that maps device footprints into layout footprints would be useful. We could have databases for various requirement sets here. Keeping the responsibility for this out of gschem avoids unnecessary complication and facilitates design reuse: the schematic should be as free as possible from dependencies on the layout and manufacturing processes. 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
gEDA-user: Fab, Pick and Place, Stencil
I've not run PCB for a couple of years. Is there a way to generate a stencil and pick and place files for the fab shops. The fab shops seem able to generate them from gerbers but that implies that the operator correctly reads the silk screen and copper layers. Ian. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Fab, Pick and Place, Stencil
Paste gerbers are created automatically. I usually use a scripts that reads the .pcb file, generates a new one with pad sizes adjusted, and generate the paste stencils from that (paste apertures always match the pad sizes). For pick-n-place, do a BOM export. It has an X-Y option. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Fab, Pick and Place, Stencil
On 04/27/2010 04:52 PM, DJ Delorie wrote: For pick-n-place, do a BOM export. It has an X-Y option. Is there a theta? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Fab, Pick and Place, Stencil
Is there a theta? I think so, but it's unreliable because we just guess. The assembly house will most likely massage the data anyway. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Database on symbols, footprints and other (was Re: gattrib)
Hi, since the stuff I managed to layout with your help is soldered now and shining brightly, I got some time, to have a look at my attempt to a database. So I have to take levels of abstraction and their naming serious. John Doty wrote: On Apr 27, 2010, at 12:26 PM, Mike Bushroe wrote: Not because of the bugs I ran into but since choosing a footprint is a difficult process in it self I was longing for a footprint browser. My personal view is that schematics should use the conventions in the gEDA documentation: http://geda.seul.org/wiki/geda:pcb_footprint_naming_conventions Agree with adhering to the convention, don't agree with the convention. The simple reason for my critics on the convention is case-use: studies in the aera of teletyping have shown, that lower case is faster to read than uppercase. That and the limit on bandwidth is why teletypes used all lowercase letters. Then computers appeared on the sceen and some sales-managers found, that upper case letters look more professional than lowercase letters. That and the limit on bandwidth is, why the 1st computer terminals used all uppercase ;-) Now compare the following: PART 1: AXHN868X888 PART 2: AXBN868X888 PART 3: AXHN8688X88 vs. part 1: axhn868x888 part 2: axbn868x888 part 3: axhn8688x88 I don't want to suggest to deviate from well known acronyms like DIN, but why must we use an uppercase X for separation of dimensions and the like? (And what are Basic SMT semiconductors? surface mounted tevices ?) Some of the convention-based names seem to contain spaces. From what I read, the trailing non-space groups are actually macro parameters for the m4-processor. This should be dealt with somehow I think, since it clashes with easy file treatment and newlib is the way to go, isn't it? These refer to the device, not the pattern of copper on the board. The pattern of copper corresponding to a given device footprint should be chosen in the layout process, because it depends (like other layout parameters) on the manufacturing processes. For me a device is a MAX232 or HCTL-2016, both sitting in a DIL-16 package (among other possibilties). So actually the convention above would describe canonical names for packages. So far in all datasheets I read, the copper pattern if at all is specified with dimensions and no mention is made of any manufacturing process (or I just ignored it, knowing my hand-soldering capabilities being far from um-precision). Still I want the database to provide for such detail and distinguish between package and footprint. A database-driven tool that maps device footprints into layout footprints would be useful. We could have databases for various requirement sets here. One thing that comes to mind with integrating simulator-models in the database is, that the package for a given device influences parameters like parasitic capacitance of pins. The more so does the copper pattern of the pads including layers below the actual pad. - would we want to address this in a database? Where does it end? (if this sounds weird, go to www.analog.com, search for rarely asked questions and then find RAQ_capacitycectomy.pfd - it's fun to read IMO) Keeping the responsibility for this out of gschem avoids unnecessary complication and facilitates design reuse: the schematic should be as free as possible from dependencies on the layout and manufacturing processes. Agree. Armin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Stencil and Pick and Place
I've not run PCB for a couple of years. Is there a way to generate a stencil and pick and place files for the fab shops. The fab shops seem able to generate them from gerbers but that implies that the operator correctly reads the silk screen and copper layers. Ian. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Idea/suggestion for improving the gschem GUI
Remember, the bare hardware without any software at all has the greatest potential. Every line of code added to the software system takes away from that potential. This is necessary, of course. You have the hardware for specific purposes, and the software serves these. But one should not ignore the cost in lost capability. Sorry, this to me is the most surreal argument I have come across for a while. This hardware capability that is suggested reduced by every line of code added by the programmer is certainly not intrinsic to the hardware. The capability comes from the programmer. This argument seems similar to suggesting that somehow the canvas that Leonardo da Vinci painted the Mona Lisa on contained the capability rather than da Vinci. I agree with advocacy for well factored code, and agree that it often seems that programmers are generating a glut of code, rather than thinking ahead and producing less lines but of better written work. But better that we have poor code with *some* functionality than hardware that has infinit potential, zero lost capability and no functionality whatsoever. As someone who often falls into the trap of not doing something at all because I don't feel I have the time or capability to do a job to a percieved high standard; I would warn against arguments like these because often just getting some sort of functionality is better than nothing at all. I presume the real concern here is that gEDA will lose capability by people adding features or functionality that restrict existing capability or similar. This perhaps is a valid concern. I enjoy reading this list because I am constantly coming across people using gEDA in such a way that capability of the gEDA suite that I had no idea was there is revealed. I think one of the PR problems gEDA has is that on the surface it often does not appear capable (but ongoing changes to the wiki and website are helping greatly in this respect). Perhaps as more people become aware of the capability of gEDA and how to leverage it, arguments about additional features etc will become less frequent. Geoff PS I hope I do not cause offence with my 2 cents in this argument. I am simply doing my best to disagree respectfully. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gattrib
John Doty: These refer to the device, not the pattern of copper on the board. The pattern of copper corresponding to a given device footprint should be chosen in the layout process, because it depends (like other layout parameters) on the manufacturing processes. I am still confused by your continual assertion that the copper pattern should be completely separate from the physical part. As pointed out above, a DIP-16 is a through-hole device in any process, the pins are always 0.100 inches apart, the part number defines if it is a typical 300 mill spacing, or a wide 600 mill. What ever process you use to attach the chip to a circuit board, those things never change for that physical part number. The closest I can guess to something that would be 'process dependent' would be the size of the copper pads, and possibly the exclusion zone around them. I could see having one version for hand soldered work, with 40 mill pads and only enough room to run one signal line between them; and a professional fab shop version with 15 mill pads, 10 mill or smaller traces and and spaces and room for 4 or more signals between pins. If there was a parameter that could be set by gattrib for each part, or gsch2pcb for all to pick from fat or skinny pads, I could see some use in that. But as far as I know, you can also do all of that in pcb, so there is no range of process variation that still uses a 16 pin dip that could not be edited in pcb. So why must we divorce the copper pattern from the component? How divergent a process are you holding out for that would still be laid out in pcb? Mike ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gattrib
On Apr 27, 2010, at 5:43 PM, Mike Bushroe wrote: John Doty: These refer to the device, not the pattern of copper on the board. The pattern of copper corresponding to a given device footprint should be chosen in the layout process, because it depends (like other layout parameters) on the manufacturing processes. I am still confused by your continual assertion that the copper pattern should be completely separate from the physical part. As pointed out above, a DIP-16 is a through-hole device in any process, the pins are always 0.100 inches apart, the part number defines if it is a typical 300 mill spacing, or a wide 600 mill. What ever process you use to attach the chip to a circuit board, those things never change for that physical part number. The closest I can guess to something that would be 'process dependent' would be the size of the copper pads, and possibly the exclusion zone around them. I could see having one version for hand soldered work, with 40 mill pads and only enough room to run one signal line between them; and a professional fab shop version with 15 mill pads, 10 mill or smaller traces and and spaces and room for 4 or more signals between pins. These properties are critical, not trivial at all. If there was a parameter that could be set by gattrib for each part, Each part? Ugh! Specify the parameters of the *process*, leave the schematics alone. Aside from the fact that a part by part process is miserably low productivity, there's no reason to restrict a schematic to a particular process downstream. or gsch2pcb for all to pick from fat or skinny pads, I could see some use in that. But as far as I know, you can also do all of that in pcb, so there is no range of process variation that still uses a 16 pin dip that could not be edited in pcb. So why must we divorce the copper pattern from the component? How divergent a process are you holding out for that would still be laid out in pcb? This is exactly the kind of tunnel vision that scares me. I have never used pcb, but I've designed quite a few printed circuit boards with gEDA (along with several VLSI chips, where footprint is irrelevant). This works because gschem is agnostic about what's downstream. It should stay that way. 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: gattrib
On Apr 27, 2010, at 5:43 PM, Mike Bushroe wrote: As pointed out above, a DIP-16 is a through-hole device in any process, the pins are always 0.100 inches apart, the part number defines if it is a typical 300 mill spacing, or a wide 600 mill. What ever process you use to attach the chip to a circuit board, those things never change for that physical part number. Yes. Therefore footprint=DIP16, as recommended in the footprint naming conventions document, should be fine. The closest I can guess to something that would be 'process dependent' would be the size of the copper pads, and possibly the exclusion zone around them. Who says there are pads? Some still use wire-wrap. gEDA would be a fine way to feed an automated wire-wrap process, although I don't know if anyone has actually done this. Imagine, then, feeding the identical schematics to a pcb flow once the wire-wrap prototype is working... 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
