kicad-developers team mailing list archive

["Brian F. G. Bidulock" <bidulock@xxxxxxxxxxx>]

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?  This is in fact scary.  No
boards are designed solely on a metric only imperial only grid anymore.
All are designed on a mixed grid.  The scary part is EDA programs that
used to make you choose between a metric or imperial grid before laying
out the first component.

> 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.

> 
> 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 F. G. Bidulock    � The reasonable man adapts himself to the �
bidulock@xxxxxxxxxxx    � world; the unreasonable one persists in  �
http://www.openss7.org/ � trying  to adapt the  world  to himself. �
                        � Therefore  all  progress  depends on the �
                        � unreasonable man. -- George Bernard Shaw �