kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 10/11/2010 01:29 PM, Brian F. G. Bidulock wrote:
> Alex,
>
> On Mon, 11 Oct 2010, Alex G wrote:
>   
>> Please guys, stop arguing. I agree with changing the base unit system to
>> metric, and I have already voiced that opinion. No one tried to chop my
>> throat. If it makes sense to switch to metric why not do it?
>>
>> The real question is wether it makes sense.
>>     
> I have several 1000-ball BGAs on a metric pitch.  Every other ball is off
> its position by part of 1/10000th of an inch.  No problem?  Well when
> pulling dogbones for BGA breakout, I wind up with about 1000 0.1mil segments
> connecting the imperial gridded vias to the imperial gridded balls.  So
> I tried unlocking the 45-degree tracks pulling slightly off 45-degrees so
> that there were no 0.1mil segments.  Instead I got 1000 DRC errors (yeah,
> its tight in there), and a thousand 0.0mil segments.  Then there is the
> performance problems associated with drawing thousands of 0.1mil or 0.0mil
> traces.  Hard locking to a 10 nanometer minimum grid would remove all these
> problems.  Any time pads, pins or lands are on a metric pitch, the same
> problems arise.
>
> The maximum precision allowed by RS-274X is 6.6 for metric, so it makes
> sense to use 1 nanometer as the internal unit.
>   


Brian,

This is something I would not oppose.  Its clear we may need finer
granularity on the *internal* units.

In any case, this rounding problem is intolerable.  The internal units
are the grand unifier between the two or more types of real world units.

We should also support more than one type of real world units, by
mentioning them in the part or footprint.

Internally however, I'd like to work with the *internal* units.

One poster said something that I still wonder about, and that C++ cannot
reliably multiple and divide by 2.54 and do a round trip conversion
using the current internal unit granularity.

It is mind boggling that 2.54 and using a C++ double does not allow this
to happen.  I don't have time to test it, but I am wondering about it. 
Is this a problem with 64 IEEE float, or that we simply do not have
enough resolution in our internal units?

Dick