Re: gEDA-user: 200 bugs, warts and feature requests
On Sat, 2010-12-18 at 09:31 +0100, Martin Kupec wrote: I would dump it to a wiki page and point to that page from here. And probably file a bug pointing to that wiki. This way someone can slowly go through it. NAK.. One issue per bug please, or I will close it as invalid. (Otherwise it becomes very difficult to track progress in fixing issues). -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Hierarchy Refdes and Component Values
Kai-Martin Knaak wrote: If the symbol for the subcircuit has refdes X15, and it contains a component with refdes C42, the refdes in the flattened netlist created by gnetlist is X15/C42. Local nets within the subcircuits similarly get pathnames for their netnames. I don't like the slash, because it makes the component names extra long. So I put these lines in a local gnetlistrc: (hierarchy-uref-separator ) (hierarchy-netname-separator ) In addition, I set the refdes of the subsheet symbol to a single digit. That way, the refdeses stand a chance to be readable in in silk with a three layered hierarchy. How about emitting only the basename of a refdes on silk - if you got several instances of a circuit on a board, the component values should be identical anyway. With sloting of subcircuits this may be wrong, but then it would make sense to collaps the pathname of a subcircuit into one instance, that you can place to a group of components. In order to get this right, rat lines from the path to the base-refdeses could be used. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: 200 bugs, warts and feature requests
Kai-Martin Knaak wrote: PS: This is what the last couple of lines look like: /-- • pcb wart: rats don't print in the eps HID :-| • gschem room for improvement: If an autosave backup is found, the dialog should offer to show the diff of the two files. sounds quite difficult to implement - diff as ghost symbols ? • gschem usability improvement: If a symbol contains slots, insert should optionally add all slots at once with slot numbers automatically incremented. :-) • gschem usability: The add text dialog should automatically apply the current text when the mouse leaves the dialog. :-( if you don't need to click for placement, 99% of times the text will be elsewhere it's a funny idea, that you have to move the dialog for placement of the text • gschem usability: The add text dialog should contain widgets to set text attributes like size, color, orientation, :-)) • gschem usability: Accel to increment/decrement text size on [s]/[shift-s] similar to pcb :-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: 200 bugs, warts and feature requests
kai-martin knaak wrote: • gschem usability: The add text dialog should automatically apply the current text when the mouse leaves the dialog. :-( if you don't need to click for placement, 99% of times the text will be elsewhere I didn't mean to get rid of the apply-click. Just the click on the ok button. If the mouse leaves the dialog area, this should be treated as ok, I am done. Let me apply the current text Sure, the OK button is superfluous. The close button isn't - this raises the idea, that this dialog could have a semi-modal behaviour: if keyboard focus is left in (or rerouted to) the dialog, you can edit the text while placing with the mouse. Rerouting input from the main drawing window to a dialog requires context based swappable handlers, which is a good idea anyways (imo). ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Hierarchy Refdes and Component Values
Armin Faltl wrote: In addition, I set the refdes of the subsheet symbol to a single digit. That way, the refdeses stand a chance to be readable in in silk with a three layered hierarchy. How about emitting only the basename of a refdes on silk Then, I'd have no way to locate which schematic subsheet a particular R1 on the layout would correspond to. Of course, all refdeses might be guaranteed to be different like starting at R100 for one sub sheet and at R200 for the second. In that case, refdes mangling can be switched off whole sale in a local gnetlistrc: (hierarchy-uref-mangle disabled) ---)kaiamrtin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Hierarchy Refdes and Component Values
kai-martin knaak wrote: Armin Faltl wrote: In addition, I set the refdes of the subsheet symbol to a single digit. That way, the refdeses stand a chance to be readable in in silk with a three layered hierarchy. How about emitting only the basename of a refdes on silk Then, I'd have no way to locate which schematic subsheet a particular R1 on the layout would correspond to. forgot to post another idea: in the course of general GUI rework, rightclick on a component could bring up info on it, including the complete refdes, the footprint source, XYRS values, attached nets, some of that even editable, e.g. for precision placement of parts. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: get-package-attribute sometimes returns ? - ID: 3114991
John Doty wrote: Repeat after me: the library symbols are only starting points. Which is a pity and a major weakness of geda/pcb. Everybody has their own working style: the library cannot possibly cover everybody's. True. However it does not preclude the existence of a library that reasonably matches the needs of a large group of users. The other EDA packages I had the chance to work with, did a much better job at the library front. You could get quite far with their default library. My eagle oriented colleagues hardly dive into the symbol and/or footprint creation business. Hierarchy-Down Symbol Delete the offending attribute. File-Save As Hierarchy-Up Delete old symbol, add new in its place. Is that really so hard? A GUI oriented work-flow recommended by John D. (!) ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Hierarchy Refdes and Component Values
Armin Faltl wrote: rightclick on a component could bring up info on it, including the complete refdes, the footprint source, XYRS values, attached nets, some of that even editable, e.g. for precision placement of parts. yay, yay! In particular the last part of it. Position and rotation angle definitely should be editable via the keyboard. Right-click to get properties is a very common meme. ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: get-package-attribute sometimes returns ? - ID: 3114991
On Dec 19, 2010, at 6:38 AM, kai-martin knaak wrote: John Doty wrote: Repeat after me: the library symbols are only starting points. Which is a pity and a major weakness of geda/pcb. Have you used other tools? It's unavoidable for anything that can tackle a broad range of projects. gEDA isn't just for hobbyists, you know. Everybody has their own working style: the library cannot possibly cover everybody's. True. However it does not preclude the existence of a library that reasonably matches the needs of a large group of users. The other EDA packages I had the chance to work with, did a much better job at the library front. You could get quite far with their default library. My eagle oriented colleagues hardly dive into the symbol and/or footprint creation business. And they can't go all the places gEDA can go. There is nothing whatever preventing somebody from constructing a symbol library that matches *their* notion of a reasonable gEDA flow. Publish on gedasymbols. But I predict that such a person would get numerous complaints from users. All of the symbol complaints seem to come from people who want gEDA to follow a narrow path that is *obviously* to them the path that suits most users, but in fact would only suit a modest subset. I personally use gEDA for about six kinds of incompatible flow (overlapping categories, take with much salt). 1. Breadboard Stock symbols, nothing fancy. 2. Small scale printed circuit. Stock symbols, attach footprint names the layout person will recognize. 3. Large scale printed circuit. Largely project-specific heavy symbols. Footprints in symbols, not usually promoted or attached. Try to get layout contractor to tell me what footprint names they want. 4. SPICE simulation of circuits for printed circuit realization Stock symbols, attach the extra attributes. It is presently impractical to simulate schematics as drawn for printed circuit layout. If we could move the semantic processing out of the gnetlist front end, it would be possible to write a SPICE netlister that would work without requiring you to redraw such things. 5. Capture of circuit topology for symbolic analysis (-g mathematica). These are necessarily small circuits, so I mostly use stock symbols. 6. VLSI design Only a few of the stock symbols are useful here. I've published (on gedasymbols) a collection of symbols matching the OpenIP VLSI library. One nice thing though, is that at least for the layout flow my customer uses there is no conflict between the semantics of layout and the semantics of simulation, so the netlists I send for layout are verifiable in simulation. Hierarchy-Down Symbol Delete the offending attribute. File-Save As Hierarchy-Up Delete old symbol, add new in its place. Is that really so hard? A GUI oriented work-flow recommended by John D. (!) Well, in truth, I'm more likely to: locate whatever.sym cp the-selected-version-of-whathever.sym ProjectSymbols/whatnow.sym gschem ProjectSymbols/whatnow.sym Fix the symbol fs Before ever placing it. Often there's already a suitable version in some other project, no fix needed. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Hierarchy Refdes and Component Values
Rick Collins wrote: In addition, I set the refdes of the subsheet symbol to a single digit. That way, the refdeses stand a chance to be readable in in silk with a three layered hierarchy. How about emitting only the basename of a refdes on silk Then, I'd have no way to locate which schematic subsheet a particular R1 on the layout would correspond to. Of course, all refdeses might be guaranteed to be different like starting at R100 for one sub sheet and at R200 for the second. In that case, refdes mangling can be switched off whole sale in a local gnetlistrc: (hierarchy-uref-mangle disabled) Can you be sure this will work with all designs? Of course not. That's why I said, In that case Your approach would limit each subsheet to 100 of each type of component before name collisions happen. I can picture two ways of working around this. One is to instead append a numeral or other indicator to the beginning of a refdes, i.e. when on subsheet 3 a part might be 3R15. This is exactly, what I like to do in my hierarchical designs. (See the top of this post.) Of course this could be confused with a part value, i.e. 15R3. Not with pcb :-) Pcb prints either refdeses, or values but not both. The other is to have a feature in the schematic package to provide a unique number to each component. The subsheet instances would be processed in turn resulting in a unique number being assigned to each component in the design. We sort of have this in gschem already: The autonumber dialog contains the option to skip numbers found in whole hierarchy. This is not perfect, since it only looks at sub sheets but not at parent sheets. If I understand correctly how subsheets work, I can see where you might want to display to the user a given subsheet only once rather than separately each time the sheet is referenced. Not sure, if I understand what you are aiming at. One of my current projects involves a subcircuit that needs to be repeated 69 times. With subsheets I don't need to have 69 times the same schematic in the documentation. If I have to change some aspect of the subcircuit, I don't have to apply the change 69 times. So for this particular project the way geda treats subsheets is a real work saver. :-) Does it make sense to let the schematic package reassign ref des in multiple instances of a subsheet? IMHO, this is the job of gnetlist. On schematic level multiple instances should be exactly the same. That's why they are instances rather than copies. ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Hierarchy Refdes and Component Values
At 11:20 AM 12/19/2010, you wrote: Rick Collins wrote: If I understand correctly how subsheets work, I can see where you might want to display to the user a given subsheet only once rather than separately each time the sheet is referenced. Not sure, if I understand what you are aiming at. One of my current projects involves a subcircuit that needs to be repeated 69 times. With subsheets I don't need to have 69 times the same schematic in the documentation. If I have to change some aspect of the subcircuit, I don't have to apply the change 69 times. So for this particular project the way geda treats subsheets is a real work saver. :-) But it is a problem with documentation. You have one page in your schematic and each part has a ref des. In your example, on the board each part in the subsheet has 69 instances, all with unique ref des. If your ref des is hierarchical (subsheet/refdes), then the ref des tells you what instance of the sheet to consider. But if the tools generate new ref des that are not hierarchical, then you need to at least be able to view each subsheet separately, with each instance having its own ref des. This does not mean you have to edit 69 pages when you make a change. If the tool actually understands subsheets as hierarchy to be instanced, then it should allow you to edit the original subsheet once, but allow you to view it N times, each with the component ref des that will be used in layout. It may make it hard to figure out which subsheet instance to view in the schematic. With the hierarchical ref des it tells you which instance. With component renumbering you have to search to find the right sheet... the same as non-hierarchical schematics. Does it make sense to let the schematic package reassign ref des in multiple instances of a subsheet? IMHO, this is the job of gnetlist. On schematic level multiple instances should be exactly the same. That's why they are instances rather than copies. There is more than one way to view instantiation. You don't have to see it as the exact same, single sheet. If you do, there is no way to have your documentation in step with the actual board produced... The way you are viewing subsheets, they are macros and the schematic is a programming language. A schematic is intended to be documentation and each page has to show the ref des that appears on the final product. If you push this off to gnetlist, you no longer have a one to one correspondence between the schematic and the board. It just requires a smart schematic package that knows how to assign ref des. The only fly in the ointment is back annotation. It is common for layouts to dictate ref des based on location to allow finding parts easily. I guess there is no reason that back annotation should be hard, but in a hierarchical schematic it may require special attention. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Random thoughts on the future interface of PCB
On Wed, Dec 15, 2010 at 01:02:25AM +, Peter Clifton wrote: On Tue, 2010-12-14 at 22:57 +0100, Martin Kupec wrote: Sometimes, when you place to lines too close, but not that close in polygon. It will make thin line in the polygon connecting two part of the polygon. DRC will mark this line as too thin. Actually, I'm pretty sure the DRC will miss this error (unless the thin line was _required_ for some connectivity), - And even then I'm not 100% sure. It misses the error. I have found old bug describing this behaviour. It should automaticly erase such lines. Any proposal, how to fix this? It is quite a hard problem to solve actually.. I'll have a think about it... it really needs solving, and I've been looking at / thinking about polygons recently. You are probably the most qualified one :-). When you make a via in polygon. Change the clerance to too small value and add thermal(even full thermal). DRC will mark this via as having too smal clearance. This seems like bug to me. Sounds like ;) (I'll point you at a bug tracker to file it at some point, but we're probably going to move trackers pretty soon anyway, so you might have the honour of filing the first (new) bug in the new bug tracker if you wait a while!). I am trying to file a bug at launchpad.net. Bigger issues is that when I drag component, lines are dragged with it. This is fine, but the lines do not respect any orthogonal/45 deg rules. You can switch off rubber-band mode in the settings menu. More intelligent rubber-banding could be done in the future, but is not trivial to implement. I know that this is problematic. I can work with current state. I just pointed to all problems I had :-). I cannot simply unmask part of the board. I know how to do it, but that is not optimal. Having some Solder mask layer with polygons clearing solder mask would be neat. Future TODO item for when we re-work layer support in (some) future PCB version. I'd expect it will not happen any time soon. There is a patch on tracker(ID 2986641). It add few new layers and one of them is component_mask(and solder_mask). What do you think about that patch? It doesn't apply currently, but it can be a starting point. Martin Kupec ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Hierarchy Refdes and Component Values
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 19.12.2010 17:59, schrieb Rick Collins: At 11:20 AM 12/19/2010, you wrote: Rick Collins wrote: If I understand correctly how subsheets work, I can see where you might want to display to the user a given subsheet only once rather than separately each time the sheet is referenced. Not sure, if I understand what you are aiming at. One of my current projects involves a subcircuit that needs to be repeated 69 times. With subsheets I don't need to have 69 times the same schematic in the documentation. If I have to change some aspect of the subcircuit, I don't have to apply the change 69 times. So for this particular project the way geda treats subsheets is a real work saver. :-) But it is a problem with documentation. You have one page in your schematic and each part has a ref des. In your example, on the board each part in the subsheet has 69 instances, all with unique ref des. If your ref des is hierarchical (subsheet/refdes), then the ref des tells you what instance of the sheet to consider. But if the tools generate new ref des that are not hierarchical, then you need to at least be able to view each subsheet separately, with each instance having its own ref des. This does not mean you have to edit 69 pages when you make a change. If the tool actually understands subsheets as hierarchy to be instanced, then it should allow you to edit the original subsheet once, but allow you to view it N times, each with the component ref des that will be used in layout. It may make it hard to figure out which subsheet instance to view in the schematic. With the hierarchical ref des it tells you which instance. With component renumbering you have to search to find the right sheet... the same as non-hierarchical schematics. Does it make sense to let the schematic package reassign ref des in multiple instances of a subsheet? IMHO, this is the job of gnetlist. On schematic level multiple instances should be exactly the same. That's why they are instances rather than copies. There is more than one way to view instantiation. You don't have to see it as the exact same, single sheet. If you do, there is no way to have your documentation in step with the actual board produced... The way you are viewing subsheets, they are macros and the schematic is a programming language. A schematic is intended to be documentation and each page has to show the ref des that appears on the final product. If you push this off to gnetlist, you no longer have a one to one correspondence between the schematic and the board. It just requires a smart schematic package that knows how to assign ref des. The only fly in the ointment is back annotation. It is common for layouts to dictate ref des based on location to allow finding parts easily. I guess there is no reason that back annotation should be hard, but in a hierarchical schematic it may require special attention. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user Hi, let me add an order of complexity here: Assume you have a bandpass consitsting of 2 OPAMPS, 4 resistors and 2 caps that you want to use (instantiate) multiple times on your board. There are multiple instances of that bandpass having different values for the R's and the C's. In addition to this, you want to use quad opamps and share these between 2 instantiations of your bandpass. To me it looks that you need to pass parameters to any instantiation of that bandpass (=subcircuit, hierarchical circuit) including a slotting parameter (share circuit with instantion n-1)). So from my point of view if you create a hierarchy symbol you need to be able to 'attach' component values and slotting to it for each instance. (There may be hierarchy symbols not requiring that at all and symbols that have 'fixe value' components and variable components in a mix). - -- Mit freundlichen Gruessen Dietmar Schmunkamp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk0OrKoACgkQn22l+QvEah3TIACcCWPCYNPJ2h7t/p9PHfQNtUAk x/IAn3T2Vh3XTis08QsgZ+HX6nIgrMt6 =aq90 -END PGP SIGNATURE- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Hierarchy Refdes and Component Values
On Friday 17 December 2010, Thomas D. Dean wrote: I have a schematic with seven instances of a schematic, a hierarchy. I want to give different values to the resistors in each of the sub-circuits. For example, I have S1 thru S7. In S1, I want R1=100, in S2, I want R1=1k, etc. Is this possible with hierarchy? With Gnucap, just give the resistor value a name, and pass it in when you instantiate the subckt. .subckt thing (a b) R1 (a b) dv .ends X1 (1 2) thing dv=100 X2 (3 4) thing dv=1k It is better to let the simulator handle hierarchy. The netlister should NOT expand subckts. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: overlapping via changes
I changed the overlapping vias test in two ways... 1. Via copper is now allowed to overlap when vias are created. Via *drills* are not. 2. Vias which violate this rule in a *.pcb file are preserved at load time. Thus, PCB will make a modest attempt at preventing users from making vias that might be difficult to manufacture, but if the user finds a way around the restriction, PCB will let them get away with it. Simply moving an existing via is an adequate way around it. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
