On Thu, Nov 20, 2008 at 4:21 AM, Steve Meier [EMAIL PROTECTED] wrote:
1 in = 25.3972 mm not exactly 25.4 but close enough for layout
work if you use high enough precision.
I recall one of my physics professors stating the same thing, but I
can't find anything to back up the claim. What
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
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
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 impossible
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 nearly
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
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
does
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 in
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 pad, but
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.
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),
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.
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 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
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.
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 very
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 to
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 could
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 for a
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.
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 can avoid
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
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 below
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
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,
unless you can
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 a
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 end up with
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 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 point...
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 future
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.01 mil is
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 and
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-user
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
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 =
35 matches
Mail list logo
