Re: gEDA-user: Subnets
John Griessen j...@ecosensory.com writes: It's not pie in the sky. Some of these ideas to use sets and lists and groups are the easiest kind to implement... Zones in layout are an easy part of what it already does, when we have more layers for intermediate calculations. net attribs plus layout zones get us far on the way to autorouting success. If there is work put into partitioning a layout, can't we please have hierarchical layout instead? -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
DJ Delorie wrote: Sure, and the big EDA code based on LISP/Guile also uses syntax for names so a wire with such a name attrib seems to be all that's necessary to define a bus. Putting the syntax netname[0:7] into form netname[0], netname[1], for the backends is fine. Seems to me the common code would still need to be aware of bus nets. I published my paper mostly to get a discussion going on what busses *mean* though, not the implementation details. For example, what does it mean when three busses with different names are connected? D[15:0] ==** D[15:0] || \\ A[1:16] The problems I see with this are: * 2 names for the same bus are probably confusing for a user * if busses of different name are allowed to connect, they should have the same wire layout * if they really shall look like above, the number of wires must be equal and the obvious mapping mechanism must be in place If all this is not for you, would it be possible to make a bus-mapper/connector symbol? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
DJ Delorie wrote: And I want to understand the implications of pins that reflect multiple signals, too - mapping names and numbers, etc. I can only envision 2 cases for a multipurpose pin: a) the generic interface shall be preserved - don't care what the pin means, just pass a wire b) the pin is actually used for something hardwired in the board - it's no longer multipurpose ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
John Griessen wrote: 1) Assign unique refdes value to all netlistable logical symbols in the schematic. If the logical symbol is one of several in a PHYSICAL_package, then assgined refdes to each logical symbol such as Uxx_yy; where yy is the value to identify a particular LOGICAL_SYMBOL among several within a PCB_PACKAGE; and xx value is the ID to differentiate among all PCB_PACKAGE for your design. Uxx is what you want to see in your PCB netlist. maybe I misunderstand something here, but if you want to say '_' in Uxx_yy is actually a separator you should come up with a positive definition of what a standard refdes can be made of. The sloopy way chars get assigned special meanings with all sorts of identifiers in geda really annoys me - and imho bites everyone in the long run. The above example would make another step to: you may not use ':' in blah, unless foo is set to 5, and '-' can bit you in some circumstances. I can assure you that '_' is valid in refdes, unless it's used for a bus in which case... Depending on the phase of the moon, '/' in an identifier can mean either:... ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Commercial CAD, land pattern generators report
John Griessen wrote: On Fri, Aug 13, 2010 at 10:54 AM, Peter Clifton pc...@cam.ac.uk wrote: On Thu, 2010-08-12 at 09:17 -0500, John Griessen wrote: OpenNurbs.org has the code, public domain. He's considering forking and licensing it GPL. IMO, that sounds like quite an aggressive thing to do to a code base.. particularly forking, then choosing a less permissive license to release under. He finds there is little community involved using it and no one improving the code except the original commercial publisher for bug fixes. That's the only reason for a fork. ...or the forker has sigificant issues with the way in which the original author/project leader is managing the original tool. For example, the IPCop fork of Smoothwall. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb: experience with import-schematics
kai-martin knaak wrote: Look at make_footprint_hash() in src/buffer.c Maybe we need to read the menus in reverse order? ^ paths? I'd say, the last path should receive highest priority. This is how the PATH environment variable of the shell is parsed. you mean the first directory has highest priority, same in linker paths ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
John Griessen wrote: In your work flow, English words convey duties to hired layout persons. In my example, I only hire the autorouter. Sounds very useful. Especially for open hardware projects and hobbyists, and bottom line oriented business folk. Sounds like you suggest the autorouter as suplement to propper understanding of layout - I've been struggling and reading for weeks now with this subject. One of the primers I found states: ... The autorouter is a tool to speed up the work of specialists and should be avoided by beginners. It is no replacement for understanding the implications of your layout... My very little experience with autorouters also makes me believe, that an autorouter has even less understanding of EMI issues than I have ;-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
On Mon, 2010-08-16 at 11:23 +0200, Armin Faltl wrote: John Griessen wrote: In your work flow, English words convey duties to hired layout persons. In my example, I only hire the autorouter. Sounds very useful. Especially for open hardware projects and hobbyists, and bottom line oriented business folk. Sounds like you suggest the autorouter as suplement to propper understanding of layout - I've been struggling and reading for weeks now with this subject. One of the primers I found states: ... The autorouter is a tool to speed up the work of specialists and should be avoided by beginners. It is no replacement for understanding the implications of your layout... My very little experience with autorouters also makes me believe, that an autorouter has even less understanding of EMI issues than I have ;-) And an autorouter, which has no idea of the intended layout by the designer, is really not too useful. When we give some hints, the autorouter may become more useful. But in first line the define netclass in schematics proposal was bound to manually routing. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Subnets
On Mon, 2010-08-16 at 10:09 +0200, Stephan Boettcher wrote: John Griessen j...@ecosensory.com writes: It's not pie in the sky. Some of these ideas to use sets and lists and groups are the easiest kind to implement... Zones in layout are an easy part of what it already does, when we have more layers for intermediate calculations. net attribs plus layout zones get us far on the way to autorouting success. If there is work put into partitioning a layout, can't we please have hierarchical layout instead? I have still problems to understand the goals and benefits of partitioning hierarchical layout on PCB board level. Can you give an example, when possible with a picture? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Specification of Rotations for Auto Assembly
Rick Collins wrote: This seems like a pretty sharp group. One of the problems I consistently have is generating an XYRS file for auto assembly of my boards. The X and Y require a specified origin and orientation of the board, which is done in the fab drawing. The side is pretty clear as well. But I always have trouble with the rotations. There are two sides and even if you pick a convention for the angle of origin and the direction of rotation, you still have to decide if the bottom side is viewed from the top or the bottom. When I have asked assembly houses about what they assume as convention, I never get an answer. They just tell me that they need the X and Y data along with the side. They basically figure out or at least verify the rotation data for themselves. Is that what you find? It just seems very odd that there is no accepted and widely used convention for rotations. I found info from IPC that says pin 1 in upper left corner is 0 degrees for ICs. But I've seen nothing that addresses how to spec the bottom side components. A FreePCB companion program. FpcPlace assumes all rotations are CCW and viewed from the top. But the footprint generator makes the footprint with pin 1 in the lower left which screws everything up, or so the FpcPlace developer says. It looks to me like the FpcPlace program is not correct. One of the things I dislike about pcb is the coordinate system: it's lefthanded, or z+ is going into the screen instead of pointing out. The right hand rule says: if you spread your first 3 fingers (starting with thumb) orthogonal to each other, thumb = X, point = Y, middle = Z ( or if you hook your fingers to indicate a rotation that will move X into Y, spreaded thumb poins to Z+). This is the basis for all math definition on vector operations in 2D and 3D, it defines the mathematically positive sense of rotation (CCW from above). All mechanical CAD systems and robotics controls adhere to this. So to define a rotation consistent with production, the first thing one must do is set up a proper 3D coordinate system. As a SCARA robot can only access one side of the board at a time, it's now a matter of convention, whether your designer procomputed rotation fixes the base coordinate system to the board (that gets flipped, so Z+ points up or down) or to the robot base. If I were to come up with a convention, I'd fix it to the board, since the actual placement of the board in the robot system (position and rotation) is unknow to the designer anyways. Next convention would be X is longer side, Y is short for rectangles. To define the complete position, one has to carry out 2 rotations (I know they can be combined to one oblique) for the backside: flip the board, then somehow rotate the chip. As the rotations can be combined, they can't be independent: you could flip the board around it's X-axis (makes most sense to designer) or it's Y-axis or around robot-X (what they fabs probably do) or around any other axis in the XY-plane, yielding completely different angles for the chip rotation. That's what the fabs actually tell you: if you believe the XY-plane to be in the center of the laminate, indicate which side is Z+. HTH, Armin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
On Fri, 2010-08-06 at 17:42 -0700, Andrew Poelstra wrote: Layer groups as I proposed separate the board into different workspaces to keep things organized. I understand your goal, and support it. But I still have problems to imagine how workspaces will work for layout process. At the end all traces and elements must fit on the board, and there space is the limiting factor. Of course I understand more simple concepts, like better support for selections (selecting all elements from one schematic sheet, all elements from a subcircuit like an amplifier or DC-DC-converter,...) or crossprobing. But your desire seems to be beyond that. So am example with a picture may be fine. Best regards, Stefan Salewski ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
On Sat, 2010-08-07 at 12:58 -0700, Andrew Poelstra wrote: I agree, but on a high level a net /is/ a relation between two pads/pins. (Well, a net can have many pads/pins. A subnet would be restricted to two, by definition.) No. A subnet, in my mind, is not restricted to two nodes (pin/pad). The +5V net with netname five_volt_positive can contain a high current subnet including DC-DC converter, big capacitor, fuse, high current devices. Just to make this clear. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: DRC rule structure
Actually, I don't think that's true: Suppose I have a trace whose clearance is set to 2.5mm - if I lay any component too close while the real-time DRC is running, how can it know that it's breaking a rule without re-checking the clearance for every object on the PCB? By checking exactly the object you are currently trying to place against the traces in vicinity, that can be found by bounding-box intersection. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb: experience with import-schematics
Armin Faltl wrote: you mean the first directory has highest priority, same in linker paths Ouups, your are right. ---)kaimartin(--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb: experience with import-schematics
DJ Delorie wrote: For PCB, you'd edit $HOME/.pcb/settings to say something like: lib-newlib = ../imported- symbols/:../gedasymbols.org_salewski_symbols/:../custom-symbols/ For the GTK GUI this is overwritten by $HOME/.pcb/preferences IMHO, the settings/preferences confusion needs to be sorted. lib-contents-command = /bin/true What is this command supposed to do? ---)kaimartin(--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
On Mon, Aug 16, 2010 at 01:18:37PM +0200, Stefan Salewski wrote: On Fri, 2010-08-06 at 17:42 -0700, Andrew Poelstra wrote: Layer groups as I proposed separate the board into different workspaces to keep things organized. I understand your goal, and support it. But I still have problems to imagine how workspaces will work for layout process. At the end all traces and elements must fit on the board, and there space is the limiting factor. Of course I understand more simple concepts, like better support for selections (selecting all elements from one schematic sheet, all elements from a subcircuit like an amplifier or DC-DC-converter,...) or crossprobing. But your desire seems to be beyond that. So am example with a picture may be fine. No, that's pretty much it. There are two things I want beyond simply workspaces to hold different tool settings for different functional groups: 1. You can create a view based on anything, not just functional groups, as will be the default. This includes opening components in their own view and editing them, or saving views as components. 2. Functional groups give one more structure to attach DRC rules to, between individual components and the entire PCB. The implementation of functional groups would be to simply add another attribute to each object, functional-block, which would determine which function block(s) each object belongs to. It merely allows one to classify parts, and to search or filter on this classification. As for workspaces: By default, PCB will open the Everything view, as well as a view for each functional group in a layout. However, the concepts of functional group and workspace are actually completely independent, though it may not appear that way to beginners, for simplicity's sake. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: discussion on what busses *mean*
DJ Delorie wrote: I can't think of a good reason to do this, but I suppose you could connect to a bus pin (aka pin with multiple signals) and name the *bus* while leaving the individual *nets* unnamed, and carry that bus name on to a second schematic page, still without naming the nets, and connect it to another bus pin with the same number of signals, and hope it all works out :-) If a bus-pin (or bus-port?) is required to have an internal representation of the pin connections and the two bus-things ;-) are required to have identical layout it should work - it's like a cable with colored wires. If the bus definition exists independently of the ports (ie. the list of wire colors aka signals, irrespective of any plug type), one has the freedom to pick any subset of the signals and define a port for it on a part. I hope this wasn't to trivial to mention. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: DRC rule structure
On Mon, Aug 16, 2010 at 03:25:08PM +0200, Stefan Salewski wrote: On Mon, 2010-08-16 at 06:12 -0700, Andrew Poelstra wrote: 1. I would have to create bounding boxes for every object on the screen, because you never know if some weird part 10 inches away has a 10-inch clearance requirement. Guess: Make bounding boxes which includes the clearance for each, so all not overlapping boxes fulfill desired clearance? I think this is the best plan - aside from cajoling the existing clearance checking code to working with my structure, that is. :) Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: pcb keyboard shortcuts (and usability in general)
i have finally fetched the source from git and rebuilt pcb. the most prominent new feature seems to be the polygon hole mode (which seems to create negative polygons inside polygons essentially). it has no keyboard shortcut assigned. since it is related to polygons i would suggest to assign some modifier (e.g. shift) + F6, what do you think? there was some discussing about adding tooltips with the shortcuts to the tool buttons in the new icon set... thread. are there any concrete plans to implement this? the Btn3 (shift+rightmouse) tools menu also lacks display of these shortcuts. is that intended or just not implemented? shortcuts for enabling/disabling layers is documented, but seems to be broken for me. docs say: ‘ToggleVisibility(Layer)’ Toggles the visibility of the layer. Mod1Key1: ToggleVisibility(1) Mod1 is mapped to alt in gnome afaik, so this should be alt+1? also the command itself does not work if entered via die command line: unknown action `ToggleVisibility'. also i am missing default shortcuts for some things i do _all_ the time while working with pcb: toggling settings/orthogonal moves toggling settings/crosshair snaps to pins and pads toggling settings/autoenforce DRC clearance opening menus (this is alt+some_char_from_the_menu_name in all* pc applications (*all but finitely many ;) why not in pcb?) saving (ok its possible to do this vi-style (:wenter), but assigning ctrl+s would not hurt anyone?) ... and there are so many (useful) commands, that are not visible in the gui at all, like the recently added FreeRotateBuffer(). e.g. MorphPolygon or ChangeClearSize(SelectedPins|SelectedVias, ...). maybe including every command would clutter the menus too much, but having a list of all commands similar to the shortcut list at hand without the manual would be useful imho. the shortcut list should be completed to list all available shortcuts in the program (maybe even those mentioned somewhere else (that would allow easier customization without creating conflicts with existing shortcuts). tab complete for the command line would help also (i think i saw it in some todo in the source tree already). is that all deliberately not included in the gui or would you accept patches? is there any written masterplan for (gui) enhancements? is there interest to debate reorganizing the current menu system + (re)assigning shortcuts at large? i have to admit, that i have not looked into the code a lot and that i don't really have a clue about (gtk) menu programming (yet). i also don't know how much time i want to dedicate to this, but i think pcb's usability, especially to newbies, can easily be improved by some of the things mentioned. i have not looked yet at (the) developer docs/design guidelines if there are any. if there are any not obvious/google-able docs, please advise. (i hate those mails, that start with that tiny question and result in something like this. :) -- Kind regards, Stefan Tauner ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
Stefan Salewski wrote: On Sat, 2010-08-07 at 12:58 -0700, Andrew Poelstra wrote: I agree, but on a high level a net /is/ a relation between two pads/pins. (Well, a net can have many pads/pins. A subnet would be restricted to two, by definition.) No. A subnet, in my mind, is not restricted to two nodes (pin/pad). The +5V net with netname five_volt_positive can contain a high current subnet including DC-DC converter, big capacitor, fuse, high current devices. Just to make this clear. Just to make it known, a subnet is a point to point connection within a net was the one and only DEFINITION of what a sub net is I found and understood. All other ways I can conceive are generalizations of that, ie. a subnet is a list of 2 or more pins within a net. For lists of 3 or more pins attributes like length or impedance don't make any sense, so this appears to me a bit like sound and smoke. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: DRC rule structure
Andrew Poelstra wrote: There are two problems with this: 1. I would have to create bounding boxes for every object on the screen, because you never know if some weird part 10 inches away has a 10-inch clearance requirement. If pcb-objects don't have bounding boxes as of now, there's something severly wrong anyway 2. Small parts, like vias, are able to be completely contained within the bounding box - so checking for intersections won't help me A bounding box test as I should have named it consists of several checks, one of which can be intersection. Since traces have finite width in reality one will perform 2 coordinate sorting tests (x and y), then find the closest point on the center line of a trace segment for all 4 corners to see if a corner gets touched and then intersections of the box lines with the centers. The fully included small part will be found by the fact that it's extents (another bbox) are fully included in both coordinate sorting tests, so no further treatment of the bboxes is required but the rigorous geometry intersection is required. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb keyboard shortcuts (and usability in general)
- Stefan Tauner stefan.tau...@student.tuwien.ac.at wrote: i have finally fetched the source from git and rebuilt pcb. the most prominent new feature seems to be the polygon hole mode (which seems to create negative polygons inside polygons essentially). it has no keyboard shortcut assigned. since it is related to polygons i would suggest to assign some modifier (e.g. shift) + F6, what do you think? there was some discussing about adding tooltips with the shortcuts to the tool buttons in the new icon set... thread. are there any concrete plans to implement this? I have tooltips on my new icon set branch at home. I can make a patch with just the tooltips, if you'd like. shortcuts for enabling/disabling layers is documented, but seems to be broken for me. docs say: ‘ToggleVisibility(Layer)’ Toggles the visibility of the layer. Mod1Key1: ToggleVisibility(1) Mod1 is mapped to alt in gnome afaik, so this should be alt+1? also the command itself does not work if entered via die command line: unknown action `ToggleVisibility'. I have tried enabling the shortcut for this. There is a strange problem with Gtk such that if you toggle the visibility of the currently selected layer, the visibility is not toggled. I hunted after the bug for a few days but didn't get anywhere. So right now in the code there is no keyboard shortcut for this. This problem prompted me to suggest redoing the layer selector entirely to clean up the code, which in turn spawned the workspace/functional block discussion. also i am missing default shortcuts for some things i do _all_ the time while working with pcb: toggling settings/orthogonal moves toggling settings/crosshair snaps to pins and pads toggling settings/autoenforce DRC clearance opening menus (this is alt+some_char_from_the_menu_name in all* pc applications (*all but finitely many ;) why not in pcb?) saving (ok its possible to do this vi-style (:wenter), but assigning ctrl+s would not hurt anyone?) ... I've also done this, but if you take it to its logical conclusion, you should also add Ctrl+O for open, Ctrl+Z/Y for undo/redo, Ctrl+N for new, Ctrl+P for print, Ctrl+A for 'select all', etc. In the end I had to displace a number of existing shortcuts, a move that I didn't expect would be popular among long-term users of the program. Also, I wanted to eventually add the ability to customize shortcuts, which would override my changes anyway. and there are so many (useful) commands, that are not visible in the gui at all, like the recently added FreeRotateBuffer(). e.g. MorphPolygon or ChangeClearSize(SelectedPins|SelectedVias, ...). maybe including every command would clutter the menus too much, but having a list of all commands similar to the shortcut list at hand without the manual would be useful imho. This is a known issue. It comes down to UI design is hard :) if you want to take a crack at it, go for it. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: DRC rule structure
Stefan Salewski wrote: On Mon, 2010-08-16 at 06:12 -0700, Andrew Poelstra wrote: 1. I would have to create bounding boxes for every object on the screen, because you never know if some weird part 10 inches away has a 10-inch clearance requirement. Guess: Make bounding boxes which includes the clearance for each, so all not overlapping boxes fulfill desired clearance? for this subtest, exactly ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb keyboard shortcuts (and usability in general)
Andrew Poelstra wrote: This problem prompted me to suggest redoing the layer selector entirely to clean up the code, which in turn spawned the workspace/functional block discussion. Since you want to do away with the radio buttons left of the layers for activating I suppose you want use left-click for activate (like Kai-Martin every 10th attempt I inadvertently do this anyway). A means to switch visibility must be found: once a right-click popup is assigned to the layer buttons, this would just be one of the properties, until then, how about using right-click or middle-click? Thinking of a way to display the extent of vias (for burried vias) a bar left of the layers showing a bronze color strip connecting the start and end layer makes sense to me. It's similiar to a scrollbar but in reality could consist of simple boxes with changing background color. The active layer could be shown with the corresponding button depressed. Cycling through visibility states can change the button background color: normal ... visible, full saturation darkish grey + bright text . greyed out very dark + bright text .. invisible Getting caught by a fixed start and end layer for vias while routing on a different layer not in that range, it's probably practical to have a setting 'via starts at current layer' - using it may be a tradeoff between manufacturing cost and ease of routing. ( what happens if I want via_1 from layer 2-4 and via_2 from layer 3-5? ok, via_1 probably starts as blind while glueing layer 2,3,4 , 1st metalization, then glueing layer 5 makes via_1 burried, 2nd metalization connects layer 5 with layer 3,4 on via_2 - with multiple drilling, sounds expensive ;-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: DRC rule structure
At 09:12 AM 8/16/2010, you wrote: On Mon, Aug 16, 2010 at 02:56:17PM +0200, Armin Faltl wrote: Actually, I don't think that's true: Suppose I have a trace whose clearance is set to 2.5mm - if I lay any component too close while the real-time DRC is running, how can it know that it's breaking a rule without re-checking the clearance for every object on the PCB? By checking exactly the object you are currently trying to place against the traces in vicinity, that can be found by bounding-box intersection. There are two problems with this: 1. I would have to create bounding boxes for every object on the screen, because you never know if some weird part 10 inches away has a 10-inch clearance requirement. 2. Small parts, like vias, are able to be completely contained within the bounding box - so checking for intersections won't help me. I'm not sure I follow. I was thinking of this when I saw your first post. This is a similar problem to displaying graphics using 3D information. I have seen a speed up method for that which uses the extra memory that typically is left over from working with three dimensions, in essence a fourth dimension. They precompute an approximate Z position (relative to the eye) which they use to quickly scan the data to see which planes to display first which are most likely to be partially or fully overwritten. In your case, for each feature (your own definition of feature which works optimally) a working radius is computed which includes the furthest extent of the feature from it's origin plus what ever clearance is needed. All features are checked against one another still, but now it is just a matter of comparing origins against the working radii which is a much faster operation than checking each feature in detail (even a bounding box). Only the features that fail this test are then checked in detail, greatly speeding up the operation. Yes, you need to precompute the working radius of each feature on the board and store it, so that you only do this once and save that computing time for each display update. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb keyboard shortcuts (and usability in general)
Hi all, -Original Message- From: geda-user-boun...@moria.seul.org [mailto:geda-user-boun...@moria.seul.org] On Behalf Of Armin Faltl Sent: Monday, August 16, 2010 5:16 PM To: gEDA user mailing list Subject: Re: gEDA-user: pcb keyboard shortcuts (and usability in general) Andrew Poelstra wrote: This problem prompted me to suggest redoing the layer selector entirely to clean up the code, which in turn spawned the workspace/functional block discussion. Since you want to do away with the radio buttons left of the layers for activating I suppose you want use left-click for activate (like Kai-Martin every 10th attempt I inadvertently do this anyway). A means to switch visibility must be found: once a right-click popup is assigned to the layer buttons, this would just be one of the properties, until then, how about using right-click or middle-click? Thinking of a way to display the extent of vias (for burried vias) a bar left of the layers showing a bronze color strip connecting the start and end layer makes sense to me. It's similiar to a scrollbar but in reality could consist of simple boxes with changing background color. The active layer could be shown with the corresponding button depressed. Cycling through visibility states can change the button background color: normal ... visible, full saturation darkish grey + bright text . greyed out very dark + bright text .. invisible Getting caught by a fixed start and end layer for vias while routing on a different layer not in that range, it's probably practical to have a setting 'via starts at current layer' - using it may be a tradeoff between manufacturing cost and ease of routing. ( what happens if I want via_1 from layer 2-4 and via_2 from layer 3-5? ok, via_1 probably starts as blind while glueing layer 2,3,4 , 1st metalization, then glueing layer 5 makes via_1 burried, 2nd metalization connects layer 5 with layer 3,4 on via_2 - with multiple drilling, sounds expensive ;-) Maybe a single button would do to open a popup dialog to alter layer settings. Maybe something like this screenshot from AutoCAD: http://www.xs4all.nl/~ljh4timm/downloads/Layer_properties_manager.jpg Just the 5 left columns and the right most would do the trick. Regards, Bert Timmerman. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb keyboard shortcuts (and usability in general)
- Armin Faltl armin.fa...@aon.at wrote: Andrew Poelstra wrote: This problem prompted me to suggest redoing the layer selector entirely to clean up the code, which in turn spawned the workspace/functional block discussion. Since you want to do away with the radio buttons left of the layers for activating I suppose you want use left-click for activate (like Kai-Martin every 10th attempt I inadvertently do this anyway). A means to switch visibility must be found: once a right-click popup is assigned to the layer buttons, this would just be one of the properties, until then, how about using right-click or middle-click? I wanted to copy the GIMP: show icons for visibility/locking as part of the list item, that can be toggled independently of visibility. Right- clicking should pop up a full context menu for creating/editing/deleting layers, geometric transforms, duplicating, etc. As for buried vias, I don't think they should be related to the layer selector at all. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: DRC rule structure
Andrew Poelstra wrote: Clearance would be set for each component created or moved, as well as the components nearby it (still working on the details ;). I think you will find good working code doing clearances in pcb. Somewhere in there... John Griessen ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Subnets
Stephan Boettcher wrote: John Griessen j...@ecosensory.com writes: net attribs plus layout zones get us far on the way to autorouting success. If there is work put into partitioning a layout, can't we please have hierarchical layout instead? They are independent enough that it's not a choice of either or. Both are possible. JG ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
Armin Faltl wrote: My very little experience with autorouters also makes me believe, that an autorouter has even less understanding of EMI issues than I have ;-) Sure, that's why I made the analogy to Rainman. Routers are autistic. Have to be told what to do with many attribs and usually with some hand routing of fanouts done first. JG ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: DRC rule structure
- Rick Collins gnuarm.2...@arius.com wrote: At 09:12 AM 8/16/2010, you wrote: I'm not sure I follow. I was thinking of this when I saw your first post. This is a similar problem to displaying graphics using 3D information. I have seen a speed up method for that which uses the extra memory that typically is left over from working with three dimensions, in essence a fourth dimension. They precompute an approximate Z position (relative to the eye) which they use to quickly scan the data to see which planes to display first which are most likely to be partially or fully overwritten. In your case, for each feature (your own definition of feature which works optimally) a working radius is computed which includes the furthest extent of the feature from it's origin plus what ever clearance is needed. All features are checked against one another still, but now it is just a matter of comparing origins against the working radii which is a much faster operation than checking each feature in detail (even a bounding box). Only the features that fail this test are then checked in detail, greatly speeding up the operation. Yes, you need to precompute the working radius of each feature on the board and store it, so that you only do this once and save that computing time for each display update. I like this. Since many features on a PCB are traces, which are long and thin, I wonder if we could achieve an even-greater speedup by using bounding ellipses rather than circles. With rounded-up sine tables I think we can do the check nearly as fast as we could with simple circles (will have to check my calc book), and we'd eliminate a -lot- more components in the initial scan. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb keyboard shortcuts (and usability in general)
Andrew Poelstra wrote: I wanted to copy the GIMP: show icons for visibility/locking as part of the list item, that can be toggled independently of visibility. Right- clicking should pop up a full context menu for creating/editing/deleting layers, geometric transforms, duplicating, etc. As for buried vias, I don't think they should be related to the layer selector at all. I don't like the layer menu of GIMP - it's detached, so I always have to fetch it from below 5 other things before I can use it. If you don't detach it, it's still very wide. I just don't like it. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
Andrew Poelstra wrote: No, that's pretty much it. There are two things I want beyond simply workspaces to hold different tool settings for different functional groups: 1. You can create a view based on anything, not just functional groups, as will be the default. This includes opening components in their own view and editing them, or saving views as components. 2. Functional groups give one more structure to attach DRC rules to, between individual components and the entire PCB. This sounds great! If you save a view as a component, it would be good to have an optional way to backannotate a symbol for it into the schematic. Are you thinking that way? To save a view as a component with pins and busses attached just like a normal component that came from a footprint? John Griessen ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb keyboard shortcuts (and usability in general)
- Armin Faltl armin.fa...@aon.at wrote: Andrew Poelstra wrote: I wanted to copy the GIMP: show icons for visibility/locking as part of the list item, that can be toggled independently of visibility. Right- clicking should pop up a full context menu for creating/editing/deleting layers, geometric transforms, duplicating, etc. As for buried vias, I don't think they should be related to the layer selector at all. I don't like the layer menu of GIMP - it's detached, so I always have to fetch it from below 5 other things before I can use it. If you don't detach it, it's still very wide. I just don't like it. There's no good reason for it to be wide - they just like to have giant clickable areas, presumably for usability's sake. Why, then, did they detach it..? I dunno. We could fit the same functionality into the same space as the current layer switcher. (Or, if we used more vertical space below the layer name, we could also add trace/via width info alongside the visibility button.) Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
- John Griessen j...@ecosensory.com wrote: Andrew Poelstra wrote: No, that's pretty much it. There are two things I want beyond simply workspaces to hold different tool settings for different functional groups: 1. You can create a view based on anything, not just functional groups, as will be the default. This includes opening components in their own view and editing them, or saving views as components. 2. Functional groups give one more structure to attach DRC rules to, between individual components and the entire PCB. This sounds great! If you save a view as a component, it would be good to have an optional way to backannotate a symbol for it into the schematic. Are you thinking that way? To save a view as a component with pins and busses attached just like a normal component that came from a footprint? My thinking was to have a flag set for views editing components - which would do things like disable all layers except silk/pins/component, change the Save group to save .fp files instead of .pcb files, etc. That's a secondary plan, of course. Initially I'll just throw a export view as footprint button somewhere, while we work out the details of how views and functional blocks should work. When you click the new button beside the view tabs, you'll get a popup asking if you want to create a: o New functional block o New component (footprint) o Custom view Wherein custom view would allow you to create a filter range as per my DRC rule proposal. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
Rick Collins wrote: Why not start with what you are trying to do in the layout, consider what the layout tool needs to make that happen, then trace that back to what is needed in the schematic to support the layout? There are lots of different users of these programs, and they have different goals. You're not going to show up and get your way in a FOSS development community unless your suggestion is obvious and brilliant at the same time. IOW slim and none. When would you want a layout to control impedance on a portion of a net and not the entire net? Who knows? Volunteers making a tool do nothing but your special cases is not going to happen. Volunteers making a tool for controlling impedances when and where told to has a chance of happening. JG ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
Andrew Poelstra wrote: When you click the new button beside the view tabs, you'll get a popup asking if you want to create a: o New functional block o New component (footprint) o Custom view So are you thinking of reusing the layout editor to edit the footprint view? Then we could create pins or pads to get a new footprint with existing footprints inside it. The netlister would need to handle footprints with no package similarly as we handle flattened hierarchy now. Probably you're thinking of saving to the buffer and convert to footprint. the buffer method only allows one level I think, no component within component. I'd be happy to have a simple no hierarchy layout group with no new pads or pins added that is savable. Then no netlister changes would be needed, the group could be handled by flattened hierarchy naming if you wanted to put down repeated instances of it. John Griessen -- Ecosensory Austin TX ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb keyboard shortcuts (and usability in general)
Andrew Poelstra wrote: Really? I had been recompiling every time I changed that file :-}. Yes, it works without recompiling. A restart may be needed. PCB still has not got much interprocess communication going on... some with dbus maybe... Are you going to put your code up on a git repository for testing? I'll make some time to test. JG ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
You're not going to show up and get your way in a FOSS development community unless your suggestion is obvious and brilliant at the same time. or if you're willing to do the work yourself, of course :-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb: experience with import-schematics
lib-contents-command = /bin/true What is this command supposed to do? The default is the command to provide the M4 library contents. Without the contents list, there is no M4 library. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb keyboard shortcuts (and usability in general)
- John Griessen j...@ecosensory.com wrote: Andrew Poelstra wrote: Really? I had been recompiling every time I changed that file :-}. Yes, it works without recompiling. A restart may be needed. PCB still has not got much interprocess communication going on... some with dbus maybe... Are you going to put your code up on a git repository for testing? I'll make some time to test. Yep, when I've got testable code ;) Gtk has a few tricks up its sleeve to trip up newbies to GUI development. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb keyboard shortcuts (and usability in general)
is that all deliberately not included in the gui or would you accept patches? is there any written masterplan for (gui) enhancements? is there interest to debate reorganizing the current menu system + (re)assigning shortcuts at large? None of PCB's shortcomings are deliberate; we just don't have a lot of manpower to actually do things. Check out the GUI section of: http://geda.seul.org/wiki/geda:pcb_funding_sow ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb keyboard shortcuts (and usability in general)
I also like the GIMP's way of doing things - big button is select/activate, side buttons for visibility/lock/whatever. To save space, perhaps the big buttons could be only partially shown, as if they were hidden behind the PCB? When you hover over them, they'd move to the front so you can see the whole name... ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
John Griessen wrote: Rick Collins wrote: Why not start with what you are trying to do in the layout, consider what the layout tool needs to make that happen, then trace that back to what is needed in the schematic to support the layout? There are lots of different users of these programs, and they have different goals. You're not going to show up and get your way in a FOSS development community unless your suggestion is obvious and brilliant at the same time. IOW slim and none. JG, in my opinion Rick has a point, that without 100% clear definitions from and for all of those talking here using subnet, the whole discussion has a high chance of getting nowhere and some of the usecases brought in for support of the idea seem to come from Wolkenkuckusheim [1] for him. He's never been insulting and I value the practical view of his writing. As he's less writing, he's probably more routing than me - a reproach I'm making to myself - I just write here, to keep the future tool useful to me and found it hard to follow all the discussion. [1] the term is german and some of the ideas look like from there for me (too) e.g. I make my traces as broad as I see fit or have space in the area, so all the cool design auto blahblah means nothing to me, but a minimum clearance based on voltage is a good feature. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
- John Griessen j...@ecosensory.com wrote: Andrew Poelstra wrote: When you click the new button beside the view tabs, you'll get a popup asking if you want to create a: o New functional block o New component (footprint) o Custom view So are you thinking of reusing the layout editor to edit the footprint view? No, there will be a new new button beside the tabs, like in Firefox. Clicking that will popup the dialog. Then we could create pins or pads to get a new footprint with existing footprints inside it. The netlister would need to handle footprints with no package similarly as we handle flattened hierarchy now. You could create a footprint out of other footprints, but it would probably need to be flattened when saving out. Probably you're thinking of saving to the buffer and convert to footprint. the buffer method only allows one level I think, no component within component. Exactly. I'd be happy to have a simple no hierarchy layout group with no new pads or pins added that is savable. Then no netlister changes would be needed, the group could be handled by flattened hierarchy naming if you wanted to put down repeated instances of it. Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb keyboard shortcuts (and usability in general)
DJ Delorie wrote: I also like the GIMP's way of doing things Gimp is good by me. I also like the UI of inkscape. From this: http://wiki.inkscape.org/wiki/index.php/Class_Inkscape::UI::Widget::ProgressPannel it looks like c++ code and not sure what toolkit. If you have an easy way to install inkscape and play with it, it's got good GUI for examples. JG ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
On Mon, 2010-08-16 at 12:00 -0400, Rick Collins wrote: I think we should try to find a better name for the connection between two nodes in a net, maybe segment? In the layout program I use, a segment is a single section of a PWB route between two points. That is, it is the shortest specified portion of a route. The entire connected entity is a net and a connection between two pins or a T vertex is a trace. The trace is equivalent to what you are trying to describe. True, segment was a bad propose from me. I am not sure if trace is really good, in my mind trace is bound to a special shape... Maybe we should simple say connection between two points/pins/nodes. (I still wonder about the term PWB, a google search does not really help.) A lot of the discussion in this list is conducted as if the functioning of schematics were the only consideration. Why not start with what you are trying to do in the layout, consider what the layout tool needs to make that happen, then trace that back to what is needed in the schematic to support the layout? Indeed, that is what I would do, if I would be alone... Please note, I was not the one who has the idea of specifying attributes on the schematic level. This discussion is really old, at least it existed when Anthony Blake starts with his topological router and we consider how to make that router more smart. And as Kai-Martin told us, this concept is in Protel for ten years. So it is not an idea at all, it is an concept, and the question is, how useful it is. I wrote that down, with a small picture, because my memory is not too good... The whole story started this time with ideas of Andrew Poelstra, and it may start again in a few months... So much of this conversation just seems so disconnected from what might be needed to do real work. This is true -- from time to time we have discussions from new users with great ideas and wishes, but without the skills and time to program that. Sometimes I am one of them. If you want to consider impedance, then lets start with the ways you would want to control impedance and figure out just what that demands of layout and then the schematic? Normally when I am controlling impedance, I am using point to point connections with no branches or stubs. Sure, this is the general and most important case. But if they are kept short, a stub can be used with impedance controlled nets. Likewise, I seldom have more than one receiver on an impedance controlled nets, but I can see where a bus might need to be impedance controlled even with many drivers and receivers. So it seems like in layout you would need impedance on an entire net, not just a trace or subnet. When would you want a layout to control impedance on a portion of a net and not the entire net? Rick I do not really like to discuss all that details now. When we build a new house, it is difficult to predict the final color of the inner rooms. Indeed I think that a net with defined impedance should define that impedance to the whole net, no need for subnets. But I may be wrong. One special case is the example which I mentioned yesterday, when we want to enforce a special shape of a net in the schematic level. But for power supply nets, different attributes for different traces of a net makes sense, and most devices need power supply. Best regards, Stefan Salewski ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: DRC rule structure
Andrew Poelstra wrote: I like this. Since many features on a PCB are traces, which are long and thin, I wonder if we could achieve an even-greater speedup by using bounding ellipses rather than circles. With rounded-up sine tables I think we can do the check nearly as fast as we could with simple circles (will have to check my calc book), and we'd eliminate a -lot- more components in the initial scan. Bounding spheres and -circles are quite common. As DJ indicated pcb already has r-trees implemented (http://en.wikipedia.org/wiki/R-tree). Sorting bounding boxes by their edges and storing the result in 4 or 6 (3D) B+trees is another option. In that case you don't even have to look at most of the objects (O(log n)). An other option is quad trees (oct trees in 3D) that devide the space into non-overlapping segments and allow an object to be part of several nodes. Finding the smallest bounding box that is *not* axis-aligned is a hard problem in general (trivial for a set of 2 circles) with lots of approaches and literature. Finding the smallest ellipse, say with minimum area I think isn't trivial, even for 2 circles. Checking the intersection of circles is fast only, because it can be reduced to the distance of their centers. The best way I can immediately write to check ellipses will involve solving a quadratic equation - requires taking a square root. I'm not quite sure atm but for circles the distance can be squared and the root avoided. For just testing whether the solutions are complex, no actual root taking with quadratic equations is required either. Problem remains to find out when an ellipse is fully inside the other... Spheres have no natural easy way to compute the bounding sphere of aggregates from the spheres of components, therefore they are sometimes used with one of the trees above. This is not to discourage you, just meant as hints. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
Ok, if that is the way this group works. I have been told that these tools can be useful and I assumed that would be the goal of development. I see lot of comments going in all directions with no clear indication of how any of it would be used. But I'm just a practical sort of guy. If you guys are into the idea of what schematic software can be rather than the practical side of what is needed by the guys in the trenches, that's fine. It's your software. This is all new to me. I actually don't use the gEDA tools other than Gerbv which has some issues under Windows. I've used FreePCB and make my small contributions there. But there is only one developer and it is not clear that he wants help. So I can only make suggestions and not able to add to the code itself. I do provide peripheral support by advising newbies and help with the wiki at the moment. If there is anything I can help with here, I'm glad to do so. Have a nice one. Rick At 12:21 PM 8/16/2010, you wrote: Rick Collins wrote: Why not start with what you are trying to do in the layout, consider what the layout tool needs to make that happen, then trace that back to what is needed in the schematic to support the layout? There are lots of different users of these programs, and they have different goals. You're not going to show up and get your way in a FOSS development community unless your suggestion is obvious and brilliant at the same time. IOW slim and none. When would you want a layout to control impedance on a portion of a net and not the entire net? Who knows? Volunteers making a tool do nothing but your special cases is not going to happen. Volunteers making a tool for controlling impedances when and where told to has a chance of happening. JG ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
On Mon, 2010-08-16 at 18:54 +0200, Armin Faltl wrote: JG, in my opinion Rick has a point, that without 100% clear definitions from and for all of those talking here using subnet, the whole discussion has a high chance of getting nowhere This is true -- but the point is not 100% clear definitions but skills and time and will to work and code. Andrew Poelstra has shown at least some of the last mentioned. My fear was, that he moved in a wrong direction, because he is new to EDA and gEDA/PCB. And that he fast turns away from this project again -- without support by some motivating words. I myself -- I guess I will not find much time to learn the internals of gEDA/PCB in the next 12 months, sorry. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Subnets
Stefan Salewski m...@ssalewski.de writes: On Mon, 2010-08-16 at 10:09 +0200, Stephan Boettcher wrote: John Griessen j...@ecosensory.com writes: If there is work put into partitioning a layout, can't we please have hierarchical layout instead? I have still problems to understand the goals and benefits of partitioning hierarchical layout on PCB board level. Can you give an example, when possible with a picture? I usually have hierarchical schematics with multiple instances of the same subcircuits referenced from the main page. The deepest until now were three layers of hierarchy. All the cutting, sed-ing and pasting of the subcircuits to multiple instances, with replication of later changes on all copies is pretty unflexible. Hierarchical sub-cells (like with ASIC layouts) would allow to make and maintain such circuits much easier. What I am asking for here is, when you now talk about layout zones/partitions/whatever it's called in the end, please consider the application of the concept for this kind of hierarchy. Maybe the new concepts can be easily applied for that as well, with a little vision into that direction. Maybe it is trivial to allow multiple copies of a layout zone on a board, with a common netname/refdes prefix substituted on the copies. When you edit the layout of any copy, all instances follow the change. My eagle-using colleagues envy me for the hierarchical schematics that I can draw 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: Specification of Rotations for Auto Assembly
Hi, -Original Message- From: geda-user-boun...@moria.seul.org [mailto:geda-user-boun...@moria.seul.org] On Behalf Of Armin Faltl Sent: Monday, August 16, 2010 1:04 PM To: gEDA user mailing list Subject: Re: gEDA-user: Specification of Rotations for Auto Assembly Rick Collins wrote: This seems like a pretty sharp group. One of the problems I consistently have is generating an XYRS file for auto assembly of my boards. The X and Y require a specified origin and orientation of the board, which is done in the fab drawing. The side is pretty clear as well. But I always have trouble with the rotations. There are two sides and even if you pick a convention for the angle of origin and the direction of rotation, you still have to decide if the bottom side is viewed from the top or the bottom. When I have asked assembly houses about what they assume as convention, I never get an answer. They just tell me that they need the X and Y data along with the side. They basically figure out or at least verify the rotation data for themselves. Is that what you find? It just seems very odd that there is no accepted and widely used convention for rotations. I found info from IPC that says pin 1 in upper left corner is 0 degrees for ICs. But I've seen nothing that addresses how to spec the bottom side components. A FreePCB companion program. FpcPlace assumes all rotations are CCW and viewed from the top. But the footprint generator makes the footprint with pin 1 in the lower left which screws everything up, or so the FpcPlace developer says. It looks to me like the FpcPlace program is not correct. One of the things I dislike about pcb is the coordinate system: it's lefthanded, or z+ is going into the screen instead of pointing out. The right hand rule says: if you spread your first 3 fingers (starting with thumb) orthogonal to each other, thumb = X, point = Y, middle = Z ( or if you hook your fingers to indicate a rotation that will move X into Y, spreaded thumb poins to Z+). This is the basis for all math definition on vector operations in 2D and 3D, it defines the mathematically positive sense of rotation (CCW from above). All mechanical CAD systems and robotics controls adhere to this. So to define a rotation consistent with production, the first thing one must do is set up a proper 3D coordinate system. As long as the internal coordinate system of pcb is consistent within the code base, and the proper coordinate system is used for the exporter for each purpose, then why change and have the risk of implementing (new) errors. When it works, don't fix it. As a SCARA robot can only access one side of the board at a time, it's now a matter of convention, whether your designer procomputed rotation fixes the base coordinate system to the board (that gets flipped, so Z+ points up or down) or to the robot base. If I were to come up with a convention, I'd fix it to the board, since the actual placement of the board in the robot system (position and rotation) is unknow to the designer anyways. Next convention would be X is longer side, Y is short for rectangles. To define the complete position, one has to carry out 2 rotations (I know they can be combined to one oblique) for the backside: flip the board, then somehow rotate the chip. As the rotations can be combined, they can't be independent: you could flip the board around it's X-axis (makes most sense to designer) or it's Y-axis or around robot-X (what they fabs probably do) or around any other axis in the XY-plane, yielding completely different angles for the chip rotation. That's what the fabs actually tell you: if you believe the XY-plane to be in the center of the laminate, indicate which side is Z+. HTH, Armin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
At 12:57 PM 8/16/2010, you wrote: On Mon, 2010-08-16 at 12:00 -0400, Rick Collins wrote: I think we should try to find a better name for the connection between two nodes in a net, maybe segment? In the layout program I use, a segment is a single section of a PWB route between two points. That is, it is the shortest specified portion of a route. The entire connected entity is a net and a connection between two pins or a T vertex is a trace. The trace is equivalent to what you are trying to describe. True, segment was a bad propose from me. I am not sure if trace is really good, in my mind trace is bound to a special shape... Maybe we should simple say connection between two points/pins/nodes. (I still wonder about the term PWB, a google search does not really help.) PWB is Printed Wiring Board. I use PWB for the bare board because often PCB is used for an entire assembly with parts installed. In reality the two terms should mean the same thing, it is a matter of usage. The real problem is that people should call a circuit card assembly an assembly of some sort and not a PCB. Also, if you look up PCB you will find Polychlorinated Biphenyls which have nothing to do with circuit cards and are very undesirable... ;^) As to trace, there is still some advantage to using a term for a special meaning even if that special meaning is not what you first think of when you hear it. A lot of the discussion in this list is conducted as if the functioning of schematics were the only consideration. Why not start with what you are trying to do in the layout, consider what the layout tool needs to make that happen, then trace that back to what is needed in the schematic to support the layout? Indeed, that is what I would do, if I would be alone... Please note, I was not the one who has the idea of specifying attributes on the schematic level. This discussion is really old, at least it existed when Anthony Blake starts with his topological router and we consider how to make that router more smart. And as Kai-Martin told us, this concept is in Protel for ten years. So it is not an idea at all, it is an concept, and the question is, how useful it is. I wrote that down, with a small picture, because my memory is not too good... The whole story started this time with ideas of Andrew Poelstra, and it may start again in a few months... I think adding attributes to schematics is a good idea. But you need a way to convey that to the layout tool, what ever sort of tool that is, ASIC, FPGA, circuit card... No point in adding features to a schematic than can't be sent to or used by layout. So much of this conversation just seems so disconnected from what might be needed to do real work. This is true -- from time to time we have discussions from new users with great ideas and wishes, but without the skills and time to program that. Sometimes I am one of them. I guess I am not thinking that there is a problem with implementation. My concern is value. How are these ideas to be used by... well, the users? After all, this is the geda-user list, no? If getting the work done is the hardest part of it all, then maybe I can help... If you want to consider impedance, then lets start with the ways you would want to control impedance and figure out just what that demands of layout and then the schematic? Normally when I am controlling impedance, I am using point to point connections with no branches or stubs. Sure, this is the general and most important case. But if they are kept short, a stub can be used with impedance controlled nets. Likewise, I seldom have more than one receiver on an impedance controlled nets, but I can see where a bus might need to be impedance controlled even with many drivers and receivers. So it seems like in layout you would need impedance on an entire net, not just a trace or subnet. When would you want a layout to control impedance on a portion of a net and not the entire net? Rick I do not really like to discuss all that details now. When we build a new house, it is difficult to predict the final color of the inner rooms. Indeed I think that a net with defined impedance should define that impedance to the whole net, no need for subnets. But I may be wrong. One special case is the example which I mentioned yesterday, when we want to enforce a special shape of a net in the schematic level. But for power supply nets, different attributes for different traces of a net makes sense, and most devices need power supply. Wow! Impedance was being discussed in the context of it being a property of a trace rather than then entire net. I suggest that it be considered how impedance control is used on the circuit card (or chip or whatever) and you compare that to picking the color of a room when designing a house! I see it as figuring out where you want the rooms and doorways before you plan for the plumbing and electrical.
Re: gEDA-user: Subnets
Stephan Boettcher wrote: Stefan Salewski m...@ssalewski.de writes: On Mon, 2010-08-16 at 10:09 +0200, Stephan Boettcher wrote: John Griessen j...@ecosensory.com writes: If there is work put into partitioning a layout, can't we please have hierarchical layout instead? I have still problems to understand the goals and benefits of partitioning hierarchical layout on PCB board level. Can you give an example, when possible with a picture? I usually have hierarchical schematics with multiple instances of the same subcircuits referenced from the main page. The deepest until now were three layers of hierarchy. All the cutting, sed-ing and pasting of the subcircuits to multiple instances, with replication of later changes on all copies is pretty unflexible. Hierarchical sub-cells (like with ASIC layouts) would allow to make and maintain such circuits much easier. What I am asking for here is, when you now talk about layout zones/partitions/whatever it's called in the end, please consider the application of the concept for this kind of hierarchy. Maybe the new concepts can be easily applied for that as well, with a little vision into that direction. Maybe it is trivial to allow multiple copies of a layout zone on a board, with a common netname/refdes prefix substituted on the copies. When you edit the layout of any copy, all instances follow the change. Using blocks in mechanical CAD has some issues with this. In principle there are 2 ways to use a block: a) copy and paste b) reference Naturally the edit one modify all can only work with referencing. Sometimes in a single construction this is not desired, so when duplicating one has the choice between reference and copy. With mechanical constructions this goes as far as changing the appearance of a referenced block, when when an external block is changed independently. This can be useful, if the interface of the block is well understood. With pcb-layouts I strongly advise against this procedure: if a block gets inserted in a layout, a local copy has to be made (that is positioned nowhere) and references to this comprise the physical instances. Any attempt to modify a block with backpropagation to external data that is used in other boards will almost certainly break those layouts. When modifying a reference/instance of the (local) block one must get asked if opening the block is meant to change all instances or copy on write shall be used. About refdes-usage in this scenario: I find it hard to see an application of a block without using a corresponding sub-schematic. I would btw. like to be able to see only the basename of a refdes on the silk layer if it is made like schematic_name/schematic_local_identifier. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
- Stefan Salewski m...@ssalewski.de wrote: On Mon, 2010-08-16 at 18:54 +0200, Armin Faltl wrote: This is true -- but the point is not 100% clear definitions but skills and time and will to work and code. Andrew Poelstra has shown at least some of the last mentioned. My fear was, that he moved in a wrong direction, because he is new to EDA and gEDA/PCB. And that he fast turns away from this project again -- without support by some motivating words. I don't expect to move on anytime soon - though we will see how much time I have left when school starts again. Certainly, EDA is filled with exciting computing science problems, while being useful at the same time. Life is much harder if you can't hack the hardware around you :) Also, the gEDA codebase is certainly cleaner and more hackable than typical, and the list much more open-minded. As for going the wrong direction - if we don't ever explore, then how can we learn? Andrew ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Specification of Rotations for Auto Assembly
Bert Timmerman wrote: The right hand rule says: if you spread your first 3 fingers (starting with thumb) orthogonal to each other, thumb = X, point = Y, middle = Z ( or if you hook your fingers to indicate a rotation that will move X into Y, spreaded thumb poins to Z+). This is the basis for all math definition on vector operations in 2D and 3D, it defines the mathematically positive sense of rotation (CCW from above). All mechanical CAD systems and robotics controls adhere to this. I gave this explanation, why I don't like the CS. It's clear to me that changing it while simple in principle would make files not backwards compatible and is error prone. So to define a rotation consistent with production, the first thing one must do is set up a proper 3D coordinate system. As long as the internal coordinate system of pcb is consistent within the code base, and the proper coordinate system is used for the exporter for each purpose, then why change and have the risk of implementing (new) errors. When it works, don't fix it. Defining a proper 3D coorinate system is sufficient for export filters in conjunction with rotation. It wasn't necessarily meant to change the internal CS of pcb. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Subnets
On Mon, Aug 16, 2010 at 07:32:23PM +0200, Stephan Boettcher wrote: I usually have hierarchical schematics with multiple instances of the same subcircuits referenced from the main page. The deepest until now were three layers of hierarchy. I make do with two, but that's how I work also. All the cutting, sed-ing and pasting of the subcircuits to multiple instances, with replication of later changes on all copies is pretty unflexible. Agree 100%. Hierarchical sub-cells (like with ASIC layouts) would allow to make and maintain such circuits much easier. What I am asking for here is, when you now talk about layout zones/partitions/whatever it's called in the end, please consider the application of the concept for this kind of hierarchy. Maybe the new concepts can be easily applied for that as well, with a little vision into that direction. Maybe it is trivial to allow multiple copies of a layout zone on a board, with a common netname/refdes prefix substituted on the copies. When you edit the layout of any copy, all instances follow the change. I don't know about the trivial adjective, but I assert that's the goal, and would give me (and I suspect many others) a dramatic improvement in productivity and usability. The old get an electic circular saw after years of only using a hand saw analogy. My eagle-using colleagues envy me for the hierarchical schematics that I can draw in gschem. I do this in xcircuit, but at some point I may move to gschem. My biggest motivation, believe it or not, will be the better BOM support. - Larry ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
On Mon, 2010-08-16 at 13:55 -0400, Rick Collins wrote: I guess I am not thinking that there is a problem with implementation. My concern is value. How are these ideas to be used by... well, the users? After all, this is the geda-user list, no? If getting the work done is the hardest part of it all, then maybe I can help... Of course, my concern is value too. But what people regard as important is very different. Here in Germany most people related to electronics seems to give visible appearance a very high priority. I have seen many complaints about gEDA/PCB to be ugly. All what does not look like Windows7 or MacOSX is regarded ugly and unusable by that people. (Some Linux users now regard Gnome as ugly too...) So one may consider optical tuning of GUI most valuable? For the concept of defining attributes at the schematic level: You may know my DSO board. Doing that layout took me 500 hours of carefully work. That is OK. A smart layouter may need less time, maybe only 300 hours with PCB. I think that layouter will take 50 $ per hour, so I have to pay 15000 $. Or I have to do next layout again myself. But that layout will be more complicated, it will contain fast differential signal pairs and BGA footprints. Should be more than 500 hours for me. I think attributes can support my work, so I will need only 350 hours. Maybe much less with autorouter support. That would make me happy. Some of our users may want a nice shiny toy with a colorful GUI. That is OK, and may be useful for very small hobby projects. Some users may be more interested in better support of larger designs. Of course, transferring the attribute stuff from schematics to the PCB layout tool is difficult in many points: It concerns gschem, gnetlist and PCB. And we have to ensure that we do not break something and do it in a clean, professional way. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
I looked at your DSO project. That is pretty impressive. Are you looking for any help? That is right up my alley! Rick At 02:56 PM 8/16/2010, you wrote: On Mon, 2010-08-16 at 13:55 -0400, Rick Collins wrote: I guess I am not thinking that there is a problem with implementation. My concern is value. How are these ideas to be used by... well, the users? After all, this is the geda-user list, no? If getting the work done is the hardest part of it all, then maybe I can help... Of course, my concern is value too. But what people regard as important is very different. Here in Germany most people related to electronics seems to give visible appearance a very high priority. I have seen many complaints about gEDA/PCB to be ugly. All what does not look like Windows7 or MacOSX is regarded ugly and unusable by that people. (Some Linux users now regard Gnome as ugly too...) So one may consider optical tuning of GUI most valuable? For the concept of defining attributes at the schematic level: You may know my DSO board. Doing that layout took me 500 hours of carefully work. That is OK. A smart layouter may need less time, maybe only 300 hours with PCB. I think that layouter will take 50 $ per hour, so I have to pay 15000 $. Or I have to do next layout again myself. But that layout will be more complicated, it will contain fast differential signal pairs and BGA footprints. Should be more than 500 hours for me. I think attributes can support my work, so I will need only 350 hours. Maybe much less with autorouter support. That would make me happy. Some of our users may want a nice shiny toy with a colorful GUI. That is OK, and may be useful for very small hobby projects. Some users may be more interested in better support of larger designs. Of course, transferring the attribute stuff from schematics to the PCB layout tool is difficult in many points: It concerns gschem, gnetlist and PCB. And we have to ensure that we do not break something and do it in a clean, professional way. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: subnets
Using blocks in mechanical CAD has some issues with this. In principle there are 2 ways to use a block: a) copy and paste b) reference Naturally the edit one modify all can only work with referencing. Sometimes in a single construction this is not desired, so when duplicating one has the choice between reference and copy. With mechanical constructions this goes as far as changing the appearance of a referenced block, when when an external block is changed independently. This can be useful, if the interface of the block is well understood. Asic synthesis has a step called uniquification where you create a module and instantiate it multiple times. Uniquify will create a new module for each instance that can be modified independently from the others. You can also modify the master to change all the instances. It can get a little messy in that once you modify an instance then you can no longer touch the master or else all changes to the instance are lost. John Eaton ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
On Mon, 2010-08-16 at 15:27 -0400, Rick Collins wrote: I looked at your DSO project. That is pretty impressive. Are you looking for any help? That is right up my alley! Rick Indeed I was hoping for some support during the last two years, but there was not much interest, some people with very limited skills in electronics area contacted me, hoping for a very cheap device. But of course I can not build large quantities, so costs can not be smaller than similar commercial tools from china, so people are disappointed. I do understand that. No, currently I do not need help, I have done schematics and layout very carefully, learned VHDL, started design of a GTK GUI. And I wrote my own USB firmware some years ago. Currently I am doing some final checking of schematics and layout, with minimal modifications. I indent to order parts and two PCB prototype boards in harvest and intend soldering the first prototype before end of this year. If that prototype works, than there may be again room for support, for example for optimizing the VHDL code, board firmware and communication with the PC, and finally optimizing the user interface. I will tell on my homepage and on this list when there is the first working prototype -- hopefully before the end of this year. Best regards Stefan Salewski ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: subnets
Ouabache Designworks wrote: Asic synthesis has a step called uniquification where you create a module and instantiate it multiple times. Uniquify will create a new module for each instance that can be modified independently from the others. You can also modify the master to change all the instances. Just a use case note: Although I am far from asic projects I would would have loved to have such a feature in the quiver. The project required eleven identical subcircuits. They had to be connected differently, though. So, a simple copy-paste would not do. I addition, I don't like projects with deliberately broken netlists. There is a similar technique in vector graphics apps like inkscape, coreldraw and illustrator. They call it cloning. It can get a little messy in that once you modify an instance then you can no longer touch the master or else all changes to the instance are lost. Sometimes, this is actually a useful feature. No need to cycle over all instances if some via needs to be enlarged. ---)kaimartin(-- @Rick: Is this posting any different? -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
Stefan Salewski wrote: But what people regard as important is very different. Here in Germany most people related to electronics seems to give visible appearance a very high priority. On the other hand, the ugly duckling who calls itself eagle enjoys quite some user base in Germany. Bartels AutoEngineer is not exactly pure eye candy, either. ---)kaimartin(--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: wishful UI
Stefan Salewski wrote: I have to do next layout again myself. But that layout will be more complicated, it will contain fast differential signal pairs and BGA footprints. Should be more than 500 hours for me. I think attributes can support my work, so I will need only 350 hours. Maybe much less with autorouter support. That would make me happy. Tony's topo router is going to be good when we test it enough to handle existing layout and complete it. And we have to ensure that we do not break something and do it in a clean, professional way. Yes, we need a unit test with a topo router example to make sure it keeps on working as much as it does. John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Plain gschem net attribute/subnets test
Indeed, we can assign different attributes to lines in gschem 1.6.1,
when the lines connect at a 90 degree angle (for 180/360 degree angle
gschem tries to be smart and joins the lines to one).
So no modification of gschem is necessary for first evaluation of the
concept. We only have to extend gnetlist and PCB, maybe only PCB if we
use the new import schematic feature of PCB.
Yes, John Doty told us so, so this message is really unnecessary.
v 20100214 2
C 47000 48100 1 0 0 resistor-1.sym
{
T 47300 48500 5 10 0 0 0 0 1
device=RESISTOR
T 47200 48400 5 10 1 1 0 0 1
refdes=R1
}
C 45800 48100 1 0 0 resistor-1.sym
{
T 46100 48500 5 10 0 0 0 0 1
device=RESISTOR
T 46000 48400 5 10 1 1 0 0 1
refdes=R2
}
C 45800 47500 1 0 0 resistor-1.sym
{
T 46100 47900 5 10 0 0 0 0 1
device=RESISTOR
T 46000 47800 5 10 1 1 0 0 1
refdes=R3
}
N 46700 47600 46700 48200 4
{
T 46800 47900 5 10 1 0 0 0 1
netclass=fat_trace_R2R3
}
N 45800 47600 45800 49000 4
{
T 44600 47900 5 10 1 0 0 0 1
netclass=default
}
N 47000 48200 46700 48200 4
{
T 46700 48600 5 10 1 0 0 0 1
netclass=short
}
C 45800 48900 1 0 0 resistor-1.sym
{
T 46100 49300 5 10 0 0 0 0 1
device=RESISTOR
T 46000 49200 5 10 1 1 0 0 1
refdes=R4
}
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
