If I may, when I have a data sheet that has been designed in mm and it is a
fine pitch component I use a excel spread sheet to confirm the change over.
Here is an example

Millimeters     Meters  Inches  Mil (0.001 in)
0.001            1.000E-06   39.370E-06    0.039370
0.002            2.000E-06   78.740E-06    0.078740
0.003            3.000E-06   118.110E-06           0.118110I 


have not had a problem yet (knock on wood).

For what it's worth,

Ted

-----Original Message-----
From: Abd ul-Rahman Lomax [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 15, 2001 1:58 PM
To: Protel EDA Forum
Subject: Re: [PEDA] MM's VS Mils


At 08:41 PM 3/15/01 +1100, Les Grant wrote:

>Perhaps I have missed something here but are you implying that
>conversion from metric is exact but conversion from imperial is
>approximate? 1 inch = 1000 mil = 25.4mm exactly, both ways.

So conversion from inch to mm is exact. But what about the other way?

If Protel supported divisors for distances, i.e., the use of fractions, 
then one could get exact conversions in both directions, it would not 
matter. It would not be difficult to implement that, by the way. One would 
break the dimension field into two fields; the default for the second field 
would be 1, but if it was present and was not one, dimensions would be 
converted by division.

Remember that we are talking about database units, not necessarily what is 
displayed.

However, Protel presently uses a database unit of a small decimal fraction 
of an inch. I think it is one microinch, but it might be smaller than that; 
I've done some experimentation with this, but I don't remember the results 
right now. Actually, the units are mils, but there is then three decimal 
place precision. For a while there, the database was floating point, which 
was interesting, but I think they changed it back. Metric dimensions (in 
mm) are translated into the database units by dividing them by 0.0254. So 
if I enter 1 mm, it will become 39.370 mils, which is pretty accurate. But 
it is not exact; an error of approximately 0.078 microinch is introduced, 
which is 0.002 mm. When the number is translated back into mm, it becomes 
0.999998 mm. That is only 2 nanometers off, but, especially when 
accumulated, it can knock the displayed mm measurements off, as we 
frequently see.

However, the problem might also be addressed by intelligent rounding of the 
mm display. If the database precision is 1 microinch, we only have a real 
resolution in mm of 0.040 mm, so display of mm to three decimal places or 
beyond is meaningless. If the mm figures were rounded (not truncated) to 
two places I think that conversions within the 100 inch workspace would 
remain accurate; but I have not thoroughly investigated this. Intelligent 
rounding would avoid the necessity of changing and testing all the myriad 
routines which use locations.....


[EMAIL PROTECTED]
Abdulrahman Lomax
P.O. Box 690
El Verano, CA 95433

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
*
* To join or leave this list visit:
* http://www.techservinc.com/protelusers/subscrib.html
*                      - or email -
* mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum
*
* Contact the list manager:
* mailto:[EMAIL PROTECTED]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to