Hi Ben and all,
On Wed, 2008-11-19 at 22:35 -0800, Ben Jackson wrote:
> On Thu, Nov 20, 2008 at 12:55:51AM -0500, DJ Delorie wrote:
> >
> > > I can't repro the MM line garbage.
> >
> > I can. Set a 0.25mm grid and draw a bunch of lines that *look* like
> > plain 45 lines (i.e. no obvious corner
Hi DJ,
On Thu, 2008-11-20 at 00:55 -0500, DJ Delorie wrote:
> > I can't repro the MM line garbage. I downloaded bx.pcb and while
> > there is a single point line IN the file (out in space) I can't get
> > points by deleting any of the lines already in the file or by
> > drawing some in the grid
On Thu, Nov 20, 2008 at 12:55:51AM -0500, DJ Delorie wrote:
>
> > I can't repro the MM line garbage.
>
> I can. Set a 0.25mm grid and draw a bunch of lines that *look* like
> plain 45 lines (i.e. no obvious corner, like you'd often get with _/,
Ah, ok, I drew a zillion lines in different modes
> I can't repro the MM line garbage. I downloaded bx.pcb and while
> there is a single point line IN the file (out in space) I can't get
> points by deleting any of the lines already in the file or by
> drawing some in the grid saved with the file and then deleting them.
I can. Set a 0.25mm gri
(sorry, I deleted the mail on this and got the ref from the web archive)
I can't repro the MM line garbage. I downloaded bx.pcb and while there
is a single point line IN the file (out in space) I can't get points by
deleting any of the lines already in the file or by drawing some in the
grid save
Interesting.
OK I think for PCB purposes 1 inch is exactly 2.54 cm by definition.
"1959 the national standards laboratories of the English-speaking
nations agreed to standardize the relation between the yard and the
meter"
For geodetic data here in the US the traditional value of 1 yard =
3600/
On Nov 19, 2008, at 7:21 PM, Steve Meier wrote:
> 1 in = 25.3972 mm not exactly 25.4 but close enough for layout
> work if you use high enough precision.
Where'd you get that? I have multiple references that say it's 25.4
*exactly*. To even be able to measure distances of order 1 inch
1 in = 25.3972 mm not exactly 25.4 but close enough for layout
work if you use high enough precision.
25.4 to 1 might not be close enough if you are trying to put a satellite
in orbit around mars.
Steve M.
On Wed, 2008-11-19 at 18:58 -0700, John Doty wrote:
> On Nov 19, 2008, at 4:08 PM
On Wed, 2008-11-19 at 18:58 -0700, John Doty wrote:
> On Nov 19, 2008, at 4:08 PM, Peter Clifton wrote:
> >> 2^32 nm is about 4.3 meters, large enough for any PCB I've ever seen.
> >> 2^64 nm is about 0.12 astronomical unit ;-)
> >
> > Well.. I can't recall if we use signed or unsigned numbers thr
> Ok, here's a fragment of the board I first noticed the problem on. Press
> "=" to optimise it, and you'll see lots of runt segments appear, then
> the verticals start to be bent of of whack (violating DRC rules).
Yeah, that one's borken.
___
geda-us
On Thu, Nov 20, 2008 at 1:09 AM, John Doty <[EMAIL PROTECTED]> wrote:
>
>> Agreed. I didn't mean gnetlist doesn't work with hierarchical designs
>> at all - it just didn't produce any useful results last time I tried
>> it.
>
> You haven't clearly stated what your problem was. I've done both
> hier
> Flip to the back-side (so you can see added tracks), and press "=". Note
> that a new line-segment is added. Is that desirable?
It's intentional at least. It connects all electrically connected
traces to the logical center of the pin/pad. That way, all the line
"corners" are at the same spot
On Nov 19, 2008, at 4:08 PM, Peter Clifton wrote:
> On Wed, 2008-11-19 at 15:44 -0700, John Doty wrote:
>
>> If you insist on no artifacts, it's zero.
>>
>> If you round imperial units to the nearest 0.01 mil, you have no
>> additional roundoff error if your fundamental unit is 1 nm, because
>> 0
On Nov 19, 2008, at 5:17 PM, r wrote:
> Agreed. I didn't mean gnetlist doesn't work with hierarchical designs
> at all - it just didn't produce any useful results last time I tried
> it.
You haven't clearly stated what your problem was. I've done both
hierarchical VLSI designs (SPICE style: ge
On Wed, Nov 19, 2008 at 11:54 PM, John Griessen <[EMAIL PROTECTED]> wrote:
> Peter Clifton wrote:
>
>> That simply is not true. The netlister _does_ work with hierarchical
>> designs, but typically, our back-ends target a flat output, such as for
>> PCB.
>
> Don't worry about him. I suspect he's o
On Wed, Nov 19, 2008 at 2:49 PM, Peter Clifton <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-11-19 at 06:04 -0800, Steve Meier wrote:
>> Peter,
>>
>> I believe that gnetlist takes in a hierarchical series of schematics and
>> flattens the schematics into a flat netlist that may then be exported
>> into
Am Mittwoch, den 19.11.2008, 23:08 + schrieb Peter Clifton:
>
> Save the files out with native units, e.g. "123456000 nm"
>
For practical purposes nm base unit seems to be a fine solution, because
then no rounding is necessary.
Academically one can still see some problems:
What if in far fu
Peter Clifton wrote:
> That simply is not true. The netlister _does_ work with hierarchical
> designs, but typically, our back-ends target a flat output, such as for
> PCB.
Don't worry about him. I suspect he's one of the poisonous people
you run across in open software development. haven't lo
Am Mittwoch, den 19.11.2008, 21:50 +0100 schrieb Stefan Salewski:
> Am Mittwoch, den 19.11.2008, 21:29 +0100 schrieb Stefan Salewski:
> >
>
> OK, I think my description was correct, but indeed I used a smaller
> symbol and a smaller footprint for this connection.
I forgot one point: For a perma
On Wed, 2008-11-19 at 15:44 -0700, John Doty wrote:
> If you insist on no artifacts, it's zero.
>
> If you round imperial units to the nearest 0.01 mil, you have no
> additional roundoff error if your fundamental unit is 1 nm, because
> 0.01 mil is *exactly* (by definition) 254 nm.
Good poin
On Nov 19, 2008, at 11:22 AM, Steve Meier wrote:
> The Pads ASCII format uses a base unit of 0.0002624671916 inches
> which is 1.054 nM
>
> Converting it to metric causes an error of about 0.5 nM
>
> The PCB base unit is 0.1 inches
>
> Converting it to metric causes an error of 19.7 n
Am Mittwoch, den 19.11.2008, 22:05 + schrieb Peter Clifton:
>
> Fine over a small component, however if you're trying to position
> mechanical items on a large board, you don't want accumulated drift.
> (This said.. perhaps it would still be acceptable if the internal units
> are small enough)
On Wed, 2008-11-19 at 22:02 +, Peter Clifton wrote:
> On Wed, 2008-11-19 at 09:50 -0500, DJ Delorie wrote:
>
> > The optimizer should never turn a good board into a bad board, that's
> > always a bug. The logic in the optimizer isn't that simple, though,
> > so fixing said bugs may be tricky.
On Wed, 2008-11-19 at 22:59 +0100, Stefan Salewski wrote:
> Am Mittwoch, den 19.11.2008, 16:37 -0500 schrieb DJ Delorie:
> > > Important may be the correct mapping of user input to internal pcb
> > > coordinates.
> >
> > The problem is rounding - some grid points round up, some round down.
> > You
On Wed, 2008-11-19 at 09:50 -0500, DJ Delorie wrote:
> The optimizer should never turn a good board into a bad board, that's
> always a bug. The logic in the optimizer isn't that simple, though,
> so fixing said bugs may be tricky. Sample boards (and/or patches ;)
> welcome.
Not sure if this is
Am Mittwoch, den 19.11.2008, 16:37 -0500 schrieb DJ Delorie:
> > Important may be the correct mapping of user input to internal pcb
> > coordinates.
>
> The problem is rounding - some grid points round up, some round down.
> You end up with off-by-one bugs, no matter how "precise" you are,
> unles
> 1. Really high resolution integer coordinate space.
> Reduces available board dimensions due to size of integers.
Not if you enlarge the integers to match. Do any compilers the gEDA
tools care about lack a 64-bit integer datatype?
/~\ The ASCII Mouse
\ / Ribbon Camp
On Wed, 2008-11-19 at 16:35 -0500, DJ Delorie wrote:
> > We would presumably store value and units.
>
> I won't contemplate this without some C++ class hiding the ugly
> details. I've seen a magazine article about it, there are ways to do
> it right that are clean and easy to understand. The be
> Is it not just a matter of altering the code which makes the 45 degree
> constraint?
It might work to just allow +- 0.1 degree. I haven't tried it.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/ged
On Wed, 2008-11-19 at 16:37 -0500, DJ Delorie wrote:
> > Important may be the correct mapping of user input to internal pcb
> > coordinates.
>
> The problem is rounding - some grid points round up, some round down.
> You end up with off-by-one bugs, no matter how "precise" you are,
> unless you ca
> Important may be the correct mapping of user input to internal pcb
> coordinates.
The problem is rounding - some grid points round up, some round down.
You end up with off-by-one bugs, no matter how "precise" you are,
unless you can avoid the need to round completely.
Peter Clifton <[EMAIL PROTECTED]> writes:
> 1. Really high resolution integer coordinate space.
Specificially, high enough to be an whole fraction of our existing
units.
> Reduces available board dimensions due to size of integers.
Yup.
> (Or go to floating-point.. -> Still limited precision f
Am Mittwoch, den 19.11.2008, 21:00 + schrieb Peter Clifton:
Thank you for your proposed solutions.
> One final thought.. could we round the width / height of the line to
> internal coordinate units, and (say), the start-point, rather than both
> end-points? That way, the line-drawing code cou
On Wed, 2008-11-19 at 13:32 -0500, DJ Delorie wrote:
> I think the problem is that mm grid points are not exactly on 1/100mil
> coordinates, so two mm grid points that look diagonally opposite each
> other may not be exactly diagonal in 1/100mil space.
>
> The only way to "fix" this is to change t
Am Mittwoch, den 19.11.2008, 21:29 +0100 schrieb Stefan Salewski:
>
> My symbols and footprints are available at gedasymbols, I think called
> SolderJumper.
>
OK, I think my description was correct, but indeed I used a smaller
symbol and a smaller footprint for this connection. I forgot to uploa
Am Mittwoch, den 19.11.2008, 20:35 +0100 schrieb Levente Kovacs:
> Hi,
>
> BTW. It would be nice to have a clean concept of starpoints in gEDA/PCB.
>
Yes.
I had the same problem. Have GND and AGND in schematic, and want to make
a connection at one point in layout. I tried to make a footprint w
Am Mittwoch, den 19.11.2008, 21:00 +0200 schrieb Duncan Drennan:
> > The only way to "fix" this is to change to something other than
> > 1/100mil internal coordinates.
>
> Maybe more important is to figure out whether this needs to be fixed.
These garbage points and not properly joined lines are
Hi,
Ok, I am doing my first layout with more than one ground. So there are two GND
nets, GND, and AGND. I want to connect them together at one point, and
therefore I'd need a starpoint. In my day job, we have footprints for
starpoints. I've tried to create one by placing two pads on the top of ea
> The only way to "fix" this is to change to something other than
> 1/100mil internal coordinates.
Maybe more important is to figure out whether this needs to be fixed.
The effect that results is an irritation rather than board breaking.
If it did result in a short the netlister would detect that.
I think the base should be one Angstrom for two reasons. 1) that it
would be 10x the resolution of the pads. 2) According to wikipedia (with
the ångström being officially discouraged by both the International
Committee for Weights and Measures and the American National Standard
for Metric Practice)
The Pads ASCII format uses a base unit of 0.0002624671916 inches
which is 1.054 nM
Converting it to metric causes an error of about 0.5 nM
The PCB base unit is 0.1 inches
Converting it to metric causes an error of 19.7 nM
All I can figure out about why pads uses that weird number i
I think the problem is that mm grid points are not exactly on 1/100mil
coordinates, so two mm grid points that look diagonally opposite each
other may not be exactly diagonal in 1/100mil space.
The only way to "fix" this is to change to something other than
1/100mil internal coordinates.
Alterna
Am Mittwoch, den 19.11.2008, 14:54 + schrieb Peter Clifton:
>
> Indeed. Unfortunately, test-cases for these kind of things are to build
Indeed my example of lines connected to the 25 pin DSUB connector was
bad, because its pins have mil grid (I inserted it yesterday and was
assuming mm grid)
Hi Jesco,
On Mittwoch, 19. November 2008, Jesco Möller wrote:
> after having installed SuSE 10.3 RPMS for gattrib, gnetlist, gschem,
> gsymcheck, utils - each of version 1.4.1-1.1 - I get upon starting
> gschem the following error message:
Have you ignored any rpm requires when installing the pac
On Wed, Nov 19, 2008 at 12:27 PM, Peter Clifton <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-11-18 at 04:02 -0500, der Mouse wrote:
>> ITYPM DE9 and DA15; I've never seen a 9- or 15-position connector in a
>> DB shell (but I've often seen DE9 and DA15 miscalled DB9 and DB15).
>> But that aside,
>
> I
On Wed, 2008-11-19 at 09:50 -0500, DJ Delorie wrote:
> > The optimiser also sometimes ended up moving / deleting nodes in
> > line-segments, in such a way as to change the line segment's angle,
> > producing a new line which violated DRC, or in the occasional case,
> > shorted the track to another
> I often end up hitting that key by mistake (not sure why, but I do -
> perhaps because its near my laptop's "Delete" key), the "optimiser"
> then spends a good deal of CPU cycles wrecking my board in very
> subtle ways, such as adding those short stubby pieces of lines where
> I had ended on a p
On Wed, 2008-11-19 at 06:04 -0800, Steve Meier wrote:
> Peter,
>
> I believe that gnetlist takes in a hierarchical series of schematics and
> flattens the schematics into a flat netlist that may then be exported
> into a number of flat formats. In other words the net has been flattened
> before re
Yamazaki,
I have done a fair amount of work on hierarchical netlisting. However, I
run my own customized versions of libgeda and gnetlist. In my version,
each page is netlisted separately and thus a back end could be written
to retain the hierarchical information.
Steve Meier
On Tue, 2008-11-18
Peter,
I believe that gnetlist takes in a hierarchical series of schematics and
flattens the schematics into a flat netlist that may then be exported
into a number of flat formats. In other words the net has been flattened
before reaching the backend. Hierarchical information is retained in
refere
Am Mittwoch, den 19.11.2008, 15:44 +0200 schrieb Duncan Drennan:
>
> I drew a bunch of random lines (grid = 0.1mm) and then deleted them
> one at a time. On one corner a small trace was left over. Below are
> the .pcb line elements. You can see that the first Line is just
> 1/100th of a mil long
> I can not believe that this happens only to me -- if this is really
> unknown to other people I can made a layout with this garbage available.
> Problem is that I can give no description how to produce this garbage --
> it occurs. I will do some testing with mil grid and see if this problem
> doe
Am Mittwoch, den 19.11.2008, 13:09 + schrieb Peter Clifton:
>
> If you use the snap points properly, I've found no problems. (Sometimes
You may test yourself.
I have uploaded a copy of my layout to
http://www.ssalewski.de/tmp/
called bx.pcb.
For me it is very easy to produce these garbag
Am Mittwoch, den 19.11.2008, 14:54 +0200 schrieb Duncan Drennan:
> > After using pcb 20080202 (GTK) for more than hundred hours for the
> > current layout know, I think the mm issues are really the most important
> > bugs of this program. (If most of the footprints have mm grid, then it
> > is near
On Wed, 2008-11-19 at 14:54 +0200, Duncan Drennan wrote:
> > After using pcb 20080202 (GTK) for more than hundred hours for the
> > current layout know, I think the mm issues are really the most important
> > bugs of this program. (If most of the footprints have mm grid, then it
> > is nearly impos
> After using pcb 20080202 (GTK) for more than hundred hours for the
> current layout know, I think the mm issues are really the most important
> bugs of this program. (If most of the footprints have mm grid, then it
> is nearly impossible to use mil grid.) Fixing these mm rounding issues
> may be
I think every pcb user who uses mm grid will know this:
Often straight line segments end (or maybe start) with very short lines,
nearly point shaped.
I think this is related to mm rounding issue -- I reported and
investigated similar bugs when connecting line segments with same
direction, see
ht
On Wed, 2008-11-19 at 10:23 +, r wrote:
> Hi,
>
> I hit exactly same issues last time I tried to use gschem/gnetlist.
> The flow simply doesn't work with hierarchical designs (and yes, there
> is no notion of a "design library" in geda).
That simply is not true. The netlister _does_ work with
On Tue, 2008-11-18 at 04:02 -0500, der Mouse wrote:
> > I'm working on a project that cables several boxes together, which
> > signal each other using "dry contacts"; i.e. by closing or opening a
> > pair of wires. The interconnect cables all use D-sub connectors
> > (DB9, DB15, and DB25).
>
> IT
Hi,
I hit exactly same issues last time I tried to use gschem/gnetlist.
The flow simply doesn't work with hierarchical designs (and yes, there
is no notion of a "design library" in geda). If you are willing to
spend some time on it and contribute fixes to the flow that would be
great. On the other
60 matches
Mail list logo
