kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

Brian,

> Dick,
>
> On Fri, 25 Nov 2011, Dick Hollenbeck wrote:
>
>> *) Metric Board. This is a pcb board that has a great number of coordinates and
>> distances that happen to be some multiple of the BIU that is also a multiple of
>> a metric engineering unit such as micrometers.
>>
>> *) Imperial Board.  This is a pcb board that has a great number of coordinates and
>> distances that happen to be some multiple of the BIU that is also a multiple of
>> an imperial engineering unit such as mils or inches.
> What is the purpose of this distinction?  


The purpose was get folks to realize that there is basically no distinction, other than
the preponderance of the grid type used during layout.  Mission accomplished.

I removed these definitions, since my goal was accomplished in my list of questions to
Vladimir.


>> Format Strings:
>> ==============
>>
>> #if USE_DOUBLE_BFU
>> typedef double          BFU;
>> #define FMT_ENG         ".%6g"
>> #else
>> typedef long double     BFU;
>> #define FMT_ENG         ".%6Lg"
>> #endif
>>
>> A format string can then be built up using compile time concatenation of
>> strings, like this:
>>
>> fprintf( fp, "Value: " FMT_ENG " " FMT_ENG "\n", BFU( biu1 * scale), BFU( biu2 * scale ) );
> Format strings had better be at least "%.10g" so that no precision is
> lost when writing BFU to disk.

Agreed, good catch.   Any one that wants to play with this, C program below:


#include <limits.h>
#include <stdio.h>


int main( int argc, char** argv )
{
    int i = INT_MAX;
//    int i = 1;

    printf( "%.10g\n", (double) i );
}


>> Here are the required immediate need BOARD load functions:
>>
>> 1) Legacy to deci-mil loader. This loader uses a floating point scaling factor
>> of unity, since destination is a RAM BOARD using deci-mils as its BIU.
>>
>> 2) Legacy to nanometer loader. This loader uses a floating point scaling factor
>> of ________, since destination is a RAM BOARD using nanometers as its BIU, and
>> the source format is using deci-mils.
>>
>> 3) mm to nanometer loader.  This loader uses a floating point scaling factor
>> of 1000000, since the destination is a RAM BOARD using nanometers as its BIU.
>>
>> There is no need for a nm to deci-mil loader. (Once somebody saves a file in the
>> new format, that format is used going forward, or its backup in the old format.)
>>
>> Now duplicate the above 3 loader types for MODULEs.
> The foregoing makes it appear that all that has to be done to load a
> board or module that was saved in the old deci-mil format is to apply
> the (2540) scaling factor and one is done.  This is far from the case.
> The old format saves every metric spaced or sized part with pads in the
> wrong locations and incorrect sizes.  Simply applying a scaling factor
> results in every metric spaced pad being very precisely in the wrong
> location and very precisely the wrong size, and the conversion will have
> accomplished nothing.  This is true both of modules and boards.
>
> When I converted the internal unit to nanometers I provided a dialog on
> load of a deci-mil board that provided the user the option of resnapping
> points to a mixed grid and setting the minimum grid for imperial and
> metric snapping.  That is, every point that is off the minimum imperial
> grid and is within the deci-mil round-off error of the minimum metric
> grid would be resnapped to the metric grid when loading.  That's
> locations; the same was true for sizes of things.  Locations of things
> that are absolutely placed on the board (e.g. tracks, module positions)
> used the board axis for resnapping.  Locations of pads and other features
> within a module, used the module axis for resnapping.  Of course the
> user could decide not to resnap.
>
> I know of no other way of avoiding hand conversion of every module in
> the library, and hand conversion of every single feature on an existing
> board.  (Hand tweaking the position of 7000 board features is not really
> an option for me.  I do not have access to skilled workers with that low
> a standard of living.)
>
> Do you see the problem?  Now that the true position and size of metric
> things has been destroyed, it might require recreating everthing from
> scratch.
>
> --brian


Brian,

I agree with your assessment of the "metric offset" problem.  The best *solution* to it
remains debatable.

What I think is that to do this "moving of points back onto a metric grid" requires some
frail assumptions, one of which is where the hell is the origin of each grid fragment? 

I don't have the time for this, nor the inclination to assume this liability. 

What can be done however is that after we have a file format that can handle the increased
resolution, perhaps you can carve out some code that folks can use to doctor their boards
if they have this metric problem.   This would be a board fix up tool.

I also think there will be sites in my new loader and saver code where someone could
install such algorithms.  The plugin scheme means it is possible to save and load a board
in most any suitable format, Eagle, Altium, geda, whatever.

I will not be doing the "metric adjustments", at least not for free.

My "boards produced per lines of code contributed" ratio is the worst of anyone within
earshot of this project, and so now my sanity is now in full doubt.  That doubt is among
others, not me.  I know I am nuts.  So please be cognizant that this old horse has limits
on what it can give for free.


Dick