delorie.com/archives/browse.cgi   search  
Mail Archives: geda-help/2011/10/17/15:41:13

X-Authentication-Warning: delorie.com: mail set sender to geda-help-bounces using -f
X-Recipient: geda-help AT delorie DOT com
Subject: Re: [geda-help] Weeding out rounding-error dot/lines?
From: Richard Rasker <rasker AT linetec DOT nl>
To: geda-help AT delorie DOT com
In-Reply-To: <CDECA546-5520-4BF7-9CF9-96E5E54A7326@jump-ing.de>
References: <1318794799 DOT 9014 DOT 61 DOT camel AT localhost>
<CDECA546-5520-4BF7-9CF9-96E5E54A7326 AT jump-ing DOT de>
Organization: Linetec
Date: Mon, 17 Oct 2011 21:40:51 +0200
Message-Id: <1318880451.3789.27.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1-2.2mdv2008.1
Reply-To: geda-help AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-help AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

Op maandag 17-10-2011 om 12:47 uur [tijdzone +0200], schreef Markus
Hitter:
> Am 16.10.2011 um 21:53 schrieb Richard Rasker:
> 
> > I already defined a key binding for reporting net length, and now I
> > found that the mil/mm rounding error sometimes causes problems in an
> > insidious way: when an extra "mini-line" (dot) is created at a via or
> > bend point, and this point is subsequently dragged along the line
> > itself, the dot gets stretched into a line.
> 
> If you copy/paste existing lines instead of using the line tool, no  
> mini-lines will appear. Also, don't pick lines at the ends if you  
> don't want them to stretch.

The problem is that when laying down RAM data lines, I need to create
and stretch loops and serpentine traces in order to match line lengths.
Using existing lines in this process would make an already cumbersome
process almost impossible to complete.

And it's even rather trivial to create a script to find & destroy lines
below a certain length in a .pcb file -- just search for lines with both
X2-X1 and Y2-Y1 smaller than 2 units, like this one:

Line[48819 247638 48819 247637 600 1200 "clearline"]

The problem is that this isn't very handy, because I can only find the
dots after the fact, not while they're created -- and lurk around,
waiting to be stretched into lines, messing up length calculations.
A fix would be rather desirable.


The creation of these dots indeed seems to be caused by a metric
rounding error, and can be reproduced like this:
* Set the grid units to mm, with grid size = 0.1 mm
* Draw a horizontal line, e.g. from [10.0000 10.0000] to [12.0000
10.0000]
* Now move the cursor diagonally up from the end point, one step (0.1
mm) at a a time:

[12.1001 9.8999]: OK
[12.1999 9.8001]: OK
[12.2999 9.7000]: OK
[12.4000 9.5999]: OK
[12.5001 9.5001]: stub line
[12.5999 9.4000]: OK
...
[13.2001 8.8001]: stub line
...

It would seem that an inadvertent stub line is created when the last
digit in both coordinates is 1, when starting out from a point with
exact integer co-ordinates.

If desired, I can do some more trial and calculation, and determine at
which exact delta co-ordinate distances this occurs.

Thanks for your reply anyway,

Best regards,

Richard Rasker

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019