Re: gEDA-user: gschem snap parameters?
Hi Kai-Martin, On Dienstag, 22. September 2009, Kai-Martin Knaak wrote: Sometimes, gschem nets shows an annoying tendency to snap to a not so near node. Is there a way to tune the distance at which the gschem net snaps? This is a hardcoded feature ;-) It's not possible to change this with configuration variables. Imagine the possible snapping objects for the nets are magnets. The magnet of the pin is stronger than the magnet of the bus or another net. The relative strength of the magnets is defined in the top section of gschem/src/o_net.c: --- /* weighting factors to tell that a pin is more important than a net */ #define MAGNETIC_PIN_WEIGHT 5.0 #define MAGNETIC_NET_WEIGHT 2.0 #define MAGNETIC_BUS_WEIGHT 3.0 If you like equal strenght, you have to set all WEIGHT constants to the same value. A second set of constants controls, how far away an object can be to activate the snapping: - /* define how far the cursor could be to activate magnetic */ #define MAGNETIC_PIN_REACH 50 #define MAGNETIC_NET_REACH 20 #define MAGNETIC_BUS_REACH 30 - Regards Werner ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem snap parameters?
- /* define how far the cursor could be to activate magnetic */ #define MAGNETIC_PIN_REACH 50 #define MAGNETIC_NET_REACH 20 #define MAGNETIC_BUS_REACH 30 What do the values actually mean? Is it 50 grid units, 50 pixels, 50 what? I've also experience some frustration with this feature, mainly when I want to route a net and one of the vertexes happens to be close to a magnetic point. Zooming in seems to help avoid the problem. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem snap parameters?
Hi Duncan, On Mittwoch, 23. September 2009, Duncan Drennan wrote: - /* define how far the cursor could be to activate magnetic */ #define MAGNETIC_PIN_REACH 50 #define MAGNETIC_NET_REACH 20 #define MAGNETIC_BUS_REACH 30 What do the values actually mean? Is it 50 grid units, 50 pixels, 50 what? Pixels. I've also experience some frustration with this feature, mainly when I want to route a net and one of the vertexes happens to be close to a magnetic point. Zooming in seems to help avoid the problem. Yes, when you zoom in you spread away the possible connection points. You can temporarly disable the magnetic net with the CTRL key. I guess that's what you need. And finally, you can easily switch the magnetic net feature ON/OFF in the options menu. (Toggle Magnetic Net / om) HTH, Regards Werner ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem snap parameters?
You can temporarly disable the magnetic net with the CTRL key. I guess that's what you need. Thanks! That does help :) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Error in DRC
Hi Tony, wr is not a valid pintype. Do you have any symbol with this attribute attached to a pin? Valid pintypes are: unknown in out io oc oe pas tp tri clk pwr unconnected Regards, Carlos El jue, 17-09-2009 a las 19:17 -0400, Tony Radice escribió: Ladies and Gentlemen - When attempting to run a drc on my heirarchical design, the drc routine crashes with the following error: Backtrace: In /usr/share/gEDA/scheme/gnet-drc2.scm: 601: 937 (if (not (null? net-conn)) (let* (# # # #) (begin #)) (list)) ... 608: 938 [cons pas ... 609: 939* [drc2:get-pintypes-of-net-connections (# # # # ...) ()] 601: 940 (if (not (null? net-conn)) (let* (# # # #) (begin #)) (list)) ... 608: 941 [cons pas ... 609: 942* [drc2:get-pintypes-of-net-connections (# # # # ...) ()] 601: 943(if (not (null? net-conn)) (let* (# # # #) (begin #)) (list)) ... 608: 944[cons pas ... 609: 945*[drc2:get-pintypes-of-net-connections (# # # # ...) ()] 601: 946 (if (not (null? net-conn)) (let* (# # # #) (begin #)) (list)) ... 608: 947 [cons pas ... 609: 948* [drc2:get-pintypes-of-net-connections (# # # # ...) ()] 601: 949 (if (not (null? net-conn)) (let* (# # # #) (begin #)) (list)) ... 608: 950 [cons pwr ... 609: 951* [drc2:get-pintypes-of-net-connections (# # # # ...) ()] 601: 952 (if (not (null? net-conn)) (let* (# # # #) (begin #)) (list)) 602: 953 (let* ((element #) (device #) (pin #) ...) (begin (cons pintype #))) 604: 954* [car ... 604: 955* [cdr ... 604: 956*(car net-conn) I am afraid I have absolutely NO IDEA what this is telling me. Would someone be kind enough to advise how to proceed? This is a repeatable error. The output of the drc file is: Checking non-numbered parts... Checking duplicated references... Checking nets with only one connection... ERROR: Net 'unnamed_net84' is connected to only one pin: SA4/R124:1 . ERROR: Net 'unnamed_net39' is connected to only one pin: SA5/U4:27 . Checking pins without the 'pintype' attribute... INTERNAL ERROR: unknown pin type : wr Again, thank you for your consideration. Tony Radice BTW: Machine is running Fedora 11, 2 G Mem. ___ 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
gEDA-user: Disappearing PCB Footprint details
Update: Ladies and Gentlemen - I experimented with the footprints I had developed in a unique directory (/home/comp/pwb_footprints) and had no success with seeing them in the pcb tool. As a point of interest: When I start the pcb tool this footprint library *directory* was identified, but the footprints themselves were not. This occurred even though I gave the directive --element-path to the pcb invocation. As an experiment, I created a local directory under /usr/share/pcb/newlib. I moved the footprints into this directory, changing the ownership to root with permissions of 644, and viola! - the footprints come up correctly WITH the silkscreen around them. SO, I will place all locally developed footprints into this directory. Comments and questions are invited. Tony Radice ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Error in DRC
Carlos - I honestly do not know - it may be a typo error on my part of a piece of pwr. I'll open the schematic file and scan for the wr. Thanks for the reply!! T. On Wed, 2009-09-23 at 21:43 +0200, Carlos Nieves Ónega wrote: Hi Tony, wr is not a valid pintype. Do you have any symbol with this attribute attached to a pin? Valid pintypes are: unknown in out io oc oe pas tp tri clk pwr unconnected Regards, Carlos El jue, 17-09-2009 a las 19:17 -0400, Tony Radice escribió: Ladies and Gentlemen - When attempting to run a drc on my heirarchical design, the drc routine crashes with the following error: Backtrace: In /usr/share/gEDA/scheme/gnet-drc2.scm: 601: 937 (if (not (null? net-conn)) (let* (# # # #) (begin #)) (list)) ... 608: 938 [cons pas ... 609: 939* [drc2:get-pintypes-of-net-connections (# # # # ...) ()] 601: 940 (if (not (null? net-conn)) (let* (# # # #) (begin #)) (list)) ... 608: 941 [cons pas ... 609: 942* [drc2:get-pintypes-of-net-connections (# # # # ...) ()] 601: 943(if (not (null? net-conn)) (let* (# # # #) (begin #)) (list)) ... 608: 944[cons pas ... 609: 945*[drc2:get-pintypes-of-net-connections (# # # # ...) ()] 601: 946 (if (not (null? net-conn)) (let* (# # # #) (begin #)) (list)) ... 608: 947 [cons pas ... 609: 948* [drc2:get-pintypes-of-net-connections (# # # # ...) ()] 601: 949 (if (not (null? net-conn)) (let* (# # # #) (begin #)) (list)) ... 608: 950 [cons pwr ... 609: 951* [drc2:get-pintypes-of-net-connections (# # # # ...) ()] 601: 952 (if (not (null? net-conn)) (let* (# # # #) (begin #)) (list)) 602: 953 (let* ((element #) (device #) (pin #) ...) (begin (cons pintype #))) 604: 954* [car ... 604: 955* [cdr ... 604: 956*(car net-conn) I am afraid I have absolutely NO IDEA what this is telling me. Would someone be kind enough to advise how to proceed? This is a repeatable error. The output of the drc file is: Checking non-numbered parts... Checking duplicated references... Checking nets with only one connection... ERROR: Net 'unnamed_net84' is connected to only one pin: SA4/R124:1 . ERROR: Net 'unnamed_net39' is connected to only one pin: SA5/U4:27 . Checking pins without the 'pintype' attribute... INTERNAL ERROR: unknown pin type : wr Again, thank you for your consideration. Tony Radice BTW: Machine is running Fedora 11, 2 G Mem. ___ 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: Disappearing PCB Footprint details
On Wed, 2009-09-23 at 15:10 -0400, Tony Radice wrote: Update: Ladies and Gentlemen - I experimented with the footprints I had developed in a unique directory (/home/comp/pwb_footprints) and had no success with seeing them in the pcb tool. I think most people use gschem2pcb script to populate the pcb board. To investigate a footprint you may try Menu Files/Load Element data to paste buffer. Or you may try menu Files/Preferences to select additional directories of footprints. I newer tried this last method, but it should work. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: device attribute in master attribute list
On Tue, 2009-09-22 at 12:35 +, Kai-Martin Knaak wrote: Cite from the master attribute list: /-- device= is the device name of the symbol and is required by gnetlist. \-- However, I forgot the device attribute in some of my symbols and gnetlist did not seem to care at all. Netlist generation was just fine. What is the purpose of the device attribute? Should the master attribute list be adjusted to reflect that the device attribute is not really required? Or should gnetlist be patched to issue an error on omission? /-- Generally the device name is in all caps. \-- What is the penalty if a device attribute does not meet this requirement? ---(kaimartin)--- I really think that we need a more precise definition of attributes. And we should have some master symbols which include all necessary attributes used in the correct way, so that user can uses these as examples. The problem seems to be that nobody knows. I can remember a discussion about the graphical attribute -- it was not clear if io symbols should include this. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: sym files sorting
On Tue, 2009-09-22 at 14:34 +, Kai-Martin Knaak wrote: The gschem gui seems to append new items to the bottom of the file. As a consequence, symbols done with the GUI are a pain to edit in a text editor. Pins mix with comments and attributes in no particular order. It would be nice, if the internals were sorted by type, by value, and/or by position. Did anyone write a script to sort the internals of a sym file? ---(kaimartin)--- I think there was a Python script called nice-sym from Werner Hoch. I tried it, but it transfered nice tragesym 1.5.x generated symbols back to old 1.4.x shape. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Error in DRC
Carlos - Thanks for the reply. I corrected the part that had the wr attribute - I did indeed mistype pwr. That was the good news - The bad news: I still get the stack overflow error below, and now the output of the .drc file is: Checking non-numbered parts... Checking duplicated references... And that's it. Any other hints to throw out? Thanks again! Tony On Wed, 2009-09-23 at 21:43 +0200, Carlos Nieves Ónega wrote: Hi Tony, wr is not a valid pintype. Do you have any symbol with this attribute attached to a pin? Valid pintypes are: unknown in out io oc oe pas tp tri clk pwr unconnected Regards, Carlos El jue, 17-09-2009 a las 19:17 -0400, Tony Radice escribió: Ladies and Gentlemen - When attempting to run a drc on my heirarchical design, the drc routine crashes with the following error: Backtrace: In /usr/share/gEDA/scheme/gnet-drc2.scm: 601: 937 (if (not (null? net-conn)) (let* (# # # #) (begin #)) (list)) ... 608: 938 [cons pas ... 609: 939* [drc2:get-pintypes-of-net-connections (# # # # ...) ()] 601: 940 (if (not (null? net-conn)) (let* (# # # #) (begin #)) (list)) ... 608: 941 [cons pas ... 609: 942* [drc2:get-pintypes-of-net-connections (# # # # ...) ()] 601: 943(if (not (null? net-conn)) (let* (# # # #) (begin #)) (list)) ... 608: 944[cons pas ... 609: 945*[drc2:get-pintypes-of-net-connections (# # # # ...) ()] 601: 946 (if (not (null? net-conn)) (let* (# # # #) (begin #)) (list)) ... 608: 947 [cons pas ... 609: 948* [drc2:get-pintypes-of-net-connections (# # # # ...) ()] 601: 949 (if (not (null? net-conn)) (let* (# # # #) (begin #)) (list)) ... 608: 950 [cons pwr ... 609: 951* [drc2:get-pintypes-of-net-connections (# # # # ...) ()] 601: 952 (if (not (null? net-conn)) (let* (# # # #) (begin #)) (list)) 602: 953 (let* ((element #) (device #) (pin #) ...) (begin (cons pintype #))) 604: 954* [car ... 604: 955* [cdr ... 604: 956*(car net-conn) I am afraid I have absolutely NO IDEA what this is telling me. Would someone be kind enough to advise how to proceed? This is a repeatable error. The output of the drc file is: Checking non-numbered parts... Checking duplicated references... Checking nets with only one connection... ERROR: Net 'unnamed_net84' is connected to only one pin: SA4/R124:1 . ERROR: Net 'unnamed_net39' is connected to only one pin: SA5/U4:27 . Checking pins without the 'pintype' attribute... INTERNAL ERROR: unknown pin type : wr Again, thank you for your consideration. Tony Radice BTW: Machine is running Fedora 11, 2 G Mem. ___ 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
gEDA-user: Exploding BOM
Ladies and Gents - Looks like I may not hit every error possible, but I'm gonna give it my best shot at as many as possible... Latest dilemma: When I issue the netlist command with the argument -g bom, I get a valid bom. When I issue the netlist command with ANY other form of the argument, I get a stack overflow. This is a two-layer heirarchical design - one block layer and nine completely independent blocks in the second layer. The drc fails - again, a stack overflow with no indication why. Hints are greatly appreciated - my next step is to try a different netlist routine. (Anthony Shanks) Cheers! Tony ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Exploding BOM
Try http://archives.seul.org/geda/user/Feb-2008/msg00277.html ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Exploding BOM
DJ - Added the (debug-options (list 'stack 20)) command to my system-gafrc file. Worked like a charm!! THANK YOU!!! Tony On Wed, 2009-09-23 at 21:12 -0400, DJ Delorie wrote: Try http://archives.seul.org/geda/user/Feb-2008/msg00277.html ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Disappearing PCB Footprint details
Stefan Salewski wrote: On Wed, 2009-09-23 at 15:10 -0400, Tony Radice wrote: Update: Ladies and Gentlemen - I experimented with the footprints I had developed in a unique directory (/home/comp/pwb_footprints) and had no success with seeing them in the pcb tool. I think most people use gschem2pcb script to populate the pcb board. To investigate a footprint you may try Menu Files/Load Element data to paste buffer. Or you may try menu Files/Preferences to select additional directories of footprints. I newer tried this last method, but it should work. After using the Files/Preferences/Library dialog, you should create one or more sub-directories under /home/comp/pwb_footprints and place your footprints in them. On the footprint selection dialog, the sub-directories should be visible on the left pane, with the corresponding footprints on the right pane. Cesar ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: PCB Renumber Was/Is Once Again
I brought up this topic a couple of years ago and left it for dead at the time but now have the question again: Is there a script that can be performed on a PCB design that will renumber the components on the board in some spatial order(say starting at the upper left hand corner of the board)? It's easier to troubleshoot a board when the components are numbered in a spatially logical order. And then once it's renumbered to be able to spit out a Was/Is list so that you can back annotate with gschem? Or looking at it from the other direction, can the renumber script on gschem provide a log of the Was/Is component names so that I can manually update PCB? I'm trying not to have to renumber everything by hand. Thanks! _ Hotmail® has ever-growing storage! Dont worry about storage limits. [1]Check it out. References 1. http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage_062009 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Disappearing PCB Footprint details
Stefan -
I do use gsch2pcb to develop the pcb population data, netlist and
population command file. The issue is that the footprints that I
developed that were not in the issue library were not listed in the pcb
library tool on invoking pcb. Interestingly, the footprints showed up in
the buffer (loaded with the pcb {filename}.pcb command) but the silk
screen courtyards put into the parts were not there.
Cheers!
Tony
On Wed, 2009-09-23 at 23:32 +0200, Stefan Salewski wrote:
On Wed, 2009-09-23 at 15:10 -0400, Tony Radice wrote:
Update:
Ladies and Gentlemen -
I experimented with the footprints I had developed in a unique
directory (/home/comp/pwb_footprints) and had no success with seeing
them in the pcb tool.
I think most people use gschem2pcb script to populate the pcb board.
To investigate a footprint you may try Menu Files/Load Element data to
paste buffer. Or you may try menu Files/Preferences to select
additional directories of footprints. I newer tried this last method,
but it should work.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Exploding BOM
On Thursday 24 September 2009 02:10:48 Tony Radice wrote: Hints are greatly appreciated - my next step is to try a different netlist routine. (Anthony Shanks) Did you try -g bom2? I thought I'd eliminated the possibility of stack overflows in that backend. IMHO it's also superior to -g bom anyway ;-) Peter -- Peter Brett pe...@peter-b.co.uk Remote Sensing Research Group Surrey Space Centre signature.asc Description: This is a digitally signed message part. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
