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
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: Reinventing the wheel
Kai-Martin Knaak k...@lilalaser.de writes: Stephan Boettcher wrote: Judging the code by lack of comments without knowledge of the language is too. I referred to the lack of documentation, rather than lack of comments. The particular case I had in mind, is the interaction of gnetlist's C front-end with the scheme back-ends. There seems to be no documentation whatsoever, what data structure the front-end should use to communicate with the back-end. Ok, yes, that is a valid point... the lack of documented APIs. -- Stephan ___ 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
Kai-Martin Knaak k...@lilalaser.de writes: Stephan Boettcher wrote: Why is there so much discussion here about the needs of potential new users, instead of the needs of current, loving, existing users? Let's make the tools perfect for us (that includes discoverability and documentation improvements), and not cater for not-yet-users. In my case, this is essentially the same. If students find geda more difficult and less attractive than eagle, I have a hard time to convince them to use the right tool. Why do you have this notion of _right tool_? Let them use what they want. My colleagues use eagle. I review their gerbers with gerbv. They envy my hierachical schematics and scripting fu, but still, they are happy. All I say is: look if you want help from me with these things, use gEAD, else, do it yourself. In the end, the development caters the needs of whoever is doing the development, and whose contributions get accepted. There is a heap of 45 patches for pcb and 20 patches for geda rotting on launchpad. just what I said see below ... That brings me to another point: I somehow feel a barrier of entry for contributing code to gEDA/PCB, more than with other projects. This is a combination of a lot of little details which have been discussed before. ack. It starts with a developer mailing list that is closed to mortal users but discusses issues which affect said users. The wiki only features edit buttons on application. That are two of those little details, major ones. -- Stephan ___ 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
Geoff Swan shinobi.j...@gmail.com writes: Examples are the next to unusable default library of geda As has been discussed many times, this cannot be fixed, since there is no narrow, common use case for gEDA. It can be fixed, ... Actually I think gEDA is not too bad for components/symbols really. What the default library lacks, gedsymbols often has. With a little bit more promotion of gedasymbols I think people wouldn't have such an issue. The way to promote gedasymbols and to fix the default library is to remove the default library, except for a small set of very generic symbols. I do use some symbols from the defaul library, generic resistors, capacitors, transistors, switches, but nothing else. Basically only the very generic drawings. The first thing a new user shall (have to) learn is making symbols, and (for a pcb workflow) footprints, or (for a simulation workflow) models, because, as John said, it cannot be done right for everybody, so we shall not try, and if it were possible, nobody wants to to the work anyway. -- Stephan ___ 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
John Doty j...@noqsi.com writes: So, is it really that bad? In the end, when you really need to look something up, giyf, it is all there. But terribly disorganised. For most things that may need looking up I am completely unaware that they even exist. As I said eleswhere, the first thing I tend to read is some kind of reference manual. Those things are typically not very verbose and give me a complete overview what the program, API, language, library can do for me. I could not point to such documents for gaf or PCB. I still do not know where the pcb users manual is to be found. I found it several times in the past after some googling, and after I read it, I still have no idea what the possibilities are on the pcb actions command line, because it appears to be incomplete both in coverage of the actions as well as the parameters for the actions. This is not a complaint, since I get along with what I know. I may just miss out on a lot of nice features that I do not know about. What I did find early (and enjoyed a lot) was the file formats documentation. -- Stephan ___ 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
k...@aspodata.se (Karl Hammar) writes: Stephan: ... I still do not know where the pcb users manual is to be found. ... You can find it in the git repo. as pcb/doc/pcb.pdf, but you have to build it first. :-) -- Stephan ___ 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
Kai-Martin Knaak kn...@iqo.uni-hannover.de writes: Russell Shaw wrote: I think Scheme could be made much more attractive in geda if it was adequately explained in documentation or a tutorial. +1 I wouldn't mind to learn (a new language). But to learn a new language by almost non-commented code is just too much of a barrier. Learning a programming language by examples is hazardous. Judging the code by lack of comments without knowledge of the language is too. Comments that help those who do not know the language to understand the code belong in tutorials, but not production code. Well written code should be understandable, with full knowlegde of the semantics of the language, but not necessarily without that knowledge. I do think that most code needs comments, but mostly exactly not the comments that are present in the code. I once learned TeX by reading the source of LaTeX2.09 (before reading the TeXbook). Nowadays I start with the language reference manual, skip the tutorial, and _then_ jump into example code. -- Stephan ___ 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 co...@gibibit.com writes: First, let's be clear that popularity is no indication of usefulness or goodness of something. But, if a product is less widely-chosen, perhaps there is something that can be done to improve the learning curve for new users... Why is there so much discussion here about the needs of potential new users, instead of the needs of current, loving, existing users? Let's make the tools perfect for us (that includes discoverability and documentation improvements), and not cater for not-yet-users. When we love the tools, they will eventually also leran how to love them. See: e.g., I was frustrated with gEDA when I first started using it, and thought KiCAD looked easy to use and cool. But I found that I didn't like the feel of KiCAD (Wxwidgets was probably part of the problem...), and eventually figured out the tricks needed to make the gEDA system work. Now I love gEDA and am really comfortable with it, Q.e.d. but I must say that it's difficult to learn. Perhaps a comprehensive tutorial/manual that explains the usual PCB workflow would help. I know there are lots of ways to use gEDA, but for new users, a basic and sensible standard workflow could be identified. Yes. Well, the results may be essentially the same, but still, the emphasis must be the needs of those how already use the tools, else the delepoment may run into dead ends. In the end, the development caters the needs of whoever is doing the development, and that is how it must be. Those of us (like me) who just argue their needs on this list, but do not write code, can just hope to steer the development a little bit towards their needs. That brings me to another point: I somehow feel a barrier of entry for contributing code to gEDA/PCB, more than with other projects. This is a combination of a lot of little details which have been discussed before. Maybe there is change in the right direction now, but I do not see any. If it were easier, some new users may already have written a tutorial based on their learning experience, or make the existing tutorials easier to find. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: BUG: gaf hierarchy problems with old backup files
I have a collection of similar projects, each of which refer to a common set of hierarchical sub-schematics, which were located in the directory of the first project. I needed to prepare a tarball for one of the other projects, so I cleaned up the mess, and moved the symbols and schematics of the common sub-circuits into the ../lib directory. I added lines to gafrc like this: (component-library ../lib) (component-library .) (source-library ../lib) (source-library .)) Everthing worked fine for the project that I had to tar up. Then I tried to open the project where the common subcircuits were previously stored, and there I could not descend into the sub-schematic with H-d. Worse, gsch2pcb did not find the source= schematics either and deleted all the included components from the layout. It took a while to figure out what was different between the project where everything worked, and there it did not work: There where backup~ and #autosave# files left in the direcory for the .sch file that were moved. After removing the backup~ and #autosave# files of the moved files everything works as expected. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: physics Re: Reinventing the wheel
John Doty j...@noqsi.com writes: Because when the theory is all epicycles and no physics, there's no foundation upon which to stand. Epicycles are no less physics than Keplers Laws. They described the observed ephemerides of planets just fine (for the time). Kepler replaced them by ellipses because he found the math turns out easier that way, but there is no more physics in there than in Ptolemaeus math. It is often the case that the wrong choice of reference frame makes the math more complicated, but not necessarily wrong. Currently we believe that Einstein got the math right, at least as precise as we can measure. Does that make the GRT more physics than Kelpers laws or epicycles? You are right, though, epicycles are no good foundation to go any further, neither is general relativity. Kepler may fit just fine, simple Euklidian geometry in a plane. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: An idea: rework design support...
Peter Clifton pc...@cam.ac.uk writes: FWIW, I'd love to see PCB's enforce one layer per layer of the board, tagging objects if necessary to implement similar functionality to what we currently use layers and layer groups for. One layer per physical layer would imply that element pins (pads) are tagged shapes in this single layer too? And negative shapes as well? So each object (shape) on the layer needs a stacking order tag (implying sublayers), or shall each negative shape take precedence over positive shapes? Mechanical drawing overlays could still sensibly be called layers, even if they are quite distinct from the physical representation of the PCB board. I do not have a problem with the idea of single layer per physical layer, as long as the end result is no more than a separation of the plane in two subsets, all layers can be manipulated othogonally in the same way (at least with a text editor), and there are not too many assumtions about the semantics of the resulting layers. The tags on the objects that define the layers have several distinct purposes: - how does this object affect the plane (positive, negative, positive with clearance, stacking order, ...) - where did this object come from (routing, element pin, ...) - how may this object be modified (locked, grouped, ...) - verification (design rules, ...) - connectivity (vias, antenna, ...) - ... - user attributes Some of these tags exist today, some are requested features, some depend on what gets picked up from the long discussion we had a few months back. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb: Track routing strategies and tips
Colin D Bennett co...@gibibit.com writes: As a rather inexperienced PCB designer, I find that I have to throw away two or three layouts until I get one that is usable--and still not entirely satisfactory. I always end up with such a mess of traces that I know I need better organization and a method to the madness. But I am a newb with little knowledge so I fall back on trial-and-error. Does anyone have any tips on how to plan a layout for easy and clean track routing? In particular for 2-layer boards. My schematics usually look almost like the layout. The pins of the symbols are placed like on the package. People on this list argue that the schematic should document the function, not the physical implementation, but in my circuit the function is all inside the FPGA and the processor, while the details of the layout in low noise mixed signal or high-speed applications are very important, so I use the schematic entry as a first opportunity to preview the place and route. One strategy that I have seen and recently tried is to use the top layer for all horizontal trace runs and the bottom layer for all vertical trace runs, or vice-versa. This is a good for (slow) digital designs. These typically benefit from good functional schematics for review and documentation, so my physical style of schematics is not appropriate. OTOH, when it needs to fit on two layers, and the logic is not too complicated, a little physical planing on the schematic level may help later with the placement and save a few backannotation cycles for swapped pins and slots. Do you ever use the pcb autorouter or do you always route by hand? I never tried an autorouter. But for that kind of Manhattan routing I probably would try. Do you ever study other people's PCB designs to learn from them? I think you could find both good and bad examples: things to emulate and things to avoid yourself. Yes. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Where is pcb-20100929 for Win32 ?
Bob Paddock graceindustr...@gmail.com writes: On Tue, May 10, 2011 at 2:18 AM, DJ Delorie d...@delorie.com wrote: If somebody requires GTK sources - let download them directly from http://gtk.org/ I used GTK etc. libs unmodified. Unfortunately, the GPL does not allow this. If we're shipping GTK dlls, we must offer the GTK sources ourselves. Why are individuals who are trying to help the project being held to a higher standard that the projects own download page? http://pcb.gpleda.org/ 's download link does not contain GTK sources, sources of compilers or sources for the Windows operating system. Neither did I find any libgtk executables, that would require to provide corresponding sources. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Out and In symbols in gschem getting net names to come out in PCB
Kai-Martin Knaak k...@lilalaser.de writes: Colin D Bennett wrote: +1000 for a patch to make I/O pin symbols visually clean without requiring maintaining duplicate attributes as at present. While I am all in favor to get rid of the :1, this is how I currently deal with net names: * For nets that jump inside a sheet I attach an attribute to a short net line stub. I copy/paste this stub to where ever the net should go. * For nets that enter the sheet from a higher level of hierarchy, I use in.sym and out.sym and set the refdes to the desired net name (without a :1 appendix). dito, plus: * For power/ground nets I create a symbol with a label and hidden net= attribute. * For small projects I use the generic power symbol and live with the ugly :1 at the end of the netname, when the standard Vcc, Vdd, Vee, Vss, and GND symbols are not sufficient. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Can i use geda for electric indoor installation?
Jonas Stein n...@jonasstein.de writes: i want to make a scheme like this: http://images.autodesk.com/emea_dach_main_germany/images/2g_acadelec_2012_auto_wire_number_1_large_1264x711.jpg Is geda the right tool for it? Yes, I'd think so. You will need to make a library of symbols. Or is there such a library for gschem already? Has anyone experience with that? Do you have some screenshots of nice schemes of house electric indoor installation? Additional information like wiretype or wire ID would be nice to have next to the line of the wire. Sure, you can attach attributes to wires. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: How to identify a refdes' owner in gSchem
Mark Rages markra...@gmail.com writes: On Fri, Apr 29, 2011 at 3:03 PM, Rob Butts r.but...@gmail.com wrote: Having never looked at a schematic this way I wouldn't know what to look for but from this excerpt can you tell if this is just a stray refdes that doesn't belong? It is the only U9 found. Right, looks like stray text. You can delete the line. How it got there is more interesting. If you can reproduce it, please file a bug on the gschem bug tracker. Typically, by selecting a refdes and hitting 'c'. No bug required. Regards,Mark markrages@gmail -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Attribute Net (without pin assignment) - for Power and Port Symbols
Gabriel Paubert paub...@iram.es writes:
A french or german keyboard will be different (I'm french,
but I can't stand the layout of french keyboards).
I'm using us keyboards exclusively, in Germany. I type a lot more
[]{}\| than äöüß.
I do not think that easy of typing should drive this decision too much.
When we need to type hierachy seprators a lot, then there is a problem
with the UI that needs fixing.
--
Stephan
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Attribute Net (without pin assignment) - for Power and Port Symbols
Peter Clifton pc...@cam.ac.uk writes: On Tue, 2011-04-12 at 22:35 +0200, Krzysztof Kościuszkiewicz wrote: On Mon, Apr 11, 2011 at 11:25:19PM +0100, Peter Clifton wrote: What about the cases where this is a mistake? The net= attribute was supposed to refer to some implicit power pin - not the device's one symbolic pin, but the user forgot the suffix. The special case applies only to symbols with a single pin, so no such error is possible here. What about symbols with one pin, and multiple net= attributes providing hidden pins. A non-graphical netlist format could be a gschem schematic file with a generic symbol without any pins, with just a list of attributes. Instead of special case, we could call it a default. If a net= attribute does not provide a pinnumber, it defaults to 1. Doesn't make is any better, but maybe feel better :-) This default is actually a natural and useful default. I'd welcome it. Whenever I forgot to put a pinnumber on a net= attribute, this default would have fixed the schematic, not hide an error. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: default pcb stackup change?
Peter Clifton pc...@cam.ac.uk writes: On Sun, 2011-04-10 at 19:42 -0400, DJ Delorie wrote: I'm pondering a minor change in pcb's defaults to give us a more useful default stackup. How's this? LAYERNAME (1, top), LAYERNAME (2, ground), LAYERNAME (3, signal2), LAYERNAME (4, signal3), LAYERNAME (5, power), LAYERNAME (6, bottom), LAYERNAME (7, outline), LAYERNAME (8, spare), I'm very keen to see this change. The PCB+GL renderer (for example), needs layers (actually layer group numbers) in the correct physical order to be able to figure out how to render 3D views. Our current default stack is totally useless for that. I'd very much like to not have any exporters/renderers requiring the layers to be in physical order, since I tend to move the final order around a lot. My layer order is defined in the README that goes to the board house, and little text numbers in the layers. A layer attribute that tells Ben-mode and PCB+GL how to render the stack may be the way to go. Is it really the layer order, or the group order that PCB+GL or Ben-mode uses? -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: RFC using SVG with semantic markup as an EDA format
Peter Clifton pc...@cam.ac.uk writes: On Mon, 2011-04-11 at 13:05 +0100, Andrew Seddon wrote: 1. Be translated to common EDA formats with relatively simple algorithms 2. Display nicely on standard SVG viewers 3. Be easily to manipulate by tools working natively in the format (this is probably implicit in 1 though) Keen to hear why this idea sucks! It doesn't. Some challenges to be met though. If you make schematics == SVG files, you need to ensure that opening and saving from an SVG editor (e.g. Inkscape) won't break the data within. Gschem currently uses special primitives to mark connectivity - nets, pins, buses etc.. I'm not quite clear how that can be mapped to SVG in a way which doesn't loose that information when edited outside of the EDA tool. Does SVG/Inkscape support layers? It sure does. I recently looked at an svg export from gerbv, and I found it pretty useless. I found one object inside, and when I ungrouped that object I found all the little pieces, but not grouped into layers. And no transparency. A schematic could require nets and pins to be in special layers. When Inkscape messes with the file, as long as the layers are preseved the connectivity should survive. All non-schematic layers are graphics. So it should be easy to map the semantics of gschem to an svg subset, allow gschem to export to such a format. On open/import, the schematic is extracted from those layers/groups that have a meaning, all the rest is preserved as graphics, maybe with limited edit sorrut, like move and delete. If this shall become the primary format, I'd first insist on really good native scripting support, since external schematics scripting on svg is no fun. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Split ground planes and zero ohm jumpers
DJ Delorie d...@delorie.com writes: Why not a description for what it is, instead of fending off some program. Like square,use=xx, where xx could be fuse, antenna, etc. For starters, flags are one-bit values. Also, if you allow the user to put in a wide range of values, then the routines in pcb need to understand what those wide range of values *means* so they can do the right thing. Exactly. The attributes and flags shall have meaning to the program, without overloading them with higher-level semantics. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Power users us normal users, a conflict?
Rubén Gómez Antolí l...@mucharuina.com writes: Hi again: El 08/04/11 01:30, Peter Clifton escribió: On Thu, 2011-04-07 at 16:00 -0600, John Doty wrote: On Apr 7, 2011, at 3:06 PM, Rubén Gómez Antolí wrote: You are right but, what about the users? I *am* a user. I'm too. Both of you now pushed some users aside somehow, one calling the GUI users _consumers_, the other calling CLI users _power users_. I do not see a conflict between GUI and make, the first ist a good way to make features of the second discoverable. John wants to make sure that the make-power is not compromised for the sake of the integrated GUI. But that should not discourage development in that area. gEDA is software that caters to the needs of users. But it's not for passive *consumers* of software. There are plenty of other tools for them. I sincerely hope that gEDA's power and productivity are never abridged to make it more palatable to consumers. John, I'm not attack the powerful of gEDA, I'm really agree with the multiple pieces of powerful software that compounds it, and I love too the posibilty of use makefiles, but... I tell you a short history: I have a friend, he is really good in electronics and yes, he uses other comercial apps (and he's testing Qucs). I try to come him with us, but, stop, if I tell him to need to learn Bash, Makefiles, Gnuplot and other esotheric languages... ¡oh, wait! He only wants to do some electronics work. He cannot be really good, when we stays in the GUI forever. At least not efficiently. An expert in any field needs to use learn the tools of his trade, or hire personel that does. None of the languages you quoted are esotheric. Users of commercial tools learn more esotheric scripting languages to achieve what open tools can partly achieve with these non-esotheric tools. These non-esotheric tools are useful for all kinds of productivity boost besides eda. Who is wrong? Possibly anyone, then, what about do a easy curve of learning? Why we have to lost a potentially users which should contribute in some way to gEDA? For a leak of a good interface* to do in a easy way the work? I say no. Try to tell him about doing some makefiles and, definitively all lost, we and they. gEDA and especially PCB suffer a lot from lack of discoverability. There a powerful features in PCB that are inaccessible from the GUI, and those features that are accessible do not provide hints how to access them from scripts. And AFAIK there is still no complete list of all actions available. I do not believe that a GUI frontend to gaf, pcb, spice is the way to go. That prevents dicoverability. My productivity with proprietary tools always got a boost as soon as I learned how to call the components individually. This was not always easy to discover. gschem modes, like emacs modes may be a good way forward. If you target simulation, provide a menu that highlights spice attributes, and spice components, with descriptive names. Just make sure you can switch to different modes on the same schematic, to use what is left of multi-target capabilities in gschem. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Split ground planes and zero ohm jumpers
John Griessen j...@ecosensory.com writes: On 04/06/2011 05:16 PM, Russell Dill wrote: The use case I'm talking about, you have two nets, say GND and AGND1 which are two planes that are connected at a single point. Connecting a component on the AGND1 side is different that connecting a component on the GND side. Yes, Levente's way of handling that after the fact is practical and what I like to do, since then you keep all your DRC's working against error, and have one more step to do after DRC complete. Perhaps that method could be scripted with a makefile? Can commands from a script make a layer invisible and not part of DRCs? If so, then the starpoint connecting copper could be on a special layer for that purpose alone, and merged in by using visibility or not. PCB layer groups may be used here. Put the short on an extra layer, in an extra group. At checkout time, you can assign the extra layer to the group representing the copper layer that needs shorting. This is probably a single char in the PCB file header, and can be done with a simple sed script. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Split ground planes and zero ohm jumpers
rickman gnuarm.g...@arius.com writes: I have to say I am philosophically opposed to any feature that allows a design to pass DRC when the layout differs from the schematic. Just to get the terminology right: DRC has no business to care about the schematics at all. There shall be a tool to check if the layout implements the schematics netlist, but that is a different issue. PCB implements this distiction properly. DRC checks consider coper structures as layed out when evaluating the rules, without regard to the netlist. The Rat's-nest (O-key) ignores DRC rules when checking connectivity. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Split ground planes and zero ohm jumpers
John Griessen j...@ecosensory.com writes: On 04/07/2011 04:52 AM, Stephan Boettcher wrote: PCB layer groups may be used here. Put the short on an extra layer, in an extra group. At checkout time, you can assign the extra layer to the group representing the copper layer that needs shorting. This is probably a single char in the PCB file header, and can be done with a simple sed script. I like that idea -- at least until someone figures how to have a starpoint symbol and footprint that keeps DRC checking of separate ground planes while still having a short there for fabbing purposes. I'm thinking of two scripts external to pcb, for use with make. While editing a pcb board, I would run DRC and effectively have a non conductive piece of trace between separately named ground planes. When I run make faboutput, one script is run to change the non conductive piece of trace to copper on a layer, then output RS274-X, the run the other script to change the piece of copper on a layer to a non conductive piece of trace. We don't have the concept of non-conductive built into pcb now though, so some kind of ignore for DRC purposes might do. There's still a problem with that method though... It won't check for proper clearances of the starpoint blob of copper to other copper if it is handled by an ignore for DRC purposes attribute. As soon as we have the option to define arbitary layer types, we also need to be able to define arbitrary DRC rules. The star-point may be a footprint with a structure on some non-conductive shorts layer, which will need to be accompanied by a set of design rules in the technology specs. The fact that the non-conductive shorts layer is implemented in conductive copper by merging the layer with the bottom copper is irrelevant, since for netlist purposes it is non-conductive, just like a resistor layer. Part of the design-rule check is to be perfomed manually, you'll always need to check your footprints in your library. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: zview/ngscope
Kai-Martin Knaak k...@lilalaser.de writes: Specifically, the suite misses a way for fast turnaround of schematic modification, simulation and display. make -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Footprint/symbol generating scripts + question
Richard Rasker ras...@linetec.nl writes: One last question: the project I'm working on has several schematic pages, with several nets spanning multiple pages. For me, this is the first project of this size, and I wondered about one thing: Are there special symbols to indicate nets connected to other schematic pages? In the reference design on which this project is based (probably made in OrCAD), those nets have double arrows, but I can't find anything similar in gschem. So now I have quite a few nets ending in little red squares, giving the impression that they're open-ended. The actual connection is there, of course, so it's more of a cosmetic issue, but I have the feeling that this is not how it's supposed to look. You could draw a bus, and connect the nets to a bus. The bus could be labeled with the sheet the nets connect to. All this is just cosmetics, though. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: US Distributor for Balloon Board
Dave McGuire mcgu...@neurotica.com writes: On 3/27/11 6:05 AM, Stephan Boettcher wrote: I am designing a lot of boards with an LPC2141 ARM7, Altera 3c25, USB client, RS232, SPI, uSD. No ram, no Linux, just the builtin flash and RAM of the ARM and FPGA, and 1MByte SPI flash. The frontend is fitted with a variable number of ADCs of various types. It is optimized for precision analog measurements. The FPGA and the ARM live on differnt ground planes, with LVDS-IO between, to isolate the noisy digital world (computer) from the frontend. This board is sandwiched between a power regulator board and a preamplifier board. The inputs to the preamps are usially quoted in pA or fC, that is just a few electrons. I don't think this is what you asked for, but, if that comes close to what you need, and are ready to do your board yourself, I will share my design to work from. Most work is in the software/firmware. That sounds like a very powerful platform for general metrology applications. I'd love to get my hands on one of those boards. If you decide to publish the info or sell any boards, please let me know! Well, I design a new board for every problem, because each problem requires it's special frontend, like == 18 * AD7276, 3 MSPS, 12bit, each with a shaper AD8005 == 2 * AD9251, 4 channels, 80MSPS, 14 bit, with AD8138 preamps. == 9 * AD7690, 9 channels, 400 kSPS, 18 bit, with AD8131 preamps. == 1 * AD9649, and LVDS IO, to test variuos ASICS. == 0 * ADC, but an SRAM, to test/emulate interfaces with downstream systems. The backend, ARM, FPGA is always the same, as is the ARM firmware, and a good part of the FPGA code. So, no boards, but I may put the design online when I find the time to package it. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: US Distributor for Balloon Board
Patrick Doyle wpds...@gmail.com writes: Hi Folks, I'm looking for a US distributor for a Balloon Board (http://www.balloonboard.org/) or it's equivalent -- perhaps one of you may have designed and sell your own equivalent. Basically, I'm looking for a standalone board with a processor (with it's associated flash SDRAM) and an FPGA. I'm not terribly picky about the FPGA -- any reasonable Xilinx or Altera device should suffice. Does anybody on this list have any recommendations? What do you want to do? I am designing a lot of boards with an LPC2141 ARM7, Altera 3c25, USB client, RS232, SPI, uSD. No ram, no Linux, just the builtin flash and RAM of the ARM and FPGA, and 1MByte SPI flash. The frontend is fitted with a variable number of ADCs of various types. It is optimized for precision analog measurements. The FPGA and the ARM live on differnt ground planes, with LVDS-IO between, to isolate the noisy digital world (computer) from the frontend. This board is sandwiched between a power regulator board and a preamplifier board. The inputs to the preamps are usially quoted in pA or fC, that is just a few electrons. I don't think this is what you asked for, but, if that comes close to what you need, and are ready to do your board yourself, I will share my design to work from. Most work is in the software/firmware. I would prefer to buy from a gEDA supporter, and it will be logistically easier if I can purchase from someplace in the US. I cannot help with that. Thanks for any pointers. --wpd ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user -- Stephan Böttcher FAX: +49-431-85660 Extraterrestrische PhysikTel: +49-431-880-2508 I.f.Exp.u.Angew.Physik mailto:boettc...@physik.uni-kiel.de Leibnizstr. 11, 24118 Kiel, Germany ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB question
Rob Butts r.but...@gmail.com writes: Yes, that's what I meant. I should have thought about it better before I asked. So if I say in the project file 'output-name new-name' It will know to check the new-name.pcb file to see what components are missing and will give me a knew file with the layout data to load into the layout buffer? Not trying to be wise but is classifying a question properly critical here? It helps, to understand the answer :-) I do recommend a vcs (subversion, git) for pcb projects. No need to rename layout files, then. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Problems with a TDSON8 footprint
Rob Butts r.but...@gmail.com writes: I am using an Infineon power mosfet in a voltage converter. I'm attaching the datasheet. Pins 5 thru 8 get tied together and the actual footprint has a big pad that ties them together. I'm attaching the footprint that I made also. I'm having trouble with PCB making the big pad orange when I optimize rats. The big pad lays across each pad for each pin. Your symbol has 5 or 8 pins? The one big pad has what pin number? I'd do a footprint/symbol with 8 pins, connect them on the schematic, and draw poly across the connected pins on the layout. I don't know if the poly clearance can be reduced to zero, of if you need to draw thermals to the poly, or a fat line, depending what you need. How can I do this? Suggestions? Or, since only the big pad that lays across the pads for each pin turns orange, should I just ignore this? Thanks ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user -- Stephan Böttcher FAX: +49-431-85660 Extraterrestrische PhysikTel: +49-431-880-2508 I.f.Exp.u.Angew.Physik mailto:boettc...@physik.uni-kiel.de Leibnizstr. 11, 24118 Kiel, Germany ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
Martin Kupec martin.ku...@kupson.cz writes: Hi all, I appreciate the discussion. So do I. It started out a bit of a mess, because we were talking about different things, but in the end I think there was not left much disagreement about fundamental issues. There we nearly no objections to my layer concept, just to the via/footprint/composite. I have updated the page (http://geda.seul.org/wiki/geda:pcb_layers) and I hope it not reflects the 'opinion of majority'. I will now have a look at that. But what do you call majority? The most vocal people here, like John and myself did not offer to do any coding, yet. In the end, those that code (DJ, you ?) decide. I appreciate that you asked for out opinion! So again. Coments are welcome, the discussion was a bit fast so I may have missed something important again. I think it is worth to read the whole thing once again. I will send myself a digest message of the whole thread so that it is easier to read, and I may try to identify the core arguments. Thank you all for participating, Thank you! -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
Stephan Boettcher boettc...@physik.uni-kiel.de writes: Now consider a differential pair. It's a line but you *don't* move the *line* endpoints, you move the *pair* control points. That is a hard one. You could define a composit of type morphable The endpoints of shapes inside such a composite become pointable/selectable, and a plugin can register callbacks to be called when such an endpoint is manipulated. The plugin would check to see if a diffpair attribute is set, and decline the callback if not, so that the magic_poly plugin has a chance. The morphable composits can also support lines with soldermask opening and paste. Maybe we call the wires. These composits allow to manipulate endpoints of contained objects, where a plugin makes sure that the stack of features representing the wires move together. -- Stephan Böttcher FAX: +49-431-85660 Extraterrestrische PhysikTel: +49-431-880-2508 I.f.Exp.u.Angew.Physik mailto:boettc...@physik.uni-kiel.de Leibnizstr. 11, 24118 Kiel, Germany ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
Martin Kupec martin.ku...@kupson.cz writes: On Fri, Mar 18, 2011 at 09:00:04PM +0100, Stephan Boettcher wrote: Martin Kupec martin.ku...@kupson.cz writes: That is a bit complicated. I need a clean definition of layer types, so one can pick the right layer when needed. But some attributes in addition to layer type are possible. I do not understand that argument. Ok. We probably don't understand each other, so I will just state my fears. I would like to know about each drawing layer where it belongs to. If layers types would be defined by attributes, someone would be able to declare one layer both as conductive and as silk for example. That could cause me a nighmares. That is why I insist on 'typed' layers, not 'tagged' layer. Hmm. I think that is the old trap of overloading. When you say that a layer type defines what you can do with it, then this one type attribute becomes messily overloaded. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
John Doty j...@noqsi.com writes: On Mar 19, 2011, at 4:57 AM, Markus Hitter wrote: BTW., there were electronic circuitries before PCBs were invented and the future of electronics manufacturing is most likely something three-dimensional, arbitrarily shaped. Yes. I'm now working with two groups that are fabricating parts with 3-D printers. I've been wondering when the technology will reach the point where the printing could include conductors, with components placed during the build-up, and then buried. But I suppose describing this is beyond what we can conceptualize here at this time. Planes are difficult enough. As long as this 3D structure is built mainy manhattan style, with horizontal conductive layers and vias, all conductive layers become component layers, an element must define keepout zones on those layers that it's housing penetrates. It's pads are on layers that correspond to the z-positions of it's pins. Before you start making your footprint library you need to decide on the thickness and distance between the conductive layers. The kind of tool we were discussion here could do that very nicely. A GUI plugin needs to be written, that allows to move the 3delements up and down in the layer stack. Maybe even rotate off plane, but that is initially best done by hand as a separate 3dfootprint. One more argument to implement holes as shapes on a hole layers. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
DJ Delorie d...@delorie.com writes: The 'countryard' layer should be exactly the keepout layer. They're two different purposes, though. The courtyard is for physical placement restrictions, the keepout is for copper routing restrictions. The file format need not know about these distictions. Both are graphical layers, with different attributes. The one has attributes to tell DRC to flag overlapping components, the other has attributes to tell some autorouter not to put copper there, and attributes to tell DRC to check for intruding copper. Future plugins need more layers to tell about different constraints. Ideally, any layer type is fully defined via attributes. The most common attribute may be net:conductive for normal copper layers, so that the HIDs know that the layer contributes to the implementation of the netlist. Copper layers need a second attribute gbr:layer=inner5 to tell the (gerber) exporter where to put it. A third attribute defines the DRC rules that apply drc:rules=default, plus per layer override drc:minwidth=6mil. drc:courtyard=front drc:keepout=front route:keepout=front -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
Martin Kupec martin.ku...@kupson.cz writes: On Fri, Mar 18, 2011 at 07:18:52PM +0100, Stephan Boettcher wrote: The file format need not know about these distictions. Both are graphical layers, with different attributes. The one has attributes to tell DRC to flag overlapping components, the other has attributes to tell some autorouter not to put copper there, and attributes to tell DRC to check for intruding copper. Future plugins need more layers to tell about different constraints. Ideally, any layer type is fully defined via attributes. The most common attribute may be net:conductive for normal copper layers, so that the HIDs know that the layer contributes to the implementation of the netlist. Copper layers need a second attribute gbr:layer=inner5 to tell the (gerber) exporter where to put it. A third attribute defines the DRC rules that apply drc:rules=default, plus per layer override drc:minwidth=6mil. drc:courtyard=front drc:keepout=front route:keepout=front That is a bit complicated. I need a clean definition of layer types, so one can pick the right layer when needed. But some attributes in addition to layer type are possible. I do not understand that argument. Each element has a clearance attribute, so definition of extra space around pads should be easy. But we can add 'keepout' layer in addition. Even when we would have more layer, it should be simplier to implement them than some arbitrary flags. Defining DRC rules per layer is a bit different story and I hope it will not be too closely related to changing of layer concept, as I don't want to touch DRC. Martin Kupec ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
DJ Delorie d...@delorie.com writes: Why single out via and footprint when they are merely members of an open-ended list of possible composite objects? Because a tool that doesn't deal with real-world concepts in a user-friendly way is unusable. Yes. The real world concepts must exist, in a higher level. In the attributes. The HIDs must implement them in a user-friendly way. At the lowest level, there shall be abstractions. The GUI must present footprints, vias, and hierachical sublayouts, both in copy on write and in truly hierachical fashion. But at the core, they work all just the same. Then there will be no more question if some feature is supported in elements or not, or how convoluted a via may be. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
Martin Kupec martin.ku...@kupson.cz writes: On Fri, Mar 18, 2011 at 01:44:35PM -0600, John Doty wrote: Trying to model things that aren't layers as if they were layers is one common mistake in this kind of tool. Equally common is leaving out layers: the insulating layers in a PCB are just as important as the copper, and have their own properties (shape, thickness, material, etc.). They're a critical part of the layer stack. The description language needs to be able to express feature p in layer x is aligned with feature q in layer y in order to build up composites. This is the geometrically sensible way to describe the result of drilling through several layers. But the geometric description language should not be tied to any particular fabrication procedure. This is all too physikal for my taste. I assert that if you do it any other way, you wind up with the following catastrophe: the code for every layer type needs to incorporate a specific definition of its interaction with the code for every other layer type. A total collapse of factoring, poisoning flexibility and maintainability. But if layers correspond to actual geometric layers, this can be avoided, I believe. What I like with PCB is that there is very little interaction. Only when special actions are called, the interactions are invoked. E.g., when I hit the O key, the connectivity is evaluated. For that I only need to know which layers are conductive and what vias connect which layers. Actually what I am trying to do, is to have concept so layers don't interract with layers of different type. The composits are a bit problem, because I would need to consider more layers when performing any action, but I think that it can still be interaction with object on the same layer. I do not understand what problems you see with composits. A layer consists of the union of all shapes on any level of the composits hierarchy. Composits may be referenced at multiple positions, so those shapes appear multiple times. When a shape is modified in a composit, it may affect all copies simultaniously, or the composit will be duplicated (copy on write), depneding on an attribute or explicit user action. So, i.e., If we would have 'hole' layer. I would have check, that holes on hole layer are not intersecting. And also check the intersection of attached shapes on each layer. But all what can happen is that some layer will yell that something bad happend and I should cancel my action. Where do you want to attach holes. To layers, like John proposes? To shapes on a layer? Or as independent entities, like they are now? -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
Martin Kupec martin.ku...@kupson.cz writes: On Fri, Mar 18, 2011 at 01:52:24PM -0600, John Doty wrote: On Mar 18, 2011, at 1:44 PM, Martin Kupec wrote: Generaly you are proposing that there should be a special type of footpring called 'via' and it should receive extra care. Why single out via and footprint when they are merely members of an open-ended list of possible composite objects? We need to single out 'via' so someone who want's simple board can find 'via' tool as everywhere. And under word 'footprint' I mean any other composite object. That is up to the HID to find the composits with attribute type=via, and present them in a via toll selector. And to maintein an in memory list of composits of type=element and akt on those when the users asks for elements. I am ok with that, I just need to figure out how to handle mapping from footprint layers to layout layers. I don't want concept of 'top', 'inner', 'bottom' layer at all...that is too naive for me. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
Steven Michalske smichal...@gmail.com writes: On Fri, Mar 18, 2011 at 12:40 PM, Martin Kupec martin.ku...@kupson.cz wrote: On Wed, Mar 16, 2011 at 10:36:24AM -0600, John Doty wrote: On Mar 16, 2011, at 4:24 AM, Stephan Boettcher wrote: Ok. So via should be a circle element on hole typed layer. No. A Via is a composit, consisting of a circle on the hole layer, and various circles on copper layers, and circles on mask layes, and thermals. The layer concept should be physical, not a metaphysical abstraction. Objects in a layer may contain holes, but a hole layer is nonsensical, a toxic conceptual shortcut. An outline layer is similarly bad: the insulating layers may all have the same shape sometimes, but not always. The outline layer will be part of 'physical' layer. So if you have 2 'physical' layers with different shape, it will play nicely. What I am prosposing is 2 level concept. There will be 'physical' layers, so you can add properties to them. And than there will be 'drawing' surfaces. And 'outline' is just drawing suface telling the 'physical' layer it's edges. But I am not convinced that we need special 'hole' typed layer. Maybe we can things like 'holes' which are not part of any specific layer just float in space. I thing that it would work. Trying to model things that aren't layers as if they were layers is one common mistake in this kind of tool. Equally common is leaving out layers: the insulating layers in a PCB are just as important as the copper, and have their own properties (shape, thickness, material, etc.). They're a critical part of the layer stack. The problem I see with the insulating layers is that there is nothing on them...So you don't need them as 'drawing' layers. But I agree that there should be a way how to add some attributes to them. Embedded resistor and capacitors are in holes in the separating layers. Some separating layers are more like a solder mask and sprayed down rather than FR4 and prepreg. Just because standard FR4 Fabs don't usually use any drawings on that layer, should not preclude it. Now the exporter may barf if it finds something it can't cope with, like a line drawn on a separator layer. If you have a foundry that does such things, probably you send them a gerber layer and tell them that those are the embedded resistors between copper 2 and 3. And that other layer are those between copper 5 and 6. No special exporter required. But you must keep the drawing layers a bit more abstract, else you confuse the tools that have invalid assumptions. The embedded resitors will be elements in a process specific library. Not top/inner/bottom layers, that get mapped to the layer present in the layout, but footprints with explicit layers. Including a shape on the resistive layer, and pads on the adjacent copper layers. The pcb layout tool will not need to know anything about those embedded devices. They just emerge and work. All you need is layers that are not marked conductive. And if those strange embedded deviced become common, somebody needs to add some DRC rules, which at that time are just a few boolean ops on some layers in a config file. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
Martin Kupec martin.ku...@kupson.cz writes: On Fri, Mar 18, 2011 at 09:00:04PM +0100, Stephan Boettcher wrote: Martin Kupec martin.ku...@kupson.cz writes: On Fri, Mar 18, 2011 at 07:18:52PM +0100, Stephan Boettcher wrote: The file format need not know about these distictions. Both are graphical layers, with different attributes. The one has attributes to tell DRC to flag overlapping components, the other has attributes to tell some autorouter not to put copper there, and attributes to tell DRC to check for intruding copper. Future plugins need more layers to tell about different constraints. Ideally, any layer type is fully defined via attributes. The most common attribute may be net:conductive for normal copper layers, so that the HIDs know that the layer contributes to the implementation of the netlist. Copper layers need a second attribute gbr:layer=inner5 to tell the (gerber) exporter where to put it. A third attribute defines the DRC rules that apply drc:rules=default, plus per layer override drc:minwidth=6mil. drc:courtyard=front drc:keepout=front route:keepout=front That is a bit complicated. I need a clean definition of layer types, so one can pick the right layer when needed. But some attributes in addition to layer type are possible. I do not understand that argument. Ok. We probably don't understand each other, so I will just state my fears. I would like to know about each drawing layer where it belongs to. So when I am performing DRC check, I will know, that it is conductive layer and I should consider it. I can take care of special DRC rules for some conductive layers later. So we do need layer specific DRC rules. Silk layers get the silk rules attached. Copper layers get copper rules attached. If layers types would be defined by attributes, someone would be able to declare one layer both as conductive and as silk for example. That could cause me a nighmares. Well, that would be a DRC violation :-) The DRC tool shall not suffer from nightmares if it finds positives. That is why I insist on 'typed' layers, not 'tagged' layer. As long as the user can define arbitrary types, the type becomes an attribute. If the user cannot define new types, then there shall be only very few very abstract types, connected to basic properies, e.g., conductive, hole/via, other. That example is probably silly, but someone would probably come up with something more realistic, but still giving me nightmares. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
Jared Casper jaredcas...@gmail.com writes: On Fri, Mar 18, 2011 at 1:23 PM, Martin Kupec martin.ku...@kupson.cz wrote: If layers types would be defined by attributes, someone would be able to declare one layer both as conductive and as silk for example. That could cause me a nighmares. That is why I insist on 'typed' layers, not 'tagged' layer. That example is probably silly, but someone would probably come up with something more realistic, but still giving me nightmares. But what if I want a silk layer to just be a copy of a copper layer? That may be just as silly, but I'm sure someone could come up with a use for it. Why would such a layer cause nightmares? When the code is worried about connectivity etc., it sees this layer is tagged as conductive and includes it in whatever its doing, ignoring the fact that it is also silk. When the code is putting out the silkscreen, it notices this layer is tagged as silk and puts it out, ignoring that it is also a conductive layer. You can always tell the board house to use copper minus soldermask as silk. Jared -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
DJ Delorie d...@delorie.com writes: Inflexible wired-in behavior ... is MANDATORY if you're going to produce a tool that's usable. That's the difference between a pcb editor and, say, inkscape. Inkscape gives you complete flexibility, and it's absolutely useless as a pcb layout tool. You seem to be totally blind to the theory that you can have inflexible wired-in behavior *and* options for flexibility through alternate mechanisms. We need both - they are not mutually exclusive. We need a tool that's easy to learn and use *and* has options for power user. Your maniacal lobbying for factoring and abstraction would leave us with a tool that nobody would *want* to use. We are talking about different thinks, I guess. The tool shall be very focussed on traces, elements, vias. But the engine at the bottom shall be flexible. The user shall see this flexibility deep down in the advanded options section of the via editor, where he will be told to go when he asks for square via holes in this mailing list. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
DJ Delorie d...@delorie.com writes: But at the core, they work all just the same. The core includes the autorouters, optimizers, DRC, exporters, reports, and even simple editing - we have a hide vias button. How does that work if you no longer have vias as an inherent type? Hide all composites with attribute type=via. The GUI probably maintains an extra list of those, as well as a list of elements, for performance. The autorouter is told to route on all enable conductive layers, and choose from a set of selected vias to go between those layers. Exporters can only export what they know about. All layers can be turned into gerbers. More complicated exports may need a technology description, like an advanced concept of the current layer groups. An exporter shall define a set of attibutes it expects to find on layers and objects to do its special deeds, and those attribute shall not be overloaded attributes that the core tool needs. PCB has a lot of tools that know a lot about how PCBs are designed. These tools are essential to making PCB a viable layout editor. The input we need at this stage is from people who design a lot of PCBs, so we know what kinds of abstractions make sense to expose and what kinds need to be hidden behind other data structures. At the bottom, a layout is a set of layers with attributes, containing shapes, maybe with attributes. The semantics of those attributes is what encapsulates the builtin knowledge how to make PCBs, and the tool must fully exploit that knowledge when presenting a layout to the user. When we morph the current pcb towards such an abstract layer concept, the user shall not see the difference unless she activates the new features that become available with these concepts. Maybe to the rendering engines they all work the same, but saying they all work the same *in general* just isn't applicable here. They don't. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
DJ Delorie d...@delorie.com writes: That is up to the HID to find the composits with attribute type=via, and present them in a via toll selector. I disagree with this. The HID is the Human Interaction Device - how the information is presented to the user. GUI, printer, etc. The HID is the wrong place to be assigning *meaning* to the data. That is still in the core. The fact that some composites are vias is something intrinsic to the pcb design, independent of what color you make it on the screen, and independend of how vias are implemented at the lowest internal levels. Physical meaning is here is a hole in the board, here is a copper circle on layer 1. Those meanings appear in elements, vias, whatever. That a hole with concentric pads is a via has no meaning except for how those came to be. DRC does not care about vias. It cares about hole diameters and copper annulus. Connectivity also does not care about vias. Only the human in front of the screen cares about vias. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
DJ Delorie d...@delorie.com writes: We are talking about different thinks, I guess. Probably. The tool shall be very focussed on traces, elements, vias. To be this kind of focused, it needs to have some understanding of what a via is. You wouldn't want to invoke the via editor on a trace, but you wouldn't want the move option on a trace to not be able to move either the endpoints or the whole trace. Regardless of how the underlying data is stored, the tools need to organize the data in a way that helps them serve the user, and be aware of various levels of semantics that need to be applied to what would otherwise be meaningless groups of composites. For example: User level - a via is a connection between layers that I can add, remove, edit, and move around. Tool level - a via is an anonymous (i.e. not part of an element) hole between layers electrically connecting copper pads on each layer. Data layer - a via is a collection of N shapes on M conducting layers, with a collection of one or more shapes penetrating the insulators between those layers. Except, I see no need to specify any insulating layers here. The data does not care. It's the exporter that may care. If, for some technology, the data does care, there will be a very special layer of type other to make it care. I feel that the data layer is easiest to implement, but it seems to be what we're arguing about the most. Yes. because ... I say we should ignore that problem for now, until we have a better understanding of what we want at the other two layers. The tool layer is going to be the hardest to design, ... I think the tool we have is pretty good already. Very good. Thanks! because that's where we blend flexibility with ease of use. Picking the right tool-level design will give us both flexibility and ease of use (use includes both the user and the plugin writer). Please do not expect that users write plugins. The tool is already too good as it is to make is worth the effort to learn how to do that. It's good to know that is is possible when a real need arises, but that will not be often the case. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
Martin Kupec martin.ku...@kupson.cz writes: On Fri, Mar 18, 2011 at 05:11:01PM -0400, DJ Delorie wrote: But if I am doing that (just to extend this silly example too far), I would want the DRC checker to ensure that it obeys both the rules for copper _and_ for silk. Hmmm... DRC is already fab-specific anyway. Maybe DRC should be on the other side of the CAM job? I.e. make DRC an exporter, so it gets the layer mappings you want, and can apply rules based on the *mapped* layers, not the *design* layers? That also lets us code the DRC rules in the CAM job file, so different jobs check different rule sets. I am sorry, but I don't think this is a good idea. The DRC should work on the hierarchy. While the exporters will receive somewhat 'flattened' stackup. Absolutely not. The DRC shall check the final flat result. And yes, the DRC should be a separate tool examining the CAM output. OTOH, some DRC functionality inside the layout tool is at least nice to have, if not required, for doing life checks when editing. These will probably never reach the coverage that a final checkout DRC should provide. But that is a problem to write such a tool in the first place. And I want represent the resulting layer mapping somewhat in the stackup, so the exporters will receive how are the layer ordered. This should brink some code from the exporters to the core = less code. This kind of information shall be in the layer attributes. Ben-mode image export will need to know that. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
DJ Delorie d...@delorie.com writes: I don't want to end up with the current state that some 'specialy named' layers receive special treatment. From a practical standpoint, I think it makes sense to have a fast way to scan for layers of some high-level type, as well as further typing them by name. I do not agree with the term high level here. I agree that there may be layers of different types, that require special treatment. These are low-level types, like conductive for layers that electrically connect things, or holes for connections between layers, and other for anything else. What kind of high-performance processing is needed in addition to that? Well, when you figure out that there is something else, it's a good justification to add anothe type. At the storage data level they are still all layers with attributes. When loading the layout, they are collected into separate lists, or get a binary attribute attached, by enumerating known values of the attribute pcb:type= My original design had an enumerated type for each drawing layer, that was one of (for example) copper, silk, soldermask, paste, outline, other with flags for normal, inverted and an assignment to a physical layer (1..N). That way, when you're doing something compute-intensive like connectivity checks for auto-enforce drc clearance you aren't doing a bazillion string compares. Actions that are performed less often, like mapping a footprint to an element, can use a more open-ended string-attribute with more complex rules. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
DJ Delorie d...@delorie.com writes: ... I think the tool we have is pretty good already. Very good. Thanks! The tool we have already is nearly impossible to maintain, though. Please do not expect that users write plugins. The tool is already too good as it is to make is worth the effort to learn how to do that. I expect the plugin mechanism to be the way to write *all* the core bits, though. The more important it is, that what is below the plugin mechanism is as general as necessary, and since that is difficult to judge up front: as general as possible, without compromising the final goals. I'd propose a very basic, very general storage data representation. Just layers, shapes, and arbitray levels of composites, the layout implicitly being the top level composit. Everything with arbitrary attributes. On top of that is a memory representation, that introduces the concepts of elements, vias, surface-layers (layer sets: copper, mask, silk, courtyard, keepout), connectivity, It provides basic operations on these concepts. The implementation of these concepts builds on the objects of the storage data layers. It must not be an error if a via has two holes, a polygon shaped hole or silk in it. DRC may flag such things, but it must not be an error. The attributes that this memory representation and it methods understand shall be in namespace pcb: and unknown attributes in that namespace shall emit warnings. The plugins define their own attributes. Attributes shall not be overloaded. If a plugin operates on attributes of the memory representation, it shall do that via methods of that representation, if possible. Higher level parts of the concepts element, via, surface layer may be implemented in plugins. I cannot keep up, there are 15 new messages in my inbox, lets see what what new arguments come up :-) I cannot make up my mind if I should continue to argue for hole layers, or if holes shall be shapes with hole attribute on layers. The fact that the *user* can write them *also* is a side-effect :-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user -- Stephan Böttcher FAX: +49-431-85660 Extraterrestrische PhysikTel: +49-431-880-2508 I.f.Exp.u.Angew.Physik mailto:boettc...@physik.uni-kiel.de Leibnizstr. 11, 24118 Kiel, Germany ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
DJ Delorie d...@delorie.com writes: Hide all composites with attribute type=via. The GUI probably maintains an extra list of those, as well as a list of elements, for performance. Why the GUI? Why can't the core maintain that list, since a lot of things will need it? I care a lot about performance. Sorry, yes, that's what I meant. But it's not in the disk file. Exporters can only export what they know about. All layers can be turned into gerbers. Except gerbers have special cases for thermals and pads, for example. If you use the special cases, other CAM tools empower their users to do more things (like auto-generate paste stencils when you forget the paste mask, which does NOT work with pcb's gerbers). But for the exporters to offer these special cases, they need to know more about the data they're given than just draw circle here. So there need to be attributes on shapes. At the bottom, a layout is a set of layers with attributes, containing shapes, maybe with attributes. and containing other layers as sub-layouts. I have never disagreed with this! Oh. My understanding of composites is different. I assume a composite contains shapes that go on a global set of layers. What I disagree with is using this at the bottom information to re-produce the semantic information inherent in a pcb layout. I see no reason why there can't be a semantic heierarchy to the data, so at a high level we have a collection of all vias that's a child of this layout, so that the tools can find them easier and deal with them as a group. Well, yes, it can, except that a via is not sufficiently special to justify the distiction. What would we have in a composite, the layout being the top-level composite? Vias Elements Composits that are not Vias or Elements Lines Shapes outside of composits that are not Lines How the layers fit in here depends if they are global or local to a composit. I did not think about non-global layers yet. The set of global layers is the union of layers referenced in the hierachy of composits. When an how to map generic element layers to layout layers is another good question. And how to treat conflicting attributes of layers. I'd flag those as errors. Or define for each attribute lookup if the precedence goes from outside to inside, or from inside to outside starting at some shape. Global layers can be mapped at load time. Local layers inside composits must be mapped a runtime, don't they? The semantics of those attributes is what encapsulates the builtin knowledge how to make PCBs, and the tool must fully exploit that knowledge when presenting a layout to the user. Forcing tools to fully exploit data at too low a level makes it very difficult to create such tools in the first place. The move tool needs to know the difference between an element, a via, and a trace, so it can function properly. We need to consider these types of issues when designing the internal data structures, or it will be so difficult to write the software that it just won't get done. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
DJ Delorie d...@delorie.com writes: As someone proposed, it is possible to have different hole size on different layers. So I think the best would be to have special 'hole' object on each layer. And that object will always be in composite container, and all of them will be forcebly aligned to the same center. What I suggested before is that each composite itself have outline type layers, which contains any holes, cutouts, or physical outline shapes that need to be applied to all of the layers therein. composit instance overlap with other composits and shapes. I do not like the concept of composit outlines. Does each layer have its outline? How does it do partial vias? -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
John Doty j...@noqsi.com writes: On Mar 18, 2011, at 3:31 PM, Stephan Boettcher wrote: Except, I see no need to specify any insulating layers here. I see no need is exactly the kind of thinking that produces an inflexible, limited tool. I see *every* need to base the description on geometry, so that the tool's limits are defined by necessity and not by the limited imagination of any particular group of developers. Nothing prevents that you define insulator layers, and include shapes on these layers in your vias and elements. But for simple layout work its not needed. I did not miss them, yet. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
DJ Delorie d...@delorie.com writes: I expect the plugin mechanism to be the way to write *all* the core bits, though. The more important it is, that what is below the plugin mechanism is as general as necessary, and since that is difficult to judge up front: as general as possible, without compromising the final goals. As general as neccessary, but not as general as *possible*. But we cannot know what is necessary. On top of that is a memory representation, that introduces the concepts of elements, vias, surface-layers (layer sets: copper, mask, silk, courtyard, keepout), connectivity, This is the part I wish we were discussing. As John said, bottom up works better in the long term :-) It provides basic operations on these concepts. The implementation of these concepts builds on the objects of the storage data layers. It must not be an error if a via has two holes, a polygon shaped hole or silk in it. DRC may flag such things, but it must not be an error. There must be *some* limits, however, or the tools cannot be written. Defining a hole in a silk layer is nonsensical, if you wish to support it, we cannot define what the tools would do with it. Why not? The tool can move it arount and not much else, like with all objects on a sliklayer. But that's why I argue for hole layers. A hole is a shape on a hole layer. The layers attributes define what needs to be drilled. Actually, they only define to which layers they electrically conduct. That is all the tools needs to know until checkout. DRC checks if all shapes are circles, unless the shape has a DRC overide attribute. There would be one hole layer for each drill pattern, i.e., one, unless there are partial vias. John's insulating layers will be mentioned in the attributes, so they get drilled too. A via with variable hole size for different layers must be built as a composit with multiple holes on as many hole layers. Inefficient but appropriate for such an obscure case. The attributes that this memory representation and it methods understand shall be in namespace pcb: and unknown attributes in that namespace shall emit warnings. You assume that attributes are the way to organize groups of things. Why? So that everything is just shapes on layers. Very simple, very powerful. Higher level parts of the concepts element, via, surface layer may be implemented in plugins. How does a move tool plugin interact with an element plugin, then? The memory core representation provides methods to move, rotate, mirror shapes and composits. (Element composits may have an attribute that forbids mirroring.) To bring an element to the other side od the board is method of the Element plugin, relying on attributes of the relevant layers how they map to the other side. I don't think that the concept of vias and elements shall be fully implemented in plugins, for efficiency, and since most other plugings may need refer to these concepts. At least some callback hooks need to be specific to elements or vias, that a plugin can register. So that a plugin can intercept composite methods (e.g., move) for elements or vias. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
DJ Delorie d...@delorie.com writes: I do not like the concept of composit outlines. Does each layer have its outline? How does it do partial vias? In the case of flex cables, each layer *does* have its own outline. The tool needs to know that vias go only across layers that actually exist at that spot. I am the one who did flex cables with pcb, with six copper layes, three different outlines, four surface layers. It is going to fly to Mars later this year. http://www.ieap.uni-kiel.de/et/people/stephan/msl/eda/TFlex/TFlex.pdf http://www.ieap.uni-kiel.de/et/msl/pictures/photos/rsh/FM/TFlex/index.html To support such a beast in PCB you need multiple pairs of surface layers. Elements with pads on explicit layers is what fills this role, so that the pads of the flex edge connectors get connected to their (inner) copper layers. The outlines are just any graphical layers that can be exported without vias and pins. But the boardhouse had no problems ignoring the holes in the outline layers. Still, I do not see a need for outline layers anywhere, except as an attribute on a graphical layer that tells an exporter where to stop drawing. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
DJ Delorie d...@delorie.com writes: Except gerbers have special cases for thermals and pads, for example. So there need to be attributes on shapes. No, the exporters really need to have access to the whole collection of shapes that means pin so they can do pin-specific things. If the exporter doesn't need that high-level access, then the default action breaks it down into shapes and exports them individually. The gerber exporter needs to be given a whole pin because it has a command that means put pin here, with this aperture and thermal settings. If you wait until the core descends to circle, arc, line, it's too late to look at the attributes and figure out what's happening. CAM tools know about this, and can adjust thermals and pins as needed, but in PCB's case they can't do it because we break pins down into raw shapes. I do not understand this. The gerber exporter exports each layer separately, no? On some layer it finds a circle with a thermal attribute surounded by a polygon. What else does in need? and containing other layers as sub-layouts. I have never disagreed with this! Oh. My understanding of composites is different. I assume a composite contains shapes that go on a global set of layers. This is part of the communication problem we're having, yes ;-) Consider these: * A footprint is a global resource, but an instance of a footprint (an element) must be mapped to the physical layout. When do you manage the footprint as an element (indivisible) and when do you access its parts (changing pad size)? Is the footprint still part of the layout? Wouldn't it's genereic layers (top,inner,bottom) be mapped to the layout layers (oben,innen1,innen2,unten) when imported? * A sub-circuit that's replicated N times on a board. composites instances are objects inside other composites, next to shapes. You can do most operations to composites, that you do to shapes (move, rotate, mirror, delete, ...). Vias and elements are special in the memory representation, as there are methods, or callback hooks that allow access to some internals without explicitly decending into the composit. It should be possible to flag any composit as Element or vise versa, to turn on and off this special access. If you exlicitly decend into an element, you can move its pins and pads. But pads size, text positions e.t.c. are still directly accessible for elements. Maybe it is not even necessary to have any special treatment and treat all composites the same. * A flex cable that has 4 layers at each end, but only 2 layers in the middle. The extra layers on the end are on opposite sides of the cable. You want to describe the rigid ends as outlines of a composite? That attaches high-level semantics to a low level concept in an inapropriate way. Here you need outline layers with attributes that tell the autorouters not to cross the lines on certain layers. * buried vias are limited to certain pairs of layers because of the way the fab is assembling the board. A DRC problem. With hole layers, the GUI tool to add/manipulate these hole layers can provide a view on the layer stack that represents the stacking and drilling order, just like you once proposed as an underlying data structure. The tool would refuse to configure holes layers that cannot be drilled, unless you say please. * 400 instances of a standard via, but the user needs to modify the pad stack on just one of them, and only for one layer. Vias may be COW by default, like they are now. But you can decend in non-copy mode into the composite, so they all change. That composit is also the master copy in the Via menu, so that future vias of that type are affected by the edit. When you edit the via definition in the Via menu, you may need to answer a question if you want all existing instances to change, of only new vias. These are all examples of a need for both a semantic and data heirarchy, where parts of your design are grouped together and treated as a single object, sometimes replicated, sometimes customized. What we call them is not important. Well, yes, it can, except that a via is not sufficiently special to justify the distiction. What would we have in a composite, the layout being the top-level composite? Vias Elements Composits that are not Vias or Elements Lines Shapes outside of composits that are not Lines Consider: you can move a via, but for lines, you can move either the line or its endpoints. For a polygon you can move its corners. Ah, but a via can include polygons and lines - but when it's a via, you *don't* move their endpoints and corners, unless you specifically edit the via. A pin is just like a via, except you *don't* move it - you move the element it's in. shapes (lines and polys) in the current composite can be editied as before, moved, endpoints moved, size, pcb:endcap attributes changed ... Some internals of composites may be
Re: gEDA-user: General Layers questions
DJ Delorie d...@delorie.com writes: Still, I do not see a need for outline layers anywhere, except as an attribute on a graphical layer that tells an exporter where to stop drawing. Hmmm... so you think PCB should let the user place an element in a physically impossible location, because it doesn't care about the outlines? currently it does, and I need that functionality. When I import a new batch of components from gsch2pcb, they get disperses in a big area outside the outline, because inside there is half the layout already done. In the end, it's a DRC problem, so yes, the DRC may look for a layer with an outline attributes. That layer shall have a separate attribute for the placement wizard plugin, although the message is almost the same. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
Martin Kupec martin.ku...@kupson.cz writes: On Wed, Mar 16, 2011 at 02:42:26AM +0100, Stephan Boettcher wrote: IMHO, .. holes are circles draw on just another layer. People were asking for slots. If they find a vendor to do them, they may just draw lines on that layer as well. Else, DRC shall flag non-circles. Each such hole layer shall have a spec (attribute) to which (copper) layers they electrically connect. There will be at least one such layer for each type of blind, burried, and through via. The GUI will happily stack vias according to the selected routing style into a composites and paste them on the layout, so for simple cases nothing changes from how we work now. Ok. So via should be a circle element on hole typed layer. No. A Via is a composit, consisting of a circle on the hole layer, and various circles on copper layers, and circles on mask layes, and thermals. A library (routing style) Via would have top, inner, (outer?), bottom copper layers, which would be mapped to physical copper layers of the layout according to some mapping, exactly as for footprints. In addition, some projects would have their own sets of Vias in a library, where those circles are expressed explicitly for the physical hole/coper layers of that board, for burried and blind vias, or special annular ring config on certain inner layers. That library shall be linked to some Via GUI to efficiently choose from. That object will have some description to which layers of type cooper it belongs to. The hole _layer_ should have that description. The default connects to all copper. Blind and burried vias require extra hole type layers, one for each set of drill stacks. This information is needed for connectivity checks mostly. Some DRC check may verify if the drilling of the stacks is feasible. I think this is simpler and more flexible that DJs proposal: to hierachically group (copper) layers into drill stacks. That would be a John D violation, since it originates from a narrow view on how PCBs are manufactured. It in no problem to reflect such a narrow view in a DRC rule, but it is a mistake to cast it into the core data structure. A HID may present the layers in such an arangement to the user. Said HID may then proceed to add the required hole layers and Via types automatically, after the user pushed the copper layers around as required for the project. And how would you describe the cooper around via on each layer? Someone wanted different cooper size/shape on different layers. Martin Kupec -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
John Doty j...@noqsi.com writes: On Mar 16, 2011, at 4:24 AM, Stephan Boettcher wrote: Ok. So via should be a circle element on hole typed layer. No. A Via is a composit, consisting of a circle on the hole layer, and various circles on copper layers, and circles on mask layes, and thermals. The layer concept should be physical, not a metaphysical abstraction. Objects in a layer may contain holes, but a hole layer is nonsensical, a toxic conceptual shortcut. An outline layer is similarly bad: the insulating layers may all have the same shape sometimes, but not always. So, a via needs a separate hole in each copper and insulating layer? And each layer needs its own discription of it's shape? Trying to model things that aren't layers as if they were layers is one common mistake in this kind of tool. Equally common is leaving out layers: the insulating layers in a PCB are just as important as the copper, and have their own properties (shape, thickness, material, etc.). They're a critical part of the layer stack. The description language needs to be able to express feature p in layer x is aligned with feature q in layer y in order to build up composites. This is the geometrically sensible way to describe the result of drilling through several layers. But the geometric description language should not be tied to any particular fabrication procedure. This is all too physikal for my taste. Why are you so attached to the concept of drilling? For the design of a layout, all that matters is that there are conductive connections between layers. For me, a layer is something that the designer puts shapes on. Shapes with atributes, if required. The semantics of these shapes on a given layer shall all be the same. Some of these are required for netlisting, some are steering the physical checkout. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
Kai-Martin Knaak kn...@iqo.uni-hannover.de writes: DJ Delorie wrote: However, I don't think we should start off with lines have paste. They don't. My current project happens to be a use case for lines with paste: I need to transport lots of current on limited space. And it needs to be very resistant to vibration (this is supposed to survive a rocket launch) So ordinary green wires soldered are considered a risk of failure. What we intend to do, is solder copper wires full length on the board. This calls for tracks with exposed copper and corresponding apertures in paste layer. Paste will allow for better control of the amount of solder than with a simple syringe dispenser. Currently tracks cannot be uncovered, let alone induce paste apertures. As a work-around I plan to convert the current path into pads just before the layout is exported to gerber. (Maybe, I should write a script...) This is of course a kludge. Upshot: Please try not to constrain possible attributes and properties of objects. There may be use cases even for seemingly weird combinations just around the corner. I don't think that paste shall be attributes of lines. Lines and paste live at the same level. If you need to connect them, you'd need to go one level up, like elements are one or two levels up from lines and paste, or vias are one level up. To implement this level (lines+paste) you will not need support from the file format, it's in the GUI. You may add attributes to lines and paste objects that effect the GUI to edit them together. IMHO, the file format shall loose all special support for levels (elemets, vias), just an arbitray hierachy of grouping, with attributes that tell the GUI how to present those to the user for editing. (Do I sound like John Doty now? :-) All will be well :-) Allowing a GUI way to enable/disable layers anywhere in the heirarchy would be cool; you could disable just the assembly objects in your generic silk layer. +1 ---)kaimartin(--- -- Stephan Böttcher FAX: +49-431-85660 Extraterrestrische PhysikTel: +49-431-880-2508 I.f.Exp.u.Angew.Physik mailto:boettc...@physik.uni-kiel.de Leibnizstr. 11, 24118 Kiel, Germany ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: subcircuit definition and channelised design
Krzysztof Kościuszkiewicz k.kosciuszkiew...@gmail.com writes: Dnia 2011-03-15 o godzinie 21:03 Bert Timmerman napisał(a): http://www.xs4all.nl/~ljh4timm/downloads/geda_sch2sym.tar.gz #!/bin/bash # gEDA - GNU Electronic Design Automation # geda_sch2sym.bsh # Copyright (C) 2007 Andrew Tan Says it all. It is also waiting for review here: https://bugs.launchpad.net/geda/+bug/698670 IMPORTANT NOTE: In order to run geda_sch2sym.bsh, users must make sure the hierarchy-traversal is disabled in the system-gnetlistrc file (usually located in the /usr/share/gEDA folder). There should be some way to disable hierarchy-traversal from the commandline, is there? Or at least a local gafrc, but even that would push it out of reach for me. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: subcircuit definition and channelised design
John Doty j...@noqsi.com writes: On Mar 15, 2011, at 2:50 PM, Stephan Boettcher wrote: There should be some way to disable hierarchy-traversal from the commandline, is there? Or at least a local gafrc, but even that would push it out of reach for me. You have to put a little bit of Scheme in some gnetlistrc someplace to control it from command line, but it can be done: http://archives.seul.org/geda/user/Nov-2008/msg00489.html I had a peek at the man page: -c string Pass the specified string to the guile interpreter. This allows you to execute arbitrary guile scripts from the command line. Be sure to surround the string with either single or double quotes to satisfy your shell. The string is execute before any init or netlist backend scheme code is loaded or executed. How about: gnetlist -c '(hierarchy-traversal disabled)' 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 -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
Martin Kupec martin.ku...@kupson.cz writes: On Tue, Mar 15, 2011 at 03:55:58PM -0600, John Doty wrote: On Mar 15, 2011, at 3:35 PM, Martin Kupec wrote: There will be a struct called via. It will contain a hole and pointers to attached object on all affected layers. No. A via is only one kind of composite object. The list of kinds of composite objects that might appear on a board is unbounded. There isn't even a single kind of via in real life. Having an ad hoc implementation of each such object is impractical and confusing. Well-designed software would avoid implementing such things as special kludges, but would have a general facility for describing them. Then, users could contribute to libraries of such descriptions, so we would not be so dependent on developers to spoon feed us every detail. Footprints are a particular case of this, but other kinds of composite objects (subcircuits, antennas, delay lines, buried vias, fuses, current sense resistors, printed inductors and capacitors, ...) could also be in the library if the software properly distinguished between primitive elements and composite objects. Ok. You got the point. I don't see how to do it right now, but I will think of it. We need at least hole element. And say which layers it goes through. But the rest can by just footprint. The problem I see is that the number of layers affected differs, so the footprint has to accomodate that. IMHO, as holes are circles draw on just another layer. People were asking for slots. If they find a vendor to do them, they may just draw lines on that layer as well. Else, DRC shall flag non-circles. Each such hole layer shall have a spec (attribute) to which (copper) layers they electrically connect. There will be at least one such layer for each type of blind, burried, and through via. The GUI will happily stack vias according to the selected routing style into a composites and paste them on the layout, so for simple cases nothing changes from how we work now. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: OT: Vintage uP
Ethan, Thanks a lot! Stephan Ethan Swint eswint.r...@verizon.net writes: Stephan- Here's what I've got in the Motorola family: MC68010L8 - 1 unit SC87876L8 - 1 unit MC68000P8 - 2 units MC68000P10 - 2 units These are all 64-pin devices; I'm not sure about the SC87876. It looks like shipping is reasonable - USD$13.25 for a DVD-sized box. Regards, Ethan On 02/13/2011 05:57 PM, Stephan Boettcher wrote: Ethan, Ethan Swinteswint.r...@verizon.net writes: I recently ran across a cache of 'vintage' microprocessors - a Motorola MC68010L8 and other MC68K chips, Dallas Semi Speed it uP, AMD 8088, etc. The are all in new condition, most in ESD foam. Any of these of interest to the list? Well, if you could ship to Europe in an unsusicious package to avoid customs excessive duties, I'd be interested in an MC68010L8 and maybe other MC68K chips (what are those? UART? FPU?) I could pay via paypal. Cheers, Stephan Regards, Ethan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user -- Stephan Böttcher FAX: +49-431-85660 Extraterrestrische PhysikTel: +49-431-880-2508 I.f.Exp.u.Angew.Physik mailto:boettc...@physik.uni-kiel.de Leibnizstr. 11, 24118 Kiel, Germany ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb commands to automatically select, cut, rotate, and paste elements
Mark Rages markra...@gmail.com writes: You would be wise to avoid PCB for anything non-rectangular. It is exceedingly painful. I do recommend pcb for anything non-rectangular. The arcs can be nicely done in gnumeric, python, awk, whatever. With a gui this will be difficult. For example the outline of the board on the attached picture (which will launch into space later this year to land on Mars) RADE_front.pdf Description: Adobe PDF document -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: polygon regression in pcb+gl
Peter Clifton pc...@cam.ac.uk writes: On Sun, 2011-02-20 at 10:36 +0100, Karl Hammar wrote: Peter Clifton: ... generate, and setup .ssh/config with these lines: Host git.gpleda.org Port 5022 RSAAuthentication yes IdentityFile ~/.ssh/keys/id_rsa.gpleda.org ... Don't you know that protocol version 1 i vulnerable for a man-in-the-middle attack? No, I didn't know that. Does it require a different type of key to be generated and used, or just removing that option to become secure again? id_rsa is a version 2 key. The RSAAuthentication may be used for version 1 only, but that does not mean specifying it makes ssh to use version 1. Do ssh -v git.gpleda.org to see which version is used. Most default sshd installations do not permit protocol version 1. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: polygon regression in pcb+gl
k...@aspodata.se (Karl Hammar) writes: Stephan: Do ssh -v git.gpleda.org to see which version is used. Most default sshd installations do not permit protocol version 1. Can't test that: $ ssh -v git.gpleda.org OpenSSH_5.1p1 Debian-5, OpenSSL 0.9.8o 01 Jun 2010 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to git.gpleda.org [97.107.141.5] port 22. debug1: connect to address 97.107.141.5 port 22: Connection refused ssh: connect to host git.gpleda.org port 22: Connection refused $ Regards, /Karl Hammar Peter could, you'd need to spec the port number :-) (stephan)blaulicht:~$ ssh -v -p 5022 git.gpleda.org OpenSSH_5.5p1 Debian-6, OpenSSL 0.9.8o 01 Jun 2010 debug1: Reading configuration data /home/blaulicht/stephan/.ssh/config debug1: Applying options for * debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to git.gpleda.org [97.107.141.5] port 5022. debug1: Connection established. debug1: identity file /home/blaulicht/stephan/.ssh/id_rsa type 1 debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 debug1: identity file /home/blaulicht/stephan/.ssh/id_rsa-cert type -1 debug1: identity file /home/blaulicht/stephan/.ssh/id_dsa type -1 debug1: identity file /home/blaulicht/stephan/.ssh/id_dsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5 debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-6 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server-client aes128-ctr hmac-md5 none debug1: kex: client-server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(102410248192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: checking without port identifier The authenticity of host '[git.gpleda.org]:5022 ([97.107.141.5]:5022)' can't be established. RSA key fingerprint is d7:07:7f:96:51:11:ab:43:57:0d:fe:92:45:72:e8:93. Are you sure you want to continue connecting (yes/no)? no Host key verification failed. (stephan)blaulicht:~$ -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Breaking up power planes
Russell Dill ru...@asu.edu writes: On Sun, Feb 20, 2011 at 10:05 AM, Kai-Martin Knaak k...@lilalaser.de wrote: Russell Dill wrote: I'm just wondering what everyones preferred method of breaking up power/ground planes is. My preferred method is to break the planes as little as possible :-) IMHO, a continuous copper plane is the best you can get for shielding purposes. If large amounts current need to be canalized, I prefer to guide them in fat tracks rather than polygons. With tracks it is easier to ensure a minimum diameter. My design has several different power and IO rails, and so it requires split power planes.I realize its possible to do with the polygon editor, it just seems like it'd be much easier with the line drawing tool. You want to split a polygon into different nets? Does that work? Even if you invoke the special magic to not loose isolated parts of the polygon, will the connectivity check treat them as separate copper and assign them to different nets? I've drawn separate polys for each power/gnd net on my boards. Let's see, ok, it does work. I'd still be uncomfortable with such a layout. test.pcb Description: Binary data -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
John Doty j...@noqsi.com writes: On Feb 15, 2011, at 9:40 AM, Stephan Boettcher wrote: DJ Delorie d...@delorie.com writes: The two words mean two different things in the English language. sorry, I wasn't clear on these distinctions. DJ has a very narrow and negative viewpoint on factoring. In the end, I do not care how you call what is being done, as long as the results are more like Unix, and less like Multics :-) Stephan Refactoring means changing nonfunctional attributes of the software (i.e. rearranging code to be more maintainable). Way, way too narrow. Refactoring can dramatically increase the power at the users' fingertips. Consider a favorite Brian Kernighan example. Take the Multics command: how_many_users In Unix, refactor it into: who | wc -l Now, you've given the user much more power with fewer commands. For example, ls | wc -l counts files, something I recall there was no command for in Multics. The large suite of inflexible, specialized commands in Multics collapsed into a much smaller set of commands that were specialized in one sense (what abstraction was served) but generalized in another (what end was served) in Unix. This put a lot more power in users' hands: many things that would have required a page of tricky PL/I code in Multics became simple shell one-liners in Unix. It was much easier to master and remember the smaller, but more powerful, set of Unix commands. If we're talking about changing functionality (as we were in this case), we need to use a different word. Functionality emerges naturally from good factoring. Without good factoring, functionality requires a large number of complex features that are difficult to remember and often don't play well with each other. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
Martin Kupec martin.ku...@kupson.cz writes: On Tue, Feb 15, 2011 at 11:17:27AM +0100, Stephan Boettcher wrote: And think about vias as well. Those need a major refactoring as well, to support custom via stacks, blind and burried vias. IMHO, vias should be layers as well, with attributes that tell to which conductive layers they connect. So maybe it is a good idea to keep vias in mind when redoing they way layers are handled. I was at the idea, that a via will be assigned set of physical layers and it will show in each cooper layer belonging to that physical layer. That should be relativly simple to achieve. And by default it will be assigned all the physical layers. Pressing shift or ctrl will make it ask what layers you want it to belong. Plus there need to be the possibility to change default temporary in order to aid making a lot of blind/burried vias at once. With different annular rings, and clearance on each layer, and non-circular shapes, ... A via editor HID shall at least provide means to modify annular and clearance independently for top, inner, bottom, soldermask top, soldermask bottom logical layers. The file formal shall allow to spec this for each physical layer as well. When we are at that point, a via is a stack of structures on various layers. The hole itself may then be just a circle on another layer of type via. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
Martin Kupec martin.ku...@kupson.cz writes: On Tue, Feb 15, 2011 at 09:45:40AM -0500, DJ Delorie wrote: I am not shure if it is possible to have non-circular drill holes in gerber files. We can have the pad around the hole be of any shape, but the hole itself probably needs to be circular. We can have any shape hole we want, if we export it as a gerber file instead of an excellon file. However, that doesn't mean the fab will manufacture it. I will stick with the current manufactors abbilities... Hmmm. We had requests to express plated slots in this group. If somebody defines an extra via layer for slots, and draws polygons or traces on it, the exporter should recognise that and produce a gerber instead of a drill file. The rest is negotiation with the vendor. PCB will be able to check the connectivity by the via connectivity attributes. I'd love to draw square polygons (or better traces without rounded caps) on a via layer and export to gds2 instead or gerber. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
DJ Delorie d...@delorie.com writes: The two words mean two different things in the English language. sorry, I wasn't clear on these distinctions. Refactoring means changing nonfunctional attributes of the software (i.e. rearranging code to be more maintainable). If we're talking about changing functionality (as we were in this case), we need to use a different word. An example of refactoring, in PCB's case, would be changing the underlying language from the C/C++ hybrid mess we have now to a clean C++ object-oriented structure, without changing the code's functionality at all. An example of redesigning, in PCB's case, would be changing the way the user manages the layer stack and what kinds of layers the user can describe. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: OT: Vintage uP
Ethan, Ethan Swint eswint.r...@verizon.net writes: I recently ran across a cache of 'vintage' microprocessors - a Motorola MC68010L8 and other MC68K chips, Dallas Semi Speed it uP, AMD 8088, etc. The are all in new condition, most in ESD foam. Any of these of interest to the list? Well, if you could ship to Europe in an unsusicious package to avoid customs excessive duties, I'd be interested in an MC68010L8 and maybe other MC68K chips (what are those? UART? FPU?) I could pay via paypal. Cheers, Stephan Regards, Ethan -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: transition of pcb internal units to metric (SI, mm)
John Doty j...@noqsi.com writes: I doubt PCB will ever be a suitable tool for chip design. Why? It should not make that a priority. But the hierachical features outlined elsewhere, layer types, a sufficiently generic via mechanism, its not too far from making it possible to do chip design. Hierachy, blind and burried vias, all these PCB features are on the list. Just steer the development just a little bit to make it general enough in the core/file formats. The GUI may be 100% PCB by default and hide the generality from the user. Chip design will then need another pile of code to interpret the drawing in terms a silocon technology, at least a gds2 exporter. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: PCB bug: only names, draw a line, undo: segfault
PCB version 20100929 Compiled on Nov 8 2010 at 05:46:11 Debian sid. gtk. - Settings-Only Names - draw a line - hit 'u' for undo. - segfault. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gnetlist (bug?) subcircuit symbol without pinnumbers
Hi, a few comments/questions on this weekends gnetlist experince: gnetlist via gsch2pcb complains a lot, and adds a pin U?-? on every net that connects to a specific symbol for a subcircuit (with source= attibute). The error messages are not helpful. It took a while to figure out that gnetlist is unhappy about not finding pinnumber= attibutes on the pins of that symbol. Why does a subcircuit need pin numbers? The connectivity is establisched via pinlabel= (although pinnumber= would be more intuitive, at least until we get rid of all the attribute overloading, and since pinnumber= seems to be required for unknown reasons). Why does gnetlist not tell which entity it is complaining about in its error messages? $ gnetlist --version gnetlist: unrecognized option '--version' ... oh, that is unhelpful as well, no cut'n paste from the gschem about box either. Let's see, $ dpkg -s geda | grep ^Version Version: 1:1.6.1-4 Debian sid. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB bug: only names, draw a line, undo: segfault
Stefan Salewski m...@ssalewski.de writes: On Sun, 2011-01-30 at 14:48 +0100, Stephan Boettcher wrote: PCB version 20100929 Compiled on Nov 8 2010 at 05:46:11 Debian sid. gtk. - Settings-Only Names - draw a line - hit 'u' for undo. - segfault. Works fine for Gentoo AMD64, tested empty board and tut1.pcb. PCB version 20100929 (GTK) Ok, I tried again, empty board, and yes, the segfault does not happen when a line draw is completed (with the middle mouse button). It only happens when I hit u (undo) after drawing a track segment, but did not terminate the draw (with middle mouse button). -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB bug: only names, draw a line, undo: segfault
Peter Clifton pc...@cam.ac.uk writes: On Sun, 2011-01-30 at 15:22 +0100, Stephan Boettcher wrote: It only happens when I hit u (undo) after drawing a track segment, but did not terminate the draw (with middle mouse button). That matches the same set of steps where I can trigger the valgrind warning. As an added data-point, I was able to reproduce with Only names switched off when I started line-drawing, but switched it on mid-way, before I hit undo. A cursory glance didn't suggest what might be wrong yet.. please file a bug at: http://launchpad.net/pcb/+filebug That site shows a white page with a [continue] button, and then I click on it, it says 'Invalid OpenID transaction'. And when I turn on Javascript, it does nothing more helpfu either. And anyway, I do not have an account with launchpad, and I don't think I'd want one. Sorry. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
Peter Clifton pc...@cam.ac.uk writes: On Mon, 2011-01-24 at 07:48 -0800, Ouabache Designworks wrote: The special symbols is supposed to fuse netnames as issued on the netlist, not labels on the schematic. --- If you are also fusing the copper on the board then I would kind of like to see that when I am viewing the schematic. You want to give the user a choice. If I pull up a component view then I want to see the signal names from the original designer. If I am traversing a hierarchy and open an instance view then I want to see the signal names that match the names in the parent instance. John Eaton For a loop antenna, for example, the solution needs to be in PCB.. allow footprints / functional groups which implement RF components by placing copper on some layer. For me, this raises a very interesting design question: How do I go from abstract inductor / transmission line / (capacitance even?) representations on a schematic, to correctly DRC'd board layout? This will probably require an additional tool. The tool needs to extract the properties of the wiring from the layout via some techology file that describes the properties of the board materials (layer stack, etc). The schematic will have attributes on nets that spec what to check for. IMHO, net segments should be explicitly marked with the short-symbol that was discussed. A gnetlist backend will provide a netlist to the verification tool that includes the attributes and net segments. The PCB gnetlist backend merges the net segments. How to split out the net segments during extraction is probably not easy. The inductor will end up as a shaped piece of copper tracking, and at this point, you realise that net is a very DC term! The inductor could be a subschematic with shorted pins via two short symbols, with a net in between that asks for an inductance check of some sort. We would need to have some way to demarcate the start and end of the inductor in PCB, or to draw it on a layer, or with an attribute which causes the copper making up the component to be disjoint from either net connecting to that section. That piece of board layout becomes a component, not an interconnect between components. The DRC could be told to treat certain layers in a group as component copper. One might imagine a similar method being useful to join two hierarchically shorted nets together... have a link component which joins AGND and DGND, which is implemented by copper drawn on the board between those two power planes. This would then allow preservation of important DRC checks such as making sure the correct plane / return path is used for signals. Regards, -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
John Doty j...@noqsi.com writes: On Jan 24, 2011, at 11:57 AM, Kai-Martin Knaak wrote: Steven Michalske wrote: We would also need a way to force the chosen name of the net to choose when merging nets. e.g. When you merge a net named power with a net named 3v3_power, who wins? If a two pin symbol mediates the fusion, this would be determined by the connections to the symbol. The symbol would comprise a win-pin and a loose-pin. The winner would be the net that is connected to the win-pin. Works for the simplest case: net1 net2 ---(WP,LP) The combined net would be net1. But a little more complicated: net1 net2 net3 ---(WP,LP)(LP,WP)- Is this net1 or net3? At some point the user looses for his own stupitity. I'd just require a well defined topology, and tell the user if the resolution is not unique, then he has to accept arbitrary results, based on the random order of evaluation of the shorts. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
Ouabache Designworks z3qmt...@gmail.com writes: The special symbols is supposed to fuse netnames as issued on the netlist, not labels on the schematic. --- If you are also fusing the copper on the board then I would kind of like to see that when I am viewing the schematic. PCB requires all connecting copper to be the same net(name). gnetlist needs to resolve merged nets to a single net. That happens now for hierarchy, except when a subcircuit shorts two higher-level nets. This could probably be fixed, with a warning and some arbitrary choice how the net is named. You want to give the user a choice. If I pull up a component view then I want to see the signal names from the original designer. If I am traversing a hierarchy and open an instance view then I want to see the signal names that match the names in the parent instance. There is no instance view in gschem. John Eaton NB, when resolving hierarchy, gnetlist keeps the netname of the outer level. Sometimes I'd wish it would keep the subcircuit netname. This would also resolve the case when a subcircuit shorts two outer nets. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gerber outlines
Rob Butts r.but...@gmail.com writes: I'm trying to provide Dorkbot PDX with gerbers for a two-layer circuit board. They require an outline gerber so I followed the http://geda.seul.org/wiki/geda:pcb_tips#how_do_i_make_a_board_outline_to_go_with_my_gerbers_to_the_board_maker instructions by naming the active layer which for me was the component layer 'outline'. No. You need to add an extra outline layer, which is empty except for the board outline, which needs to be drawn as a closed seqence of lines (and/or arc?). I then exported the gerber file and the outline gerber still shows nothing. The help link above makes it sound like PCB will generate the outline automatically to the 'outline' layer absolute edge. No such automatism. Do I have to draw these lines in or does PCB do this and what should I see when viewing the outline gerber layer? Yes, you need to draw them. The fab gerber includes an outline trace, which is the 'absolute edge' of your design when there is nor outline layer. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gerber outlines
... you can either rename a layer ... ... you can either rename an unused empty layer ... ... that exclusively contains the objects in the outline layer. ... in particular, no vias and pins. ... the width of the lines does not matter. The fab will cut the board at the center of the lines. Is this universally true? At least our milling machine mills the outline on the outer edge of the lines. The guy who runs the machine says, he cannot easily tell the programm to mill along a center line. I prefer to keep the line width within tolerances to both sides, so if the fab ignores my README specifying the centerline, it is no big deal. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Visual cue of zero length pin endpoint
Andrzej ndrwr...@googlemail.com writes: On Mon, Jan 24, 2011 at 12:01 AM, Peter Clifton pc...@cam.ac.uk wrote: libgeda was recently patched to allow zero length pins. Please point me at where the documentation says this is invalid, and I'll file a bug about getting that changed. http://www.geda.seul.org/wiki/geda:file_format_spec#pin You cannot have a zero length pen (the tools will throw them away). The typo in this sentence technically makes it invalid. ;-) Same requirement exists also for other data types. You are correct there, those driving the zero-length pins change should consider whether this is a problem or not, and if so - what do do about it! It makes sense to extend the spec to cover zero-length pins (IMHO other shapes should stay non-zero sized) but it would be better if the spec explicitly said when and for what purposes pin directionality can be used. In the current version there is no mention of it but since pins are guaranteed to have a direction, it's not unreasonable to use this property for all sorts of things. I just made a symbol with 624 zero length pins. Please keep them :-) -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem: directly connecting two nets?
Colin D Bennett co...@gibibit.com writes: Sometimes I would like to directly connect two nets. There are a number of different specific cases in which I would like to do this for simplicity in the schematic. For instance, I might have an input port component (e.g., input-1.sym) on a connector pin with net VLCD, and then somewhere else in the schematic want to show that VLCD is connected to +3.3V. However, after some investigation as to why I wasn't getting the right rats in 'pcb' after a gsch2pcb import, I realized that connecting two nets in gschem (using a power symbol and/or an I/O port symbol connected with a net line) does not create that connection in the netlist! I think the gnetlist drc did emit a warning due to this, but I did not understand the cause... Is there any correct way to show two nets are directly connected in a schematic? e.g., connecting two I/O ports or two power symbols directly. Hmm, yes. You need to invent some 2-pin symbol with some special attributes, and teach the pcb gnetlist backend(s) to interpret those attributes as a net-unification bridge. There should also be a convention how that net should be named in the output. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
Markus Hitter m...@jump-ing.de writes: Am 18.01.2011 um 01:56 schrieb John Griessen: I thought about this some more after sleeping last night, and what Markus is probably asking for is a position range sensitive diff or auto- merge. When people make changes in PCB that can be merged, it means they are working in different places, zones, quadrants... IOW if you could say easily *where* you were working was different and not overlapping another's work, an auto-merge would work -- if it only over-rode layout traces and footprints in the limited zone of the change made... That reminds me on an idea discussed here a few weeks ago: drop the current footprint logic and replace it with full fledged circuit layouts. You'd edit the sub-layout in it's own file and insert that into the total layout as a non-editable, but movable block. One possible drawback for both ideas: you can't route tracks through the foreign area/sub-layout, even if there's enough room after assembling the zones. Why do you need that limitation? Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user -- Stephan Böttcher FAX: +49-431-880-3968 Extraterrestrische PhysikTel: +49-431-880-2508 I.f.Exp.u.Angew.Physik mailto:boettc...@physik.uni-kiel.de Leibnizstr. 11, 24118 Kiel, Germany ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
Markus Hitter m...@jump-ing.de writes: Am 19.01.2011 um 22:27 schrieb Stephan Boettcher: Markus Hitter m...@jump-ing.de writes: Am 18.01.2011 um 01:56 schrieb John Griessen: I thought about this some more after sleeping last night, and what Markus is probably asking for is a position range sensitive diff or auto- merge. When people make changes in PCB that can be merged, it means they are working in different places, zones, quadrants... IOW if you could say easily *where* you were working was different and not overlapping another's work, an auto-merge would work -- if it only over-rode layout traces and footprints in the limited zone of the change made... That reminds me on an idea discussed here a few weeks ago: drop the current footprint logic and replace it with full fledged circuit layouts. You'd edit the sub-layout in it's own file and insert that into the total layout as a non-editable, but movable block. One possible drawback for both ideas: you can't route tracks through the foreign area/sub-layout, even if there's enough room after assembling the zones. Why do you need that limitation? Without that limitation, a zone is no longer a zone and conflicts can happen. Doesn't apply for tracks drawn to the main layout, of course. Also doesn't apply to sub-layouts of undefined size, but then the idea of sectoring a board for different contributors becomes a bit limited. Why? If everybody sticks to a sublayout, at least the VCS merges will not conflict. If the drawn copper conflicts, that's what needs to be cleaned up after the merge. For efficient collaboration there should be some aggrement about who draws where, but technically there should not be any limits how sublayouts overlap. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
Peter Clifton pc...@cam.ac.uk writes: On Tue, 2011-01-18 at 16:05 +0900, John Doty wrote: Note that there's a bit of terminology confusion. gschem actually manipulates segments of nets (other tools sometimes call these wires), while net in EE theory is usually a topological whole, where the connection is assumed to be structureless. wires is a useful distinction here, although it sounds like it implies something physical. I'll try to call them net segments from now on. Sometimes a gnetlist backend might wish to request the connectivity of a net (the topological whole). IMO libgeda should be able to provide that. (A library or convenience function if you will). It does not happen very often, but in this point my opinion disagrees with John's, I think. The whole point of libgeda and gnetlist is to express connectivity between pins. Machine-interpreting meaning into the details of the individual net segments is a confusing concept, that should not be encouraged by the tools. If such things need to be expressed, I'd introduce a new type of symbol, and teach the gnetlist backend that needs those semantics to treat both/all connections to that symbol as the same net, but with different attributes. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: multiple attributes
al davis ad...@freeelectron.net writes: How about prefixing simulation attributes with a dot. No, please, use a proper namespace prefix, like spice- verilog- sim- spice: verilog: sim: Backend namespaces, use namespaces, with fallbacks into legacy and global namespaces. spice-value= sim-value= value= -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
Markus Hitter m...@jump-ing.de writes: Being more a mechanics and software guy, I'm astonished how things in the electronics world apparently work. Perhaps I'm exaggerating a bit. Is it even possible to do something in collaboration? I'd appreciate any answer. In our lab we recently had very nice results partitioning the work across multiple boards. The mechanics engineer did a fine housing, a PhD-student made the front-end board with eagle, I made the main board with gEDA/PCB, and our electronics engineer does the power board, using eagle. There was FPGA and ARM7 firmware to do as well. Lot's of opportunities to devide work and to collaborate. You have to agree on the interfaces for sure. But collaborating on a single layout is pretty stupid. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: FYI [Fwd: [Balloon] Balloon 4]
Peter Clifton pc...@cam.ac.uk writes: On Sun, 2011-01-16 at 11:44 -0600, John Griessen wrote: On 01/16/2011 11:32 AM, John Griessen wrote: So I don't see how that was a stopper, even without Bill's specific Altium experience. I meant Bob's I'm lost.. who is Bob? You do not use a thread view in your mail reader, do you? -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
ge...@igor2.repo.hu writes: If you edit one object, that won't ever move other objects around by side effect. VCS systems I know depend on this feature. I think PCB already provides this feature, keeping order of objects, Not really. When you edit a line, it somehow gets thrown into an entirely different slot in the list. Like if there is a vector of allocated slots, some marked unused, and when something is changed, it is thrown into the first unused slot. Probably some feature of some glib(?) container class? It's not too bad for vcs diffs, but could be a little better. Not worth the trouble to fix this, I guess. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
Peter Clifton pc...@cam.ac.uk writes: On Fri, 2011-01-14 at 21:14 -0500, al davis wrote: Reading a file is easy. The hard part about the geda format, where use of libgeda may be advantageous, is establishing connectivity. A mix of libgeda, with gnetlist wading in and flattening things (perhaps unhelpfully). I want to see all connectivity code move into libgeda, and flattening be optional. I don't know where that is done, or if it is done in a form that would be useful here, or whether there exists the code to go the other way (generate a schematic given a netlist and rendering info) which is equally needed. Not done. Would be nice though - but I'd rate it of similar complexity to a board auto-router. (Not as rigidly constrained topologically, but to do well would require a decent auto-place, and a decent auto-router - even if the rules are different to that used with a PCB). Why would anybody want such a schematic? I see two semi-graphical ways to express a netlist in gschem format. 1. Each element uses the same generic symbol, with the proper attributes attached, and net= attributes for connectivity. Placed on some grid in arbitrary order, optionally so that the attribute lists do not overlap when viewed graphically. 2. When symbols are available for the elements, those can be placed on some grid, and each pin gets a little net stub with netname= for connectivity. Last millenium, some cadence netlister move such schematics from synthesized Verilog netlist, but I do not remember why they were needed in the flow, certainly not for human inspection. A mixture between 1. and 2., in case there is some way to feed an element to symbol map into the process, falling back to 1. for elements without symbols. But that use case is What are the use-cases? Mix gschem schematics with synthesis output into gnetlist for ASIC or simulation targets? -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Rant about Make Inv Text Vis
Peter Clifton pc...@cam.ac.uk writes: On Sat, 2011-01-15 at 07:54 +, Peter TB Brett wrote: - Original message - What is the point of the command Make Inv Text Vis in gschem, other than aggravating me. Good question. I'm not aware of a use-case for it either. At the very least, it should be undo-able. Please file a bug report. Lets kill it with fire. Yes, please! -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Rant about Make Inv Text Vis
Vanessa Ezekowitz vanessaezekow...@gmail.com writes: On Sat, 15 Jan 2011 16:25:39 + Peter Clifton pc...@cam.ac.uk wrote: On Sat, 2011-01-15 at 09:10 -0600, John Griessen wrote: On 01/15/2011 06:59 AM, Stephan Boettcher wrote: Yes, please! +1 Consider it napalmed. Napalmed ain't enough - I want that option *nuked* (from orbit yet). :-) The worst part is the keyboard shortcut e v, just the reverse of the frequently used v e. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB antenna pattern
Kovacs Levente leventel...@gmail.com writes: I am designing a zigbee interface, and I am using an inverted F antenna out of PCB pattern. The problem is that the terminals of the antenna pattern are shorted (well not on 2.4GHz), so I don't have any clue what to put to the schematic. So far, I simply grounded the antenna pin of the transceiver, but it can lead to misunderstanding. The other option is to have a two-pin symbol, but the pattern will cause short circuit when running the DRC. Any suggestion? I'd put the antenna, or at least the short, on a separate layer, in the same group as the normal copper layer. For verification, you can temporarily move the antenna layer to it's own group. Just remember to do the checkout with the correct group assignment. If you get an extra gerber layer for the short, then you know you made a mistake. Thanks, Levente -- Stephan Böttcher FAX: +49-431-880-3968 Extraterrestrische PhysikTel: +49-431-880-2508 I.f.Exp.u.Angew.Physik mailto:boettc...@physik.uni-kiel.de Leibnizstr. 11, 24118 Kiel, Germany ___ 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 (5)
Krzysztof Kościuszkiewicz k.kosciuszkiew...@gmail.com writes: I would say the existing attribute/backend/semantics interaction matrix is complex enough to require full analysis of the implications of yet another attribute being added... The matrix is so complex because it is not orthogonal. The solution is: more attributes and less overloading, not the reverse. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: multiple attributes
Matthew Wilkins matthew_m_wilk...@yahoo.ca writes: There _is_ a meaning to the order if a netlister expects only one attribute, but the symbol has several of the same name. In that case, the netlister could find either the first attribute of that name or the last, depending on how the netlister was written. This should either case an error or a prominent warning. About overloading: Sometimes it's desirable to overload attributes; for example I might want to simulate a circuit through a spice netlister, then generate a BOM of the parts in the simulation. Having the BOM netlister use the same value attributes as the simulation helps prevent errors in keeping the two flows in sync. To give the user the choice of overloading the symbols or not, each netlister could first look for a netlister-specific attribute, and if that doesn't exist then use a generic attribute. i.e first look for spice-sdb-value, and if that doesn't exist then use the generic value. And that is the way forward for the problematic overloading we have right now, e.g., the pinseq attribute: The spice netlist shall learn to use a (spice-)port-order attribute, or however that shall be named, and fall back to pinseq, with an obsolescence warning. spice-port-order port-order pin-seq (obsolete) I like your idea. What is the spice term for pins? -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
