Re: gEDA-user: New layer selector to play with (git preview)

[Jared Casper]

On Wed, Aug 24, 2011 at 3:21 AM, Andrew Poelstra  wrote:
>
> Hey all,
>
> The new gtk layer selector is finished for most uses now. If
> you want to play with it before it's ready to be published
> (which is a few days away still), you can get it here:
>

Looks great! Just played around with it for a second and noticed a bug
though, when you delete or otherwise change the layers in the PCB
Preferences dialog (i.e. delete or move the currently selected layer,
or add a new one) the layers are changed, but the widget isn't
updated, even after the dialog is closed, leading to all kinds of
confusion.

Jared


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: New layer selector to play with (git preview)

[Peter Clifton]

On Fri, 2011-08-26 at 06:01 -0700, Andrew Poelstra wrote:
> On Fri, Aug 26, 2011 at 06:28:09AM +0100, Peter Clifton wrote:
> > 
> > A few nits when I tested it. (And not just looked at the screenshots)..
> > 
> > 1. PCB crashes immediately on startup for me:
> > 
> > 2. It should not be printing debug text like "UPDATE COLORS" to the
> > console ;)
> >
> 
> Both fixed and pushed. Thanks for noticing so quickly! 

That was quick! (Ignore my last email with the bandaid patch).


-- 
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)


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

Re: gEDA-user: New layer selector to play with (git preview)

[Peter Clifton]

On Fri, 2011-08-26 at 05:52 -0700, Andrew Poelstra wrote:
> On Fri, Aug 26, 2011 at 06:28:09AM +0100, Peter Clifton wrote:
> > 
> > A few nits when I tested it. (And not just looked at the screenshots)..
> > 
> > 1. PCB crashes immediately on startup for me:
> > 
> > UPDATE COLORS
> > 
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x004d6883 in gtk_pcb_layer_selector_update_colors (ls=0x0,
> > callback=0x4ca630 )
> > at hid/gtk/gtk-pcb-layer-selector.c:694
> > 694   gtk_tree_model_get_iter_first (GTK_TREE_MODEL (ls->list_store),
> > &iter);
> >
> 
> Cool. I have never seen this. I also don't get the "UPDATE COLORS"
> text on startup. How have you configured your colors?

Nothing special.. but I do have a colour scheme:

 ~/.pcb/preferences contains the line:

color-file = /home/pcjc2/.pcb/colors/foo

(Very imaginatively named ;).

I've attached the colour scheme file just in case you're curious.

> > 2. It should not be printing debug text like "UPDATE COLORS" to the
> > console ;)
> > 
> 
> Oops. But it seems to have helped here. ;)

It is approximately the right place.

This is a bandaid to fix the crash:

diff --git a/src/hid/gtk/gui-top-window.c b/src/hid/gtk/gui-top-window.c
index 001d2ca..d6d061c 100644
--- a/src/hid/gtk/gui-top-window.c
+++ b/src/hid/gtk/gui-top-window.c
@@ -1033,6 +1033,8 @@ get_layer_color (gint layer)
 void
 ghid_layer_buttons_color_update (void)
 {
+  if (PCB == NULL)
+return;
   printf ("UPDATE COLORS\n");
   gtk_pcb_layer_selector_update_colors
 (GTK_PCB_LAYER_SELECTOR (ghidgui->layer_selector), get_layer_color);


But perhaps there is a nicer way.

-- 
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)
black-color =   #00
white-color =   #ff
background-color =  #00
crosshair-color =   #ff
cross-color =   #cdcd00
via-color = #8c8c8c
via-selected-color =#00
pin-color = #99
pin-selected-color =#00
pin-name-color =#ff
element-color = #e6e6e6
rat-color = #b8860b
invisible-objects-color =   #4c4c4c
invisible-mark-color =  #66
element-selected-color =#00
rat-selected-color =#00
connected-color =   #00ff00
off-limit-color =   #66
grid-color =#ff
layer-color-1 = #cd3700
layer-color-2 = #395ecc
layer-color-3 = #cfcf00
layer-color-4 = #8b2323
layer-color-5 = #548b54
layer-color-6 = #8b7355
layer-color-7 = #00868b
layer-color-8 = #228b22
layer-color-9 = #8b2323
layer-color-10 =#3a5fcd
layer-color-11 =#104e8b
layer-color-12 =#cd3700
layer-color-13 =#548b54
layer-color-14 =#8b7355
layer-color-15 =#00868b
layer-color-16 =#228b22
layer-selected-color-1 =#00
layer-selected-color-2 =#00
layer-selected-color-3 =#00
layer-selected-color-4 =#00
layer-selected-color-5 =#00
layer-selected-color-6 =#00
layer-selected-color-7 =#00
layer-selected-color-8 =#00
layer-selected-color-9 =#00
layer-selected-color-10 =   #00
layer-selected-color-11 =   #00
layer-selected-color-12 =   #00
layer-selected-color-13 =   #00
layer-selected-color-14 =   #00
layer-selected-color-15 =   #00
layer-selected-color-16 =   #00
warn-color =#ff8000
mask-color =#009900
### PCB configuration file. ###
gui-compact-horizontal = 1
gui-compact-vertical = 0
gui-title-window = 1
use-command-window = 0
save-in-tmp = 0
grid-units = mil
history-size = 5
auto-pan-speed = 3
top-window-width = 1680
top-window-height = 1026
log-window-width = 1680
log-window-height = 1026
drc-window-width = 795
drc-window-height = 500
library-window-width = 917
library-window-height = 657
netlist-window-height = 577
keyref-window-width = 0
keyref-window-height = 0
text-scale = 296
backup-interval = 60
groups = 1,c:2:3:4:5:6,s:7:8
route-styles = Signal,1000,3600,2000,1000:Power,2500,6000,3500,1000:Fat,4000,6000,3500,1000:Skinny,600,2402,1181,600
library-newlib = 
color-file = /home/pcjc2/.pcb/colors/foo
layer-name-1 = top
layer-name-2 = ground
layer-name-3 = signal2
layer-name-4 = signal3
layer-name-5 = power
layer-name-6 = bottom
layer-name-7 = outline
layer-name-8 = spare


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

Re: gEDA-user: New layer selector to play with (git preview)

[Andrew Poelstra]

On Fri, Aug 26, 2011 at 06:28:09AM +0100, Peter Clifton wrote:
> 
> A few nits when I tested it. (And not just looked at the screenshots)..
> 
> 1. PCB crashes immediately on startup for me:
> 
> 2. It should not be printing debug text like "UPDATE COLORS" to the
> console ;)
>

Both fixed and pushed. Thanks for noticing so quickly! 


-- 
Andrew Poelstra
Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net
Web:   http://www.wpsoftware.net/andrew/



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: New layer selector to play with (git preview)

[Andrew Poelstra]

On Fri, Aug 26, 2011 at 06:28:09AM +0100, Peter Clifton wrote:
> 
> A few nits when I tested it. (And not just looked at the screenshots)..
> 
> 1. PCB crashes immediately on startup for me:
> 
> UPDATE COLORS
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x004d6883 in gtk_pcb_layer_selector_update_colors (ls=0x0,
> callback=0x4ca630 )
> at hid/gtk/gtk-pcb-layer-selector.c:694
> 694 gtk_tree_model_get_iter_first (GTK_TREE_MODEL (ls->list_store),
> &iter);
>

Cool. I have never seen this. I also don't get the "UPDATE COLORS"
text on startup. How have you configured your colors?
 
> 2. It should not be printing debug text like "UPDATE COLORS" to the
> console ;)
> 

Oops. But it seems to have helped here. ;)

> 
> If I'm seeming brief, it might be because its now 6:30AM and I've not
> slept.
>

-- 
Andrew Poelstra
Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net
Web:   http://www.wpsoftware.net/andrew/



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: New layer selector to play with (git preview)

[Peter Clifton]

On Fri, 2011-08-26 at 06:23 +0100, Peter Clifton wrote:
> On Wed, 2011-08-24 at 03:21 -0700, Andrew Poelstra wrote:
> > Hey all,
> > 
> > The new gtk layer selector is finished for most uses now. If
> > you want to play with it before it's ready to be published
> > (which is a few days away still), you can get it here:
> > 
> >   git://wpsoftware.net/pcb-andrew.git
> 
> I see this is committed now, but perhaps we can rename some of the new
> stuff at some point?

A few nits when I tested it. (And not just looked at the screenshots)..

1. PCB crashes immediately on startup for me:

UPDATE COLORS

Program received signal SIGSEGV, Segmentation fault.
0x004d6883 in gtk_pcb_layer_selector_update_colors (ls=0x0,
callback=0x4ca630 )
at hid/gtk/gtk-pcb-layer-selector.c:694
694   gtk_tree_model_get_iter_first (GTK_TREE_MODEL (ls->list_store),
&iter);

2. It should not be printing debug text like "UPDATE COLORS" to the
console ;)


If I'm seeming brief, it might be because its now 6:30AM and I've not
slept.

-- 
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)


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

Re: gEDA-user: New layer selector to play with (git preview)

[Peter Clifton]

On Wed, 2011-08-24 at 03:21 -0700, Andrew Poelstra wrote:
> Hey all,
> 
> The new gtk layer selector is finished for most uses now. If
> you want to play with it before it's ready to be published
> (which is a few days away still), you can get it here:
> 
>   git://wpsoftware.net/pcb-andrew.git

I see this is committed now, but perhaps we can rename some of the new
stuff at some point?

We should never use the gtk_ prefix for our own widgets. That belongs to
GTK's API only. Our GTK HID usually uses "ghid_...", and we should
probably stick to that for new code.

The new widget looks really good.. when I get some time to finish off
the viewport / zoom patches I've been working on, I'll rebase PCB+GL on
top of it.

(My own patches will currently clash with my PCB+GL stuff, so best I
figure out what shape they will land in before rebasing, or I'll end up
resolving conflicts more than once).

Best wishes,

-- 
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)


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

Re: gEDA-user: Foss-pcb Proposed plan from CERN

[Dietmar Schmunkamp]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 24.08.2011 22:46, schrieb John Hudak:
>ummm, I think citing and expounding on the philosophical differences of
>one approach (integrated) versus another (multiple tool kits) is a nice
>amorphous description and somewhat akin to mental masturbation.  
I somehow agree, but the flexibility to insert other (maybe hand-written
own) tools into the entire design flow is essential.

>The philosophy of gEDA has already been established.  What is more
>important is that the tool suite *flawlessly* supports a small subset
>of generally accepted design-fabrication paradigms, eg workflow from
>schematic to completed & populated board, and a subset of potential
>offshoot efforts such as circuit simulation, head modeling,symbol
>creation and package creation and management, etc.
I disagree with this point: You treat circuit simulation as an offshoot,
that's pretty dangerous: If board costs are in the range of 100$ you're
right, but if the board cosst increases to 10k$ it's very dangerous to
give simulation a low priority.

>My premise is that if you put 100 design engineers in a room who have
>done circuit design to board fab and ask them to produce a scenario of
>their work flow, at least 40% of them would have a common scenario.
That's the wrong audience for your question:
Ask architects what it takes to put their ideas into a shippable product
instead of asking the frogs about drying the swamp :-) . You
overestimate one part of the entire design flow.

- From my point of view the major thing is to have one design source (even
with a multitude of attributes e.g. net_group = g1, net_length(g1) = xxx
mm, tolerance(g1) = 1 mm, ...etc) and drive simulation and board layout
from this single source. That also requires feedback of electrical
properties of the board wires back into the design source (and by this
into the simulation model).

I admit, as a hobbyist I'm happy with the current gschem->pcb flow as of
today but for upcoming RF designs I'd like to have an easy generation of
netlists including electrical parameters


... deleted the rest ...
- -- 

Mit freundlichen Gruessen

Dietmar Schmunkamp
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAk5W6dQACgkQn22l+QvEah0UowCeM7lvV+gSkRZ1vkvs9Psv57S0
F4sAn0fBPALS76Wob52Cy13A7e5Nhv4X
=SgkS
-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: gschem vs. PCB diode pin numbering

[Colin D Bennett]

On Thu, 25 Aug 2011 22:41:28 +0200
Levente Kovacs  wrote:

> On Thu, 25 Aug 2011 14:03:35 +0200
> Kai-Martin Knaak  wrote:
> 
> > Why not?
> 
> Pinnumbers are "numbers" in the first place. Former versions of
> netlisters/PCB got confused by non-digital pinnumbers.

Who cares?  There's no reason to restrict ourselves from doing it right
when the tools support it now.

> With this approach you have to have a SOT23 footprint with 1,2,3
> pinout, A,K,NC pinout, A1,A2,K pinout, B,C,E pinout etc. Sooner or
> later, your library will contain duplicated data. What if you
> discover that you want to modify the shape of the SOT23.fp footprint?
> You have to modify all of them. Yuk.

I won't get into it too much here; the logical vs. physical pinnumber
assignment has been discussed in much detail before.


> I think a footprint must have only *one* pinout, that is a standard
> pinout of the package. Have an intermediate layer (scripts, database,
> pinmaps, etc.) that do the heavy lifting for you.

Maybe in an ideal world (when pin mapping orthogonal to the schematic
and layout is introduced), but for now, the only two ways to handle
transistors etc. properly is to either

(1) create separate symbols for each pinout, where pinnumber is
assigned numerically according to package pin number (1, 2, 3).
For instance, you would need symbols NPN-EBC, NPN-BCE, etc., and
potentially different symbols for packages with a fourth “tab” pin such
as SOT-223-4 ; or

(2) create separate footprints for each pinout, using logical
pinnumbers B, C, E, and footprints that assign these to appropriate
package pins; then you only need two BJT symbols “NPN.sym” and
“PNP.sym” that use these logical pins; this supports packages with a
fourth “tab” pin without cluttering the schematic, and allows such
details as pinout to be deferred until after basic schematic drawing.

Do you really want to delete and re-add each of your dozens of
transistors in gschem when you change the transistor to one with a
different pinout?  If you use a logically-pinned symbol, you can easily
change the pinout by just editing the footprint attributes (gattrib,
gschem property editor, export/import to/from spreadsheet, etc.).

Conversation regarding TO-92 transistor package pinouts:


Well, I always say I won't get into the logical/physical pinning
debate, but I always do. :-)  For me, using logical pins on the
schematic symbols such as transistors and diodes (*especially* diodes in
IC packages like SOT-23) is the only way that makes sense ... at least
until proper pin mapping is implemented.

Regards,
Colin


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: gschem vs. PCB diode pin numbering - anode/cathode definition

[Colin D Bennett]

On Thu, 25 Aug 2011 08:28:46 -0400
Ethan Swint  wrote:

> On 08/24/2011 01:15 PM, Colin D Bennett wrote:
> > I understand that it is electrical convention to name diode terminal
> > anode and cathode, but I reject it as a confusing and ambiguous
> > naming convention.
> Yes, it's not quite correct, but it is a widely held convention,
> unlike numbering the pins 1 and 2 (or 3 or 4).

Agreed that A and K certainly avoids ambiguity, as compared to
numbering diode pins simply 1 and 2.  It is 100% superior as it does
convey the required information.

> > For my diode symbols and footprints, I choose to name the terminals
> > “P” and “N“ (for the p-type doped side and the n-type doped side).
> If you use "P" and "N", Schottky diodes are now in error.  ;)

Good point.  The moral of the story is: at least name the pins in a
way that communicates the pin's function in a clear way.  I will have
to make my peace with the fact that there is no 100% technically
correct way to do so... at least we can avoid errors caused by
arbitrarily naming pins 1 and 2.

Regards,
Colin


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: How to do PCB Autorouting with non-plated holes

[Colin D Bennett]

On Wed, 24 Aug 2011 16:33:05 -0400 (EDT)
Cory Papenfuss  wrote:

>   Thanks for all the suggestions.  I've played with it a bit
> and come up with an example for a 200mil radial capacitor below:
> 
> Element["" "" "C0" "" 97000 208000 8000 -28000 0 100 ""]
> (
>  Pin[0 0 0 3000 6600 3000 "" "1" "hole,square"]
>  Pin[2 0 0 3000 6600 3000 "" "2" "hole"]
>  Pad[0 0 100 0 6000 3000 9000 "" "1" "onsolder,square"]
>  Pad[2 0 20100 0 6000 3000 9000 "" "2" "onsolder,edge2"]
>  ElementArc [1 0 2 2 0 360 1000]
> 
>  )
> 
>   I have never had to muck with footprints manually, so it's a
> bit of a learning curve for me.  The footprint Colin provided doesn't
> have a solder mask that's quite right (Resistor_TH_FarPads.fp).  It
> appears that in order to fix is, I had to add the "square" flag to
> the Pin as well as to the Pad.

At first glance, it may look like the solder mask is wrong, but in fact
if you hit Tab to view from the back side of the board and enable
solder mask view, you will see it is correct.

Alternatively, look at the front side of the board and disable the
“far side” layer.  Enable the solder mask layer.  Observe that the
solder mask on the top layer actually has a round hole for the pin.

The solder mask on the front side of the board has a round opening, to
leave space around the hole.  The solder mask on the back side has a
square hole for pin 1's “Pad”.  Viewing the board from the front
doesn't show the difference by default.

Regards,
Colin


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: gschem vs. PCB diode pin numbering

[Levente Kovacs]

On Thu, 25 Aug 2011 14:03:35 +0200
Kai-Martin Knaak  wrote:

> Why not?

Pinnumbers are "numbers" in the first place. Former versions of netlisters/PCB
got confused by non-digital pinnumbers.

With this approach you have to have a SOT23 footprint with 1,2,3 pinout,
A,K,NC pinout, A1,A2,K pinout, B,C,E pinout etc. Sooner or later, your library
will contain duplicated data. What if you discover that you want to modify the
shape of the SOT23.fp footprint? You have to modify all of them. Yuk.

I think a footprint must have only *one* pinout, that is a standard pinout of
the package. Have an intermediate layer (scripts, database, pinmaps, etc.)
that do the heavy lifting for you.



Levente

-- 
Levente Kovacs
http://levente.logonex.eu




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: gschem vs. PCB diode pin numbering - anode/cathode definition

[Vanessa Ezekowitz]

On Thu, 25 Aug 2011 08:28:46 -0400
Ethan Swint  wrote:

> On 08/24/2011 01:15 PM, Colin D Bennett wrote:
> > On Wed, 24 Aug 2011 08:21:17 -0400
> > Ethan Swint  wrote:
> >
> >> On 08/23/2011 08:47 PM, Matthew Lewis wrote:
> >>> I was double checking a pcb layout today and I discovered a rather
> >>> nasty gotcha. It seems that gschem and PCB don't agree on which end
> >>> of a diode should be pin 1. Gschem views pin 1 as the anode and PCB
> >>> considers pin 1 to be the cathode. It doesn't prevent you from
> >>> laying out a board correctly, but it does cause the silkscreen
> >>> polarity to be printed backwards (for the SOD devices at least).
> >> I've defined my own symbols and footprints to use 'A' and 'K' instead
> >> of 1 and 2.
> > That's a good idea.  Anything you can do to error-proof yourself is
> > a Good Thing.
> >
> > However, I refuse to use “anode” and “cathode” for diode symbols, since
> > these terms refer to electron flow and are _incorrect_ when the diode is
> > reverse-biased (most obvious for common Zener diode circuits).
> >
> 
> > I understand that it is electrical convention to name diode terminal
> > anode and cathode, but I reject it as a confusing and ambiguous naming
> > convention.
> Yes, it's not quite correct, but it is a widely held convention, unlike 
> numbering the pins 1 and 2 (or 3 or 4).
> > For my diode symbols and footprints, I choose to name the terminals
> > “P” and “N“ (for the p-type doped side and the n-type doped side).
> If you use "P" and "N", Schottky diodes are now in error.  ;)

I am not an expert by any means, for in the 25 years I've dabbled in 
electronics, including a formal course in high school, it's always been "K" to 
designate the cathode (in addition to what the overall symbol implies, of 
course), regardless of the type of diode or the true direction of current flow.

New users, and those not on this list, are not going to be aware of this 
thread, and are going to expect the anode/cathode convention to hold - anything 
else unnecessarily complicates things, and could potentially lead to much 
bigger problems (i.e. an apparent unreliability of gEDA or PCB).

Why change what works for most electronics folks?

-- 
"There are some things in life worth obsessing over.  Most
things aren't, and when you learn that, life improves."
http://digitalaudioconcepts.com
Vanessa Ezekowitz 


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: This patch is breaking compile

[Felix Ruoff]

I forgot to mention, that I refer to the latest patch-set available at
https://bugs.launchpad.net/pcb/+bug/699497 (Patch set of 2011-08-13.


Am 25.08.2011 21:57, schrieb Felix Ruoff:

Hello Markus and all,

(English text starts after this paragraph. Nothing important here in 
German said.)
danke für die Antwort (auf Deutsch! Viel einfacher für mich zu lesen 
;-) ). Ich habe ein gewisses Interesse daran, dass die Patches 
eingepflegt werden, da ich PCB evtl. als GCode generator für meine CNC 
Fräse benutzen möchte, die zur Zeit mit der reprap-Software läuft 
(wenn ich das richtig rausgefunden habe, bist du/sie (blöde deutsche 
Sprache) bei dem Projekt auch aktiv, oder?). Werd jetzt trotzdem in 
englischer Sprache weiterschreiben, damit sich niemand ausgegrezt fühlt.


Thank you for the 'tutorial'. I have much other things to do, so I 
think it will need some days for me to review all your patches.


There has been some discussion already about Markus' patch-set which I 
will summarise here and add some own comments. Please everybody, give 
your comments.


- 0001 let the system library allocate the temporyary file: Alberto 
Maccioni wrote in his mail of 1. May 2011 that the temporary file is 
sometimes needed for checking the result. He suggested to add a switch 
weather the file should be removed or not. My suggestion: Don't use 
tmpfile(), but use the new function gcode_get_filename() from patch 
0004 with an additional suffix for the filename '.png'.


- 0004 create better file names: Why should the default file-suffix be 
changed to '.cnc'? I suggest to apply this patch but let the default 
file-suffix as it is ('.gcode') for compatibility with probably 
existing scripts using this function.


- 0005 add a flag wether to procude advanced G-code: I will suggest to 
set the switch 'produce advanced G-code' to ON by default (backwards 
compatibility).


- 0007 switch from tool-radius to tool-diameter in the user interface: 
This patch breaks backwards compatibility, so have a little headache 
with it. I think, there is a possibility to mark the tool-radius 
setting as deprecated and support both options (for using the 
gcode-export with scripts). I have not done something like this - 
perhaps anyone have a hint? I would also prefer to have the 
tool-diameter in the user interface (as Markus' patch would do).


I have not reviewed the other patches completely (have stopped at 
0010). I will write again, when I have new questions/suggestions.


If there are no negative comments in the next days I will do the 
changes I suggested and start to apply this patches step by step.


Kind regards,
Felix

By the way: Has anyone started to review the commandline-docu patches 
I have posted last Thursday (gEDA-user: PCB Docu: Patch for 
command-line options)?


@Kai-Martin: I did not forget about your patch for 'Select all 
connected items'



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: This patch is breaking compile

[Felix Ruoff]

Hello Markus and all,

(English text starts after this paragraph. Nothing important here in 
German said.)
danke für die Antwort (auf Deutsch! Viel einfacher für mich zu lesen ;-) 
). Ich habe ein gewisses Interesse daran, dass die Patches eingepflegt 
werden, da ich PCB evtl. als GCode generator für meine CNC Fräse 
benutzen möchte, die zur Zeit mit der reprap-Software läuft (wenn ich 
das richtig rausgefunden habe, bist du/sie (blöde deutsche Sprache) bei 
dem Projekt auch aktiv, oder?). Werd jetzt trotzdem in englischer 
Sprache weiterschreiben, damit sich niemand ausgegrezt fühlt.


Thank you for the 'tutorial'. I have much other things to do, so I think 
it will need some days for me to review all your patches.


There has been some discussion already about Markus' patch-set which I 
will summarise here and add some own comments. Please everybody, give 
your comments.


- 0001 let the system library allocate the temporyary file: Alberto 
Maccioni wrote in his mail of 1. May 2011 that the temporary file is 
sometimes needed for checking the result. He suggested to add a switch 
weather the file should be removed or not. My suggestion: Don't use 
tmpfile(), but use the new function gcode_get_filename() from patch 0004 
with an additional suffix for the filename '.png'.


- 0004 create better file names: Why should the default file-suffix be 
changed to '.cnc'? I suggest to apply this patch but let the default 
file-suffix as it is ('.gcode') for compatibility with probably existing 
scripts using this function.


- 0005 add a flag wether to procude advanced G-code: I will suggest to 
set the switch 'produce advanced G-code' to ON by default (backwards 
compatibility).


- 0007 switch from tool-radius to tool-diameter in the user interface: 
This patch breaks backwards compatibility, so have a little headache 
with it. I think, there is a possibility to mark the tool-radius setting 
as deprecated and support both options (for using the gcode-export with 
scripts). I have not done something like this - perhaps anyone have a 
hint? I would also prefer to have the tool-diameter in the user 
interface (as Markus' patch would do).


I have not reviewed the other patches completely (have stopped at 0010). 
I will write again, when I have new questions/suggestions.


If there are no negative comments in the next days I will do the changes 
I suggested and start to apply this patches step by step.


Kind regards,
Felix

By the way: Has anyone started to review the commandline-docu patches I 
have posted last Thursday (gEDA-user: PCB Docu: Patch for command-line 
options)?


@Kai-Martin: I did not forget about your patch for 'Select all connected 
items'



Am 25.08.2011 17:28, schrieb Markus Hitter:


Am 23.08.2011 um 07:50 schrieb Felix Ruoff:

as you can see, some of the patches failed to get applied. The reason 
for this are some changes in git head (the nanometer-conversion). I 
have worked to get this fixed yesterday but did not fully complete.


Ganz unerwartete Unterstützung, vielen Dank. :-)

Das letzte Mal hat es gut funktioniert, ein Rebase für jeden einzelnen 
neuen Schritt aus master zu machen. Also erst die Version auschecken, 
zu der der Patchset passt, dann die Zahl der neuen Schritte zählen, dann


git rebase master~38
autogen.sh && make clean && make
git rebase master~37
autogen.sh && make clean && make
git rebase master~36
autogen.sh && make clean && make
git rebase master~35
autogen.sh && make clean && make
...

bis man wieder bei master ist. Dann fallen die manuellen Korrekturen 
entweder ganz weg oder bleiben zumindest übersichtlich.



Wenn ich da lese, dass ein Patch für nicht durchgehende Vias schon 
seit mehreren Jahren existiert, aber immer noch nicht eingebracht ist, 
dann bekomme ich das Gefühl, dass gEDA so eine Art Aufstand der 
Nicht-Developer braucht. Diese konsequente Verweigerung neuer Features 
ist zu nichts zu gebrauchen, gEDA könnte bereits sehr viel weiter sein.



Gruss,
Markus

- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/







___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

gEDA-user: gschem: Modifier keys for moving?

[Stefan Salewski]

If my memory is correct, there are plans (have seen a patch at geda-dev
long time ago?) to allow moving of objects without need of selecting
them first for gschem1.8, as suggested in my draft
http://www.ssalewski.de/PetEd.png

Would it make sense to have modifier keys for moving? I would like
rubberband mode for plain move, and no rubberband when SHIFT is hold
down. I think currently we have to type "or" or use pulldown menu -- at
least there should be an icon for fast toggling.

And of course, there should be much more, i.e a combo-box for grid size
with default values 100, 50, 25, 10 and entry field for custom values.
(why these void area on the right of the 10 icons in gschem GUI?)





___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: gschem vs. PCB diode pin numbering

[Kai-Martin Knaak]

Kovacs Levente wrote:

> On Wed, 24 Aug 2011 08:21:17 -0400
> Ethan Swint  wrote:
> 
>> I've defined my own symbols and footprints to use 'A' and 'K' instead
>> of 1 and 2.
> 
> I don't think it's a good idea.

Why not?

---<)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
-> not happy with moderation of geda-user mailinglist



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Foss-pcb Proposed plan from CERN

[John Doty]

On Aug 24, 2011, at 2:46 PM, John Hudak wrote:

Rudeness snipped.

>  The
>   philosophy of gEDA has already been established.

Kind of. But part of the misconception you have is that gEDA (as currently 
defined) has a coherent philosophy. gEDA once referred only to gschem, 
gnetlist, and associated tools. "pcb" is an older program, which I believe only 
came under the gEDA tent after gschem replaced xcircuit as the tool of choice 
for schematic capture by pcb users.

I think this is very confusing to new users: pcb and the 
gschem/gnetlist/gattrib/... kit play well together, but they are not 
integrated. They represent different design philosophies, and cannot be 
integrated without damage. A Jeep pulling a trailer is more flexible 
transportation than an integrated RV.

I think that a great deal of confusion and strife would be avoided if the core 
developers would separate the pcb and gEDA projects.

>  What is more
>   important is that the tool suite *flawlessly* supports a small subset
>   of generally accepted design-fabrication paradigms, eg workflow from
>   schematic to completed & populated board, and a subset of potential
>   offshoot efforts such as circuit simulation, head modeling,symbol
>   creation and package creation and management, etc.
>   My premise is that if you put 100 design engineers in a room who have
>   done circuit design to board fab and ask them to produce a scenario of
>   their work flow, at least 40% of them would have a common scenario.

Based on the wildly different notions people on this forum have for what the 
common scenarios are, I doubt it. The failure of efforts by vocal advocates of 
the "common scenarios" point of view to create a coherent symbol library for 
the "most common scenarios" is evidence, too. But I would also assert that gEDA 
is, by its nature, the toolkit of choice for all those uncommon scenarios. You 
would probably be somewhat happier with KiCad (although I doubt you'd be happy 
with anything).

>   If someone buys into a certain philosophy and the tool implementation
>   causes them pain, they will search for less painless approaches and
>   adapting ones development scenario is much easier than trying to
>   understand and patching someone bogus code.

I think it used to be easier to learn gEDA when we *didn't* have all the 
tutorial stuff, just concise reference documentation. It's easier to learn to 
fish than to have to beg for every meal. One problem with the tutorials is that 
there are lots of paths you can use, and each tutorial applies to a subset.

>   Another point is don't stick ones head in the sand and start slinging
>   code so that the additions 'do something'Consider 'the other
>   religion' and the possibility that one might want to import a schematic
>   developed in kicad, Altrum, orcad or whatever because PCB is the
>   sexiest thing on earth.

Yep, that would be nice. The problem is that import is hard without support 
from the upstream tool. The secret of the (multiple) ways to get a design from 
gschem to pcb is gnetlist, which is operating behind the scenes even if you're 
not using it explicitly.

> One also needs to consider outflow of a design
>   from gEDA to whatever.

This is gEDA's greatest strength. Type "gnetlist -g help" and/or "man gnetlist".

>   Make a road map, have a plan, follow the plan and have at it.

That's the top-down approach. It has the advantage that it gets you to a 
well-defined destination efficiently. But if you want to go anywhere else in 
the future, it's trouble. Bottom-up design is more appropriate if you want 
unlimited horizons.

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: This patch is breaking compile

[Markus Hitter]

Am 23.08.2011 um 07:50 schrieb Felix Ruoff:

as you can see, some of the patches failed to get applied. The  
reason for this are some changes in git head (the nanometer- 
conversion). I have worked to get this fixed yesterday but did not  
fully complete.


Ganz unerwartete Unterstützung, vielen Dank. :-)

Das letzte Mal hat es gut funktioniert, ein Rebase für jeden  
einzelnen neuen Schritt aus master zu machen. Also erst die Version  
auschecken, zu der der Patchset passt, dann die Zahl der neuen  
Schritte zählen, dann


git rebase master~38
autogen.sh && make clean && make
git rebase master~37
autogen.sh && make clean && make
git rebase master~36
autogen.sh && make clean && make
git rebase master~35
autogen.sh && make clean && make
...

bis man wieder bei master ist. Dann fallen die manuellen Korrekturen  
entweder ganz weg oder bleiben zumindest übersichtlich.



Wenn ich da lese, dass ein Patch für nicht durchgehende Vias schon  
seit mehreren Jahren existiert, aber immer noch nicht eingebracht  
ist, dann bekomme ich das Gefühl, dass gEDA so eine Art Aufstand der  
Nicht-Developer braucht. Diese konsequente Verweigerung neuer  
Features ist zu nichts zu gebrauchen, gEDA könnte bereits sehr viel  
weiter sein.



Gruss,
Markus

- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/







___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: gschem vs. PCB diode pin numbering - anode/cathode definition

[Ethan Swint]

On 08/24/2011 01:15 PM, Colin D Bennett wrote:

On Wed, 24 Aug 2011 08:21:17 -0400
Ethan Swint  wrote:


On 08/23/2011 08:47 PM, Matthew Lewis wrote:

I was double checking a pcb layout today and I discovered a rather
nasty gotcha. It seems that gschem and PCB don't agree on which end
of a diode should be pin 1. Gschem views pin 1 as the anode and PCB
considers pin 1 to be the cathode. It doesn't prevent you from
laying out a board correctly, but it does cause the silkscreen
polarity to be printed backwards (for the SOD devices at least).

I've defined my own symbols and footprints to use 'A' and 'K' instead
of 1 and 2.

That's a good idea.  Anything you can do to error-proof yourself is
a Good Thing.

However, I refuse to use “anode” and “cathode” for diode symbols, since
these terms refer to electron flow and are _incorrect_ when the diode is
reverse-biased (most obvious for common Zener diode circuits).




I understand that it is electrical convention to name diode terminal
anode and cathode, but I reject it as a confusing and ambiguous naming
convention.
Yes, it's not quite correct, but it is a widely held convention, unlike 
numbering the pins 1 and 2 (or 3 or 4).

For my diode symbols and footprints, I choose to name the terminals
“P” and “N“ (for the p-type doped side and the n-type doped side).

If you use "P" and "N", Schottky diodes are now in error.  ;)


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: How to do PCB Autorouting with non-plated holes

[Kai-Martin Knaak]

Colin D Bennett wrote:

>  Well, you could do the heavy lifting with an awk script: 
>> 
>>  If the current line is a pin,
>> set the diameter of the pin to zero and add a hole flag
>> ouput a round pad with the diameter of the pins annular ring
>>  else, 
>> output the current line unchanged.   
> 
> Could you do this on the layout (.pcb file) after all elements are
> placed so he would not even need to create new footprint files?
 
I answered yesterday (*), that it would be tricky to make sure the conversion 
happens only once if you apply the script more than once. Actually, there is 
an easy solution: Only do the conversion if the pin in question has non-zero 
pin width.

---<)kaimartin(>---

(*) Which didn't hit the list, yet.
-- 
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
-> increasingly unhappy with moderation of geda-user mailinglist



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: How to do PCB Autorouting with non-plated holes

[Kai-Martin Knaak]

Colin D Bennett wrote:

>> Well, you could do the heavy lifting with an awk script: 
>> 
>>  If the current line is a pin,
>> set the diameter of the pin to zero and add a hole flag
>> ouput a round pad with the diameter of the pins annular ring
>>  else, 
>> output the current line unchanged.   
> 
> Could you do this on the layout (.pcb file) after all elements are
> placed so he would not even need to create new footprint files?

Sure. 
It would get a little nasty though, if you require the script to ignore 
the already converted pins.  

---<)kaimartin(>---
-- 
Kai-Martin Knaak
Email: k...@familieknaak.de
http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53
increasingly unhappy with moderation of geda-user



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: canvas of openGL enabled PCB temporarily goes confetti

[Kai-Martin Knaak]

Peter Clifton wrote:

> Thanks for the screen-shot. I can't reproduce it here on Intel HW. Does
> it happen for any other GL applications, such as glxgears?

No. 
glxgears adjusts its size just fine. 
etuxracer flickers but does not show the confetty syndrome.
glest does not allow resize in the first place.
gliv resizes images impressively fast with no apparent glitch at all.

<)kaimartin(>---
-- 
Kai-Martin Knaak
Email: k...@familieknaak.de
http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53
increasingly unhappy with moderation of geda-user



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: How to do PCB Autorouting with non-plated holes

[Cory Papenfuss]

	Thanks for all the suggestions.  I've played with it a bit and 
come up with an example for a 200mil radial capacitor below:


Element["" "" "C0" "" 97000 208000 8000 -28000 0 100 ""]
(
Pin[0 0 0 3000 6600 3000 "" "1" "hole,square"]
Pin[2 0 0 3000 6600 3000 "" "2" "hole"]
Pad[0 0 100 0 6000 3000 9000 "" "1" "onsolder,square"]
Pad[2 0 20100 0 6000 3000 9000 "" "2" "onsolder,edge2"]
ElementArc [1 0 2 2 0 360 1000]

)

	I have never had to muck with footprints manually, so it's a bit 
of a learning curve for me.  The footprint Colin provided doesn't have a 
solder mask that's quite right (Resistor_TH_FarPads.fp).  It appears that 
in order to fix is, I had to add the "square" flag to the Pin as well as 
to the Pad.


-Cory

On Tue, 23 Aug 2011, Kai-Martin Knaak wrote:


Cory Papenfuss wrote:


I thought about that... making different footprints that don't
have copper on the component side of the pins.  Since that would require
making new footprints for pretty much everything,


Well, you could do the heavy lifting with an awk script:

If the current line is a pin,
   set the diameter of the pin to zero and add a hole flag
   ouput a round pad with the diameter of the pins annular ring
else,
   output the current line unchanged.



I was hoping for a
different solution... :)  It seems like it would be a relatively common
thing for hobbyists to want (whether it's a milled or home-etched board),
so I thought there might be a setting on the autorouter config to "ignore
component hold plating" or something.


IMHO, the copperless pin solution is superior. It models the layout like
it is in reality.

That said, both autorouters have a problem with user level configuration,
or rather the lack thereof. Features that would make auto routing a much
more viable option than it is now:


* alternatively minimize via count, or minimize overall track length

* options to not autoroute particular nets/pins/components

* track parameters that depend on the net it connects

* preferred routing direction of a layer

* Non-copper avoid-areas with different levels of importance.
 (prefer-to-avoid --> avoid at all cost)

---<)kaimartin(>---
--
Kai-Martin Knaak
Email: k...@familieknaak.de
http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53
increasingly unhappy with moderation of geda-user



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user





*
* Cory Papenfuss, Ph.D. Electrical Engineering, PPSEL-IA*
* Research Associate, Vibrations and Acoustics Laboratory   *
* Mechanical Engineering*
* Virginia Polytechnic Institute and State University   *
*



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Foss-pcb Proposed plan from CERN

[John Hudak]

   ummm, I think citing and expounding on the philosophical differences of
   one approach (integrated) versus another (multiple tool kits) is a nice
   amorphous description and somewhat akin to mental masturbation.  The
   philosophy of gEDA has already been established.  What is more
   important is that the tool suite *flawlessly* supports a small subset
   of generally accepted design-fabrication paradigms, eg workflow from
   schematic to completed & populated board, and a subset of potential
   offshoot efforts such as circuit simulation, head modeling,symbol
   creation and package creation and management, etc.
   My premise is that if you put 100 design engineers in a room who have
   done circuit design to board fab and ask them to produce a scenario of
   their work flow, at least 40% of them would have a common scenario.
   So the important questions to ask and answer are:
   Do you know what the top 2 (or 3) scenarios are?
   Do you know what the top 2 (or 3) parallel offshoot activities are?
   How well can those scenarios by fulfilled by the tool chain
   approach?(Conceptually)
   How well can those scenarios by fulfilled by the tool chain approach,
   in reality (e.g do the tools work flawlessly and do they scale?)
   If someone buys into a certain philosophy and the tool implementation
   causes them pain, they will search for less painless approaches and
   adapting ones development scenario is much easier than trying to
   understand and patching someone bogus code.
   Another point is don't stick ones head in the sand and start slinging
   code so that the additions 'do something'Consider 'the other
   religion' and the possibility that one might want to import a schematic
   developed in kicad, Altrum, orcad or whatever because PCB is the
   sexiest thing on earth. One also needs to consider outflow of a design
   from gEDA to whatever.
   Make a road map, have a plan, follow the plan and have at it.
   J

   On Wed, Aug 24, 2011 at 1:03 PM, John Doty <[1]j...@noqsi.com> wrote:

   On Aug 24, 2011, at 8:33 AM, Jared Casper wrote:
   > I chuckled at what this community would think of the comment, in
   > response to "There are users who prefer separate dedicated
   > applications to an integrated design environment.", "BTW. How many of
   > these users have ever designed a PCB with more than 4 layers and,
   say,
   > 300 components? From my own experience, above the certain level of
   PCB
   > complexity the intuitiveness and efficiency of the GUI become a
   > paramount. "

 I think that's exactly backwards. The "intuitiveness and efficiency"
 of the GUI make for comfort, but not productivity. In a big design,
 the key is to break it down into modules, and then use the
 automation to put the modules together. This is especially true when
 you recognize that a big design encompasses not just EDA, but
 documentation, software, and possibly other things. The toolkit
 approach allows you to combine these things in a maximally automated
 flow.
 I've seen the difference starkly in software. I personally don't
 care what tools a programmer uses as long as they get the job done:
 this should be a matter of individual preference. Except, it is my
 experience that programmers who prefer toolkits are much more
 productive than programmers who prefer IDE. They plan better, they
 factor better, and they exploit the power of the computer better.
 One serious problem is that IDE encourages very inefficient
 debugging practices: it's much better to trap bugs with assertions,
 logs, and analysis than to fish for bugs interactively.
 Yes, it takes more thought and planning to use a toolkit. For simple
 jobs, a nice intuitive GUI is fine (I'm typing this to the Mac
 "Mail" app). But planning is more important for big jobs, and a
 toolkit rewards planning better. Spending time to adapt your
 processes to the job is a big time saver for big jobs.
 A flexible, extensible, toolkit is especially superior for jobs that
 have characteristics that fall outside the limits of the application
 designers' imaginations. Try exporting KiCad designs to a computer
 algebra system for symbolic analysis (but the Mathematica back end
 for gnetlist only took me an afternoon to write).
 The important thing to recognize is that there is room for, and a
 need for, both toolkits and integrated tools. AWK and spreadsheets
 are both effective at processing tabular data in their own ways, but
 a merged tool with the characteristics of both would be
 incomprehensible. I think the same is true in EDA.
 It is my opinion that gEDA's developers and users should embrace its
 strengths as a powerful, flexible toolkit. Keep the tools separate.
 Keep the interfaces clean and simple. Maximize the rewards that
 those who can do a little scripting can earn. Let KiCad cover the
 integrated a

Re: gEDA-user: gschem vs. PCB diode pin numbering

[Kovacs Levente]

On Wed, 24 Aug 2011 08:21:17 -0400
Ethan Swint  wrote:

> I've defined my own symbols and footprints to use 'A' and 'K' instead
> of 1 and 2.

I don't think it's a good idea. Instead, I use my own library, where pin
numbers are consistent. In addition I have my perl scripts which can add pin
numbers to symbols according to pinmap files.

Levente

-- 
Kovacs Levente 
Voice: +36705071002




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user