Re: gEDA-user: Matching footprints with symbols

[Colin D Bennett]

On Sat, 17 Apr 2010 05:23:05 +0200
kai-martin knaak  wrote:

> Stefan Salewski wrote:
> 
> > This can give trouble in rare cases due to m4 macro expansion.
>
>/rare/many/
> The insidious side of this bug shows by the many seemingly unrelated
> ways it breaks the layout further down the road.
> 
> Bottom line: Avoid hyphens in footprint names except to add a
> revision number at the end of the base name.

Alternate bottom line: Avoid m4 footprint library.

Regards,
Colin


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

Re: gEDA-user: Matching footprints with symbols

[Colin D Bennett]

On Sat, 17 Apr 2010 05:23:05 +0200
kai-martin knaak  wrote:

> Stefan Salewski wrote:
> 
> > On Sat, 2010-04-17 at 01:15 +0200, Armin Faltl wrote:
> 
> >> Did anyone try my schematic posted in
> >> http://www.seul.org/pipermail/geda-user/2010-April/046716.html
> 
> I read the list with knode via gmane. Unfortunately, gmane munged
> your attachments. And I was too lazy to ask for a resend to my
> private email address.
> 
> 
> > One remark: You used the minus sign "-" in your footprint names.
> 
> This seems to be the initiation bug for serious geda users :-P

> There is an option to gsch2pcb to ignore the m4 library no matter
> what: --skip-m4

I always use 'skip-m4' in my gsch2pcb project file since newlib is so
much cleaner.

> Bottom line: Avoid hyphens in footprint names except to add a
> revision number at the end of the base name. 

Unless you're exclusively creating newlib footprints, right?

For instance, my footprint library contains the following footprints
which have hyphens ("-") in their name:

FCI_10033526-N3212MLF.fp
Hirose_DF13A-2P-1.25H.fp
Molex_KK-156_male_header_3pin.fp
Molex_KK-156_male_header_8pin.fp
NXP_LQFP-48_7x7_SOT313-2.fp
Omron_XF2M-2015-1A_RefPin1.fp
Omron_XF2M-2015-1A_RefPin20.fp
TSOP-5.fp

Regards,
Colin


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

Re: gEDA-user: Problems compiling PCB Release 20100929

[dfro]

Thanks Colin,

That makes a lot of sense. Very clearly explained!

I like the idea of making distinctly separate locations for each build 
of a program.


Dave

On 11/12/2010 04:01 PM, Colin D Bennett wrote:

On Wed, 10 Nov 2010 20:46:12 -0500
d...@umich.edu wrote:


P.S. Will my Ubuntu 10.04 system get confused if I install both the
Synaptic package of pcb along with the compiled version?


You should look at the 'prefix' where pcb is configured for
installation.  Don't use a prefix of '/usr' since that will (1) stomp
on files installed by the .deb version installed by the Ubuntu
package manager, and (2) I never, ever install any hand-compiled
program in /usr since you will totally lose track of what you have
manually installed in that enormous, fairly flat namespace.

You can probably use a prefix of /usr/local successfully, and then
things will probably be in your PATH by default, (/usr/local/bin comes
before /usr/bin in the default Ubuntu path).  However, even
though /usr/local avoids stomping on managed packages, it is still like
a big dumping ground that is very unorganized.  Good luck trying to
clean up old version of programs installed there...

I use the following specific method of organizing manually installed
packages.  You may prefer to eliminate the VERSION level of hierarchy
and use just /opt/pcb as the prefix, but I have found it very useful
and not at all cumbersome to allow multiple versions to be installed
simultaneously.

(1) I install all non-Ubuntu-managed programs
into /opt/PACKAGENAME/VERSION.  For instance, when building pcb, I use
a command like

   ./configure --prefix=/opt/pcb/20091103

This will create a hierarchy under /opt/pcb/20091103 with 'bin' and
'share' directories.

(2) I create a symbolic link to '20091103' at /opt/pcb/current.  Then
if I have multiple pcb versions installed under /opt/pcb, I can just
have /opt/pcb/current/bin in my PATH and the currently selected pcb
version will be executed.

(3) Put this in your .profile if you often run pcb from the command
line: PATH="/opt/pcb/current/bin:$PATH"
Otherwise you can add a Gnome/KDE icon to your programs menu or launch
bar that runs /opt/pcb/current/bin/pcb.

Regards,
Colin


___
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: PCB+GL Testers (please test)

[kai-martin knaak]

Peter Clifton wrote:

> If you fancied sending me any of the boards off-list, I'll have
> a play and see if I can make PCB+GL faster with them ;)

I set up a git repository of pidpeltier and made it available
via gitweb:
 http://bibo.iqo.uni-hannover.de/gitweb/?p=PIDpeltier.git;a=tree
No cloning yet, because I forgot to set the export-option of the
git-daemon. But access via http with the link above should work.

The layout of Phasendetektor-Atlas has a similar size, but with 
four copper layers:
http://bibo.iqo.uni-hannover.de/gitweb/?p=Phasendetektor-Atlas.git;a=tree

---<)kaimartin(>--- 

-- 
Kai-Martin Knaak
Öffentlicher PGP-Schlüssel:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53



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

Re: gEDA-user: Matching footprints with symbols

[kai-martin knaak]

kai-martin knaak wrote:

> Bottom line: Avoid hyphens in footprint names except to add
> a revision number at the end of the base name. 

For some reason, this posting got stuck in the outbox when more
than 6 months ago. Now, it finally got unleashed. 
Sorry for the inconvenience.

 ---<)kaimartin(>---

-- 
Kai-Martin Knaak
Öffentlicher PGP-Schlüssel:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53



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

Re: gEDA-user: Matching footprints with symbols

[kai-martin knaak]

Stefan Salewski wrote:

> On Sat, 2010-04-17 at 01:15 +0200, Armin Faltl wrote:

>> Did anyone try my schematic posted in
>> http://www.seul.org/pipermail/geda-user/2010-April/046716.html

I read the list with knode via gmane. Unfortunately, gmane munged your  
attachments. And I was too lazy to ask for a resend to my private email 
address.


> One remark: You used the minus sign "-" in your footprint names.

This seems to be the initiation bug for serious geda users :-P

Welcome to the club!

Seriously, this bug is long standing since at least eight years. It has been 
discussed multiple times on the list and even been ranted on. The bug itself 
has not been addressed, yet. Some (power) users make a point in never using 
the m4 lib directly -- Most notably John Luciani. They thus can get away 
with hyphens in their footprint names.  

There is an option to gsch2pcb to ignore the m4 library no matter what: 
--skip-m4


> This can give trouble in rare cases due to m4 macro expansion.
   
   /rare/many/
The insidious side of this bug shows by the many seemingly unrelated ways it 
breaks the layout further down the road.

Bottom line: Avoid hyphens in footprint names except to add a revision 
number at the end of the base name. 

---<)kaimartin(>---
-- 
Kai-Martin Knaak
Öffentlicher PGP-Schlüssel:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53



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

Re: gEDA-user: gnetlist crash

[Levente Kovacs]

On Sat, 13 Nov 2010 01:19:18 +0100
Levente Kovacs  wrote:

> I'm trying to build gEDA from sources. I successfully installed it,
> but it keep searching for *.scm files in old places. When I run
> gnetlist I get:
> 
> Invalid path [/usr/share/gEDA/bitmap] passed to bitmap-directory
> Loading schematic
> [/home/leva/git/lbus/hardware/concentrator/if_card/sch/if_card.sch]
> Loading schematic
> [/home/leva/git/lbus/hardware/concentrator/if_card/sch/ps.sch] Failed
> to read init scm file [/usr/share/gEDA/scheme/gnetlist.scm] Failed to
> read drc2 scm file [/usr/share/gEDA/scheme/gnet-drc2.scm]
> 
> How can I get the system to find the /usr/local/* stuff?

Ok, this is solved. There was some stuff left over from the former
installation of gEDA.

Now... back to the story.

It is a hierarchical design. Now I run the following:

gdb --args /usr/local/bin/gnetlist -v -g drc2 -o drc2_out.txt if_card.sch ps.sch

and I get some very funny output:

GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/local/bin/gnetlist...done.
(gdb) run
Starting program: /usr/local/bin/gnetlist -v -g drc2 -o drc2_out.txt 
if_card.sch ps.sch
[Thread debugging using libthread_db enabled]
Loading schematic 
[/home/leva/git/lbus/hardware/concentrator/if_card/sch/if_card.sch]
Loading schematic [/home/leva/git/lbus/hardware/concentrator/if_card/sch/ps.sch]


--
Verbose mode legend

n : Found net
C : Found component (staring to traverse component)
p : Found pin (starting to traverse pin / or examining pin)
P : Found end pin connection (end of this net)
R : Starting to rename a net
v : Found source attribute, traversing down
^ : Finished underlying source, going back up
u : Found a refdes which needs to be demangle
U : Found a connected_to refdes which needs to be demangle
--

- Starting internal netlist creation
 C CpPnnPpPPpPPpnnPpnnPpnnPpnnPpnnPpnnPpnnPpnnPpnnPpnnPpnnP CpnnP 
Cpn
nP CpnnP CpnnP CpnnPpnPpnnPpnnPpnnPpnPpnnPpPPpPnPpPnPpPnPpnn
nnPpPpP CpnnP CpnP CpnP CpnPpnnnPnnP CpnPpnnnPnnP CpnP CpnP CpnP CpnP 
CpnnP Cpnn
P CpnnP CpnnP CpnnPnP CpnP CpnP CpnPpnnPnP CpnP CpnPpnPnPpnnPpnnPpnnPpnP 
CpnnP Cpnn
P CpnnP CpnP CpnP CpnnPpnPnP CpnnP CpnPpnPpnPpnnPPnPpPPpPP 
CpnPpnnPn
nP CpnPpnnPnnP CpnP CpnP CpnP CpnP CpnP 
CpnnPpnPpnPpnPpnnPnPPpPpPpnPpnPp
nnPnPPpnnPpnPpnPpnPpPpPpnPpnP CpnnP CpP CpP 
CpnnPpnnnPPP C
pnnPpnnP CpnnP CpnnPpPpnnPpnnnPPpnnP CpnP CpnP CpnP CpnP CpnP CpnP 
CpnnPPnnPnP
nPnPPnPpnnPPnnPnPnPnPPnP CpnnPPnnPnPnPnPPnPpnnPPnnPnPnPnPPnP CpnnPPnnPnPnPnPPnP
pnnPPnnPnPnPnPPnP CpnnnPPPnnPnPnPPnPpnnnPPPnnPnPnPPnP CpnnnPPPnnPnPnPPnPpnnnPPP
nnPnPnPPnP CpnnnPPPnnPnPnPPnPpnnnPPPnnPnPnPPnP CpPPPnPnPnPPnP 
CpPPPnPnPnPPnP CpP CpnnP CpP 
CpnnPpPpnnPpPpnnPpPpnnPpnnPpnnPpPnPpnn
nnPnPpnPpnPpnP CpnPpPnP CpnPpPnP CpnPpPnP CpnPpnnPnnP CpnP CpnP 
CpnP CpnP
 CpPnPpPnPpnnPnnPpPnPpPnPpPnPpnPpnPpnPpnPpnPpnP CpnP CpnP 
Cpn
nP CpnnP CpnnP CpnnP CpnnnPPPnnPnPnPnPPpnnnPPPnnPnPnPnPP 
CpnnPPPnnPnPnPnPnPpnnPPPn
nPnPnPnPnP CpP CpnP CpnP CpnP CpnnP CpnnP CpnnP CpnnP CpnnP CpnnP CpnnP 
CpnnP CpnP CpnP
 CpnP CpnP DONE
- Starting internal netlist creation
 CpnnnPPnPnnPpnnnPPnP CpnnPnPnPpnnPPnP CpnnPnPnnPnP CpnnPPnPpnnPnPnnPnP 
CpnnnPnPpn
nPnPP CpnnPPnPnPnPpnnnPnPpnnnPpnnPpnnnPnPpPnPnPnnnpnnPPnPnPnPp
PPnnnPnPnP CpnnPpnnnPnP CpnnPPnPnPnPpPnPnPnnn CpnnPpnnnPnP 
CpnnnP
pnnnP CpnnnPnPpnnPPnP CpnnPnPnP CpnnP CpnnnPPnPpnnnPPnPnnP CpnnP CpnnnP CpnnP 
CpnnP Cp
nPpnP CpnP CpPPnPnPpnP CpPPnnnPnPnPpPnPnPnnn 
CpPPnnnPnPnPpnnn
nPnPnPnnn C CpnPpnPpnPpnPpnPpnPpnPpnPpnPpnPpnPpnPpnPpnPpnPpnPpnPpnPpnPpnPpn
PpnPpnPpnPpnnnPnPnPnPnPnPpnnnPnPnPnPnPnPpnnnPnPnPnPnPnPpnnnPnPnPnPnPnPpnnnPnP
nPnPnPnPpnnPnnPnPnPnPnPpnPpnP CpnPpnPpnnPpnPpnnPpnnPpnnPpnPpnPpnPpnnPpnnPpnnPp
nnPpnnPpnnPpnnPpnnPpnPpnPpnPpnPpnPpnPpnnnPnPnPnPnPnPpnnnPnPnPnPnPnPpnnnPnPnPn
PnPnPpnnnPnPnPnPnPnPpnnnPnPnPnPnPnPpnnPnnPnPnPnPnPpnPpnP CpnnnPnPnPnPnPnP CpnnP
 CpnnP CpnnP CpnnP CpnnP CpnnP CpnnP CpnnP CpnnP CpnnP CpnP CpnP CpnP CpnP CpnP 
CpnP CpnP CpnP
 CpnP CpnP CpnP CpnP CpnnnPnPnPnPnPnP CpnP CpnP CpnP CpnP CpnP CpnP CpnP CpnP 
CpnP CpnP CpnP C
pnP CpnP CpnP CpnP CpnP CpnP CpnP CpnP CpnP CpnP CpnP CpnP CpnP CpnP CpnP 
CpnnPpnnPpnnPpnnPp
nnPpnPpnPpnPv
- Starting internal netlist creation
 CpnP CpnPpnnPnnPnPnP CpnP CpnnPP 
CpnnPnnPnnPpPPnnPpPnPnPpnnPnPnPp
nnPnnPpn

Re: gEDA-user: gnetlist crash

[Levente Kovacs]

On Fri, 12 Nov 2010 23:53:06 +
Peter TB Brett  wrote:

> On Friday 12 November 2010 23:37:18 Levente Kovacs wrote:
> > Hi all,
> > 
> > 
> > I could make gnetlist crash with the following command:
> > 
> > gnetlist -q -g gsch2pcb -o pcb/if_card.new.pcb -m gnet-
> gsch2pcb-tmp.scm
> > sch/if_card.sch sch/ps.sch
> 
> Hi,
> 
> Are you able to narrow it down to a minimal testcase at all?
> 
> Also, the stack trace would be more helpful if you installed the -
> dbg packages for libguile and libc. I'm not sure how to do that on 
> Debian, I'm afraid.
> 
> Thanks!

I'm trying to build gEDA from sources. I successfully installed it, but it
keep searching for *.scm files in old places. When I run gnetlist I get:

Invalid path [/usr/share/gEDA/bitmap] passed to bitmap-directory
Loading schematic 
[/home/leva/git/lbus/hardware/concentrator/if_card/sch/if_card.sch]
Loading schematic [/home/leva/git/lbus/hardware/concentrator/if_card/sch/ps.sch]
Failed to read init scm file [/usr/share/gEDA/scheme/gnetlist.scm]
Failed to read drc2 scm file [/usr/share/gEDA/scheme/gnet-drc2.scm]

How can I get the system to find the /usr/local/* stuff?

Thanks,
Levente

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


-- 
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: gnetlist crash

[Peter TB Brett]

On Friday 12 November 2010 23:37:18 Levente Kovacs wrote:
> Hi all,
> 
> 
> I could make gnetlist crash with the following command:
> 
> gnetlist -q -g gsch2pcb -o pcb/if_card.new.pcb -m gnet-
gsch2pcb-tmp.scm
> sch/if_card.sch sch/ps.sch

Hi,

Are you able to narrow it down to a minimal testcase at all?

Also, the stack trace would be more helpful if you installed the -
dbg packages for libguile and libc. I'm not sure how to do that on 
Debian, I'm afraid.

Thanks!


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

gEDA-user: gnetlist crash

[Levente Kovacs]

Hi all,


I could make gnetlist crash with the following command:

gnetlist -q -g gsch2pcb -o pcb/if_card.new.pcb -m gnet-gsch2pcb-tmp.scm 
sch/if_card.sch sch/ps.sch

backtrace:

#0  __strcmp_sse2 () at ../sysdeps/x86_64/multiarch/../strcmp.S:99
#1  0x77b97bad in g_get_attrib_value_by_attrib_name () from 
/usr/lib/libgeda.so.38
#2  0x778c1f1c in ?? () from /usr/lib/libguile.so.17
#3  0x778c15e4 in ?? () from /usr/lib/libguile.so.17
#4  0x778c1b68 in ?? () from /usr/lib/libguile.so.17
#5  0x778c4456 in scm_eval () from /usr/lib/libguile.so.17
#6  0x77913c9f in scm_c_catch () from /usr/lib/libguile.so.17
#7  0x77b9437d in g_scm_eval_protected () from /usr/lib/libgeda.so.38
#8  0x004072d0 in ?? ()
#9  0x00405661 in ?? ()
#10 0x00407359 in ?? ()
#11 0x0040749e in ?? ()
#12 0x00404488 in ?? ()
#13 0x778d7dff in ?? () from /usr/lib/libguile.so.17
#14 0x778ae93a in ?? () from /usr/lib/libguile.so.17
#15 0x77913c9f in scm_c_catch () from /usr/lib/libguile.so.17
#16 0x778aedab in scm_i_with_continuation_barrier () from 
/usr/lib/libguile.so.17
#17 0x778aee40 in scm_c_with_continuation_barrier () from 
/usr/lib/libguile.so.17
#18 0x77912d04 in scm_i_with_guile_and_parent () from 
/usr/lib/libguile.so.17
#19 0x778d7db5 in scm_boot_guile () from /usr/lib/libguile.so.17
#20 0x00403ef3 in ?? ()
#21 0x77032c4d in __libc_start_main (main=, 
argc=, ubp_av=, 
init=, fini=, rtld_fini=, stack_end=0x7fffe478)
---Type  to continue, or q  to quit---
at libc-start.c:228
#22 0x00402839 in ?? ()
#23 0x7fffe478 in ?? ()
#24 0x001c in ?? ()
#25 0x000a in ?? ()
#26 0x7fffe732 in ?? ()
#27 0x7fffe744 in ?? ()
#28 0x7fffe747 in ?? ()
#29 0x7fffe74a in ?? ()
#30 0x7fffe753 in ?? ()
#31 0x7fffe756 in ?? ()
#32 0x7fffe76a in ?? ()
#33 0x7fffe76d in ?? ()
#34 0x7fffe783 in ?? ()
#35 0x7fffe793 in ?? ()
#36 0x in ?? ()

I'm on Debian testing. I can send schematics on request. gEDA/gschem version
1.6.1.20100214.

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: Problems compiling PCB Release 20100929

[Colin D Bennett]

On Wed, 10 Nov 2010 20:46:12 -0500
d...@umich.edu wrote:

> P.S. Will my Ubuntu 10.04 system get confused if I install both the 
> Synaptic package of pcb along with the compiled version?

You should look at the 'prefix' where pcb is configured for
installation.  Don't use a prefix of '/usr' since that will (1) stomp
on files installed by the .deb version installed by the Ubuntu
package manager, and (2) I never, ever install any hand-compiled
program in /usr since you will totally lose track of what you have
manually installed in that enormous, fairly flat namespace.

You can probably use a prefix of /usr/local successfully, and then
things will probably be in your PATH by default, (/usr/local/bin comes
before /usr/bin in the default Ubuntu path).  However, even
though /usr/local avoids stomping on managed packages, it is still like
a big dumping ground that is very unorganized.  Good luck trying to
clean up old version of programs installed there...

I use the following specific method of organizing manually installed
packages.  You may prefer to eliminate the VERSION level of hierarchy
and use just /opt/pcb as the prefix, but I have found it very useful
and not at all cumbersome to allow multiple versions to be installed
simultaneously.

(1) I install all non-Ubuntu-managed programs
into /opt/PACKAGENAME/VERSION.  For instance, when building pcb, I use
a command like

  ./configure --prefix=/opt/pcb/20091103

This will create a hierarchy under /opt/pcb/20091103 with 'bin' and
'share' directories.

(2) I create a symbolic link to '20091103' at /opt/pcb/current.  Then
if I have multiple pcb versions installed under /opt/pcb, I can just
have /opt/pcb/current/bin in my PATH and the currently selected pcb
version will be executed.

(3) Put this in your .profile if you often run pcb from the command
line: PATH="/opt/pcb/current/bin:$PATH"
Otherwise you can add a Gnome/KDE icon to your programs menu or launch
bar that runs /opt/pcb/current/bin/pcb.

Regards,
Colin


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

gEDA-user: New branch of PCB

[Stephen Ecob]

Hello all,

I've made a branch of PCB.  The intent of the branch is to aid in the
debugging and tuning of PCB's autorouter and PCB's trace optimiser.

Motivation
Having laid out a couple of boards with PCB 20091103 I became aware of
some bugs in the autorouter that made the job difficult:
1 The autorouter was generating traces that the trace optimiser was
often refusing to miter.
2 The autorouter would sometimes generate traces that violated DRC by
being too close to other copper.
3 The autorouter would sometimes "route on top of itself".  The
generated traces were valid, but ugly and inefficient.
Whilst investigating these bugs I discovered that PCB20081128 didn't
seem to have bug 1 or bug 3.  I also discovered that the 2008 version
often gave better autorouting results for my board (fewer unrouted rats).
Unfortunately I didn't have enough time to debug the 20091103
autorouter.

Action
I have created a branch of git HEAD that has the following features:
* Resurrects the autorouter as it was in 2008, allowing it to be run
alongside the git HEAD autorouter.
* By default the autorouter action now runs git HEAD autorouter
followed by the 2008 autorouter and then chooses the best result.
* Results of both autorouters are saved alongside the current pcb to
allow visual inspection etc.
 So if your current pcb is "foo.pcb" you'll also see "foo-New.pcb" and
"foo-2008.pcb" after autorouting.

Installation
git clone git://repo.or.cz/geda-pcb/see.git
cd see
./autogen.sh
./configure
make
src/pcb

Desired community response
* If you're working on a PCB, please give this branch a try and let us
know how the two autorouters compare for your board.  The easiest
way is to post the messages from PCB's message log window about
how the two autorouters are performing.  Typical messages look like this:

AutoRoute() added 878.1" wire & 1304 vias in 715sec. 201 rat lines remaining
AutoRoute2008() added 783.1" wire & 1188 vias in 391sec. 112 rat lines remaining
Keeping results from AutoRoute2008()

* If you're happy to share your PCB then let me know.  I'm building up
a set of reference PCBs to allow benchmarking.  The ones I have so
far are located in the new "examples" folder.  "examples/downloaded"
has original PCBs (as downloaded) "examples/notraces" has the PCBs
with existing traces and planes removed to allow autorouter trials.

Notes
* autorouting now breaks undo -> please save your PCB somewhere safe
before experimenting with this branch
* A menu checkbox "Settings->Disable 2008 autorouter" is provided to
disable the dual autorouter approach.  When checked only the normal
(git HEAD) autorouter will be used.

Best Regards,
Stephen Ecob


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

Re: gEDA-user: NGspice and GNUcap Non-Linear Dependent Sources

[clif]

Thanks for the clarification John,
and sorry about the munged subject line.

I would like to take a stab at Summarizing this if I can, I'm not sure 
it's completely accurate, so anyone should feel free to make corrections.


Different versions of spice use different methods of modeling non-linear 
dependent sources, Eg. ASRC, B, E, G, F, H, etc...


Some like NGspice use arbitrary expressions with conditionals, others like 
GNUcap use polynomials and curve fitting. The POLY function seems to be 
the least common denominator of these, though Spice3 doesn't support them. 
Polynomials were the first tool used to approximate non-linear 
relationships because they are well behaved and spice can easily find the 
derivative at a point which is used in the numerical solutions. The down 
side is you have to do some extra work with other tools to get the 
coefficients for your polynomial description.


As John points out below, common problems with polynomial approximations 
are:


1. They rapidly become useless outside a limited domain. BSIM models are 
indeed prone to unphysical behavior at operating points outside the domain 
of their approximations because they use polynomial adjustments for some 
computations.


2. It takes a lot of terms to do a decent approximation of a function 
whose shape isn't very "polynomial like"


The other method is to use an arbitrary expression with something like 
if-then-else functionality or the piece wise linear functions. This is 
simpler to formulate but incurs the risk of discontinuities which can 
cause serious convergence problems. However they are much more convenient 
for hacking something together.


A lot of effort has gone into having the best of both worlds. The PWL 
functions often use small curves to smooth the transition from one 
derivative to the next. and the expressions using the if-then-else 
functions are forced to make gradual transitions between different values. 
In general the libraries use polynomial approximations where they can and 
constrain them to areas where they are useful. Examples of this in GNUcap 
are the fit and table statements.


However, if you want to try out your models in other spice versions you'll 
probably want to do the extra work to describe their behavior in terms of 
the poly statement which unfortunately is not documented very well in 
ngspice or gnucap. Here is one place it is:


http://newton.ex.ac.uk/teaching/CDHW/Electronics2/userguide/secC.html

To do the curve fitting I suppose you could use tools like gnuplot, grace, 
or simfit.


Note that for NGspice to support POLYs you need to set that compile time 
option see:

http://www.brorson.com/gEDA/SPICE/x496.html

Clif



Date: Fri, 12 Nov 2010 08:28:06 -0700
From: John Doty 
Subject: Re: gEDA-user: geda-user Digest, Vol 54, Issue 32
To: gEDA user mailing list 
Message-ID: 
Content-Type: text/plain; charset=us-ascii


On Nov 11, 2010, at 9:58 PM, c...@eugeneweb.com wrote:


You can configure ngspice to support POLY. See
http://www.brorson.com/gEDA/SPICE/x496.html.


Yes but there isn't much in the way of examples on how to use them.


Are POLYs really that much better at solving convergence problems to
be worth the extra trouble? Is there a good into or howto on how to
use them?


There is a vast literature on the subject of constructing polynomial
approximations to functions. Google for "polynomial approximation".
You'll never be able to digest it all.


True, but that dosn't help with for exmaple how to make models for
multiple variables. Apparently you can say something like POLY(2) or
POLY(3) but then how do you list the values? In Gnucap it seems you
list the coeficent of X^0 (1) but a lot of models start with X^1. It
would be helpfull to have a howto that described the best practices for
all of this with some example problems.


http://newton.ex.ac.uk/teaching/CDHW/Electronics2/userguide/secC.html



Also some discussion on when to use them vs arbituray expressions as in
B sources. Naively one might assume that becuase they should be
well behaived functions that each point would have a usable first or
even second derivative, and this would help convergance. Though here is
a quote from the NGspice manual Chapt 12.2.7 BSIM1 model (level 4):

"A known problem of this model is the negative output conductance and
the convergence problems, both related to poor behavior of the
polynomial equations."


Common problems with polynomial approximations:

1. They rapidly become useless outside a limited domain. BSIM models are
indeed prone to unphysical behavior at operating points outside the
domain of their approximations because they use polynomial adjustments
for some computations.

2. It takes a lot of terms to do a decent approximation of a function
whose shape isn't very "polynomial like".



So it's not even obvious that they will perform better. Are they there
just to support legacy models, or are there times when they are the
best tool we

Re: gEDA-user: Comments on pcb's g-code

[jbump]

Sorry that LPKF stuff is off-topic but I just figured out a way to 
make tabs on boards that might help someone.  There is a button in 
circuit cam to calculate and draw breakout-tab cutting outlines but it 
flat-out doesn't work for me so I'm going to talk about the harder way.


Draw your desired board outline.  Decide on which width routing bit 
you're going to use.  I'm going to assume you're using a 1mm router, 
which is 40 mils in diameter.  Draw a second board outline, outside of 
your existing board outline, such that the width between the copper 
edges is 40 mils.  Typically I draw board outlines 10mils thick, so 
that'd be 50 mils center-to-center offset.  Draw the outer outline with 
gaps that are 120 mils wide.  That way when it's routed there will be 
120mils - 2x(40mils router width) = 40 mils of uncut board material 
holding the board into the uncut surrounding material.




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

Re: gEDA-user: comments on pcb's g-code exporter

[jbump]

On page 1 of the LPKF brochure (http://www.lpkfusa.com/datasheets/ prototyping/rp_brochure.pdf ), it shows a screenshot of their pcb artwork software. The thick grey traces are used to route the border of the part. I noticed the breaks in the trace in order to create attachment tabs, which you can see in the picture to the right of the mill making some boards. You could have a field in the g-code export window where you can choose a layer from pcb, which contains the traces for the border routing operation. The user can customize with a simple series of thick (or thin) traces exactly what shape they want the pcb border to be, i.e. with or without tabs, what diameter endmill to use, etc. 



This layer is there already, it's the one named "outline", all lower  

case. What isn't there is code to calculate the offset of the lines
and polygons on this layer, as I couldn't find existing functions in
the remaining pcb source code and I lack the resources to write it
myself.

I use Circuit Cam to convert gerbers into LPKF files.  It works quite 
well: offsets are all okay so everything shows up superimposed.
One thing I found that might be useful to anyone else doing this 
(which should be most people using an LPKF since they supply Circuit 
Cam with the machine controller) is that CC doesn't correctly import 
gerbers from PCB because PCB (kindly) includes a layer name assignment 
in each gerber, with a line like:

%LNFRONT*%
about 10-15 lines from the start.  CC imports this into a layer called 
FRONT even if you instruct it to assign that film to CC's TopLayer, and 
then can't find the objects when it tries to insulate it.

Delete the line in each gerber and it'll import correctly.
Likewise, I have an OUTLINE layer and that imports into BoardOutline 
and CC correctly assigns that for outside cutting (once I delete the 
layer name instruction.)
This is CircuitCam's problem, not PCB's, but that's the quickest 
workaround I've found.


By the way, the tabs idea in the original post won't work.  From the 
original post: "it shows a screenshot of their pcb artwork software. 
The thick grey traces are used to route the border of the part."
The gerber has a board outline.  Once you process it in CircuitCam, CC 
produces the gray trace as it calculates the centerline of the router 
you choose, so that feature is CC-dependent.  (It'll be a different 
routing path if you're using a 2mm router bit, rather than the standard 
1mm router bit.)  The board outline is all you need to give to CC.  
Breaking it up into segments is going to give CC some troubles because 
it will calculate a route that surrounds all the outlines -- in other 
words, it will calculate a cutting-outside route around the 
circumference of every line segment, meaning it'll route into the 
inside of the board, leaving nothing but a nice 10 mil wide border of 
copper around the outside of your board unrouted.  So that's not going 
to make shaker tabs like you want.  (I tried this, is how I know.)
It'd be nice to know how to produce tabs for the LPKF through Circuit 
Cam, so if anyone has run into this I'd love to know.




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

gEDA-user: EDIF: Found some ancient books. Any use to you?

[Dave N6NZ]

I discovered a box of books that never got unpacked after the last 
rearrangement of my home office.  Among these, I found several EDIF-related 
books.  Since I long ago stopped giving a rat's rear end about EDIF, I offer 
them to the group.  I'm guessing I could stuff them into a USPS flat-rate 
mailer and get them about anywhere in the USA for about US$8.00 -- not sure 
about cheap international shipping options.  You can have them for the cost of 
shipping.  These books are about 20 years old, so to the extent EDIF has 
evolved since 2.0.0, YMMV.   I don't follow EDIF any more, in fact I will run 
quickly in the other direction at it's mere mention, so I can't comment on 
their actual utility today.  Contact me off-list if you want to save these from 
the fireplace.

EIA-584: Electronic Design Interchange Format Version 2 0 0
EIA EDIF/AG-1: Applications Guide: Using EDIF 2 0 0 For Schematic Transfer
EDIF Question and Answers Volumes I,II,III, and IV, Prepared for the Design 
Automation Conference 1991
EIA/EDIF-1 Introduction to EDIF, Vol 1
EIA/EDIF-2 Introduction to EDIF, Vol 2

-dave




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

Re: gEDA-user: PCB+GL notes on VBOs

[Bert Timmerman]

Hi all, 

> -Original Message-
> From: geda-user-boun...@moria.seul.org 
> [mailto:geda-user-boun...@moria.seul.org] On Behalf Of Richard Barlow
> Sent: Friday, November 12, 2010 3:00 PM
> To: gEDA user mailing list
> Subject: Re: gEDA-user: PCB+GL notes on VBOs
> 
> Hi,
> 
> On Fri, 2010-11-05 at 09:46 +, Peter Clifton wrote:
> > 1. My VBOs and arrays are pretty large buffers, to fit lots 
> of geometry.
> ...
> > So.. we have a large buffer. That is a large chunk of 
> graphics memory 
> > to be requesting all the time. I think that contributes if the card 
> > doesn't have a decent chunk free yet.
> 
> I did a little bit of investigation and I suspect this is the 
> culprit to everyone's poor performance.
> 
> I ran the power-hw board on my machine and achieved around 85FPS.
> Felipe ran the same board on his machine and achieved around 18FPS.
> 
> My graphics card has 1GB of VRAM, Felipe's has 256MB (I 
> couldn't easily compare this to other people's results as not 
> many people said what card/driver they were using). I have 
> tried quadrupling the size of the VBO and now get around 
> 17FPS, which is considerably less than a quarter of my 
> previous result and almost exactly the same as what Felipe got.
> 
> I would say that this indicates that the large size of the 
> buffer is to blame for the speed problems if everyone else 
> has cards with ~256MB of VRAM and therefore the driver is 
> having to swap out part of the buffer into system memory.
> 
> 
> NB: I ran the above test with the larger buffer on code 
> before commit 0fa243b4bf which seems to change how the buffer 
> allocation is performed.
> I have tried running it with the quadrupled buffer on the 
> head of that branch and see no drop in performance any more. 
> I still think my analysis stands though if people don't have 
> enough VRAM to hold the size of the buffer used by the 
> power-hw board. 
> 
> Richard
> 

FWIW, a large amount of graphics memory is one thing, my 256 Mb graphics
memory is shared memory which is contributing to the total performance
equation.

I still have to start the prcess of fine tuning modelines and BIOS to get
the max performance wrung out of the HW.

Kind regards,

Bert Timmerman.




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

Re: gEDA-user: geda-user Digest, Vol 54, Issue 32

[John Doty]

On Nov 11, 2010, at 9:58 PM, c...@eugeneweb.com wrote:
>> 
>> You can configure ngspice to support POLY. See 
>> http://www.brorson.com/gEDA/SPICE/x496.html.
> 
> Yes but there isn't much in the way of examples on how to use them.
> 
>>> Are POLYs really that much better at solving convergence problems to be 
>>> worth the extra trouble? Is there a good into or howto on how to use them?
>> 
>> There is a vast literature on the subject of constructing polynomial 
>> approximations to functions. Google for "polynomial approximation". You'll 
>> never be able to digest it all.
> 
> True, but that dosn't help with for exmaple how to make models for multiple 
> variables. Apparently you can say something like POLY(2) or POLY(3) but then 
> how do you list the values? In Gnucap it seems you list the coeficent of X^0 
> (1) but a lot of models start with X^1. It would be helpfull to have a howto 
> that described the best practices for all of this with some example problems.

http://newton.ex.ac.uk/teaching/CDHW/Electronics2/userguide/secC.html

> 
> Also some discussion on when to use them vs arbituray expressions as in B 
> sources. Naively one might assume that becuase they should be well behaived 
> functions that each point would have a usable first or even second 
> derivative, and this would help convergance. Though here is a quote from the 
> NGspice manual Chapt 12.2.7 BSIM1 model (level 4):
> 
> "A known problem of this model is the negative output conductance and the 
> convergence problems, both related to poor behavior of the polynomial 
> equations."

Common problems with polynomial approximations:

1. They rapidly become useless outside a limited domain. BSIM models are indeed 
prone to unphysical behavior at operating points outside the domain of their 
approximations because they use polynomial adjustments for some computations.

2. It takes a lot of terms to do a decent approximation of a function whose 
shape isn't very "polynomial like".

> 
> So it's not even obvious that they will perform better. Are they there
> just to support legacy models, or are there times when they are the best tool 
> we have?

Most special function libraries use polynomial approximations heavily, so if 
you're using B you're almost certainly using polynomials implicitly. The 
advantage of the library functions is that they've generally been designed to 
use a given polynomial only within the domain in which it behaves well.

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: PCB+GL notes on VBOs

[Richard Barlow]

Hi,

On Fri, 2010-11-05 at 09:46 +, Peter Clifton wrote:
> 1. My VBOs and arrays are pretty large buffers, to fit lots of geometry.
...
> So.. we have a large buffer. That is a large chunk of graphics memory to
> be requesting all the time. I think that contributes if the card doesn't
> have a decent chunk free yet.

I did a little bit of investigation and I suspect this is the culprit to
everyone's poor performance.

I ran the power-hw board on my machine and achieved around 85FPS.
Felipe ran the same board on his machine and achieved around 18FPS.

My graphics card has 1GB of VRAM, Felipe's has 256MB (I couldn't easily
compare this to other people's results as not many people said what
card/driver they were using). I have tried quadrupling the size of the
VBO and now get around 17FPS, which is considerably less than a quarter
of my previous result and almost exactly the same as what Felipe got.

I would say that this indicates that the large size of the buffer is to
blame for the speed problems if everyone else has cards with ~256MB of
VRAM and therefore the driver is having to swap out part of the buffer
into system memory.


NB: I ran the above test with the larger buffer on code before commit
0fa243b4bf which seems to change how the buffer allocation is performed.
I have tried running it with the quadrupled buffer on the head of that
branch and see no drop in performance any more. I still think my
analysis stands though if people don't have enough VRAM to hold the size
of the buffer used by the power-hw board. 

Richard


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: Comments on pcb's g-code exporter & HeeksCAD/HeeksCNC FOSS program for pcb milling

[Markus Hitter]

Am 12.11.2010 um 01:58 schrieb d...@umich.edu:


Markus,

That is good news.

Could someone tell be how to add these files to the current  
pcb-20100929 source download and recompile?


Use

git am < 00xxx.patch

Recompilation is done as before, not even a configure run is needed.


On page 1 of the LPKF brochure (http://www.lpkfusa.com/datasheets/ 
prototyping/rp_brochure.pdf ), it shows a screenshot of their pcb  
artwork software. The thick grey traces are used to route the  
border of the part. I noticed the breaks in the trace in order to  
create attachment tabs, which you can see in the picture to the  
right of the mill making some boards.


You could have a field in the g-code export window where you can  
choose a layer from pcb, which contains the traces for the border  
routing operation. The user can customize with a simple series of  
thick (or thin) traces exactly what shape they want the pcb border  
to be, i.e. with or without tabs, what diameter endmill to use, etc.


This layer is there already, it's the one named "outline", all lower  
case. What isn't there is code to calculate the offset of the lines  
and polygons on this layer, as I couldn't find existing functions in  
the remaining pcb source code and I lack the resources to write it  
myself.


So, feel free to add this. The 0023 patch roughly shows a good place  
to start.



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