kicad-developers team mailing list archive

[Vladimir Uryvaev <vovanius@xxxxx>]

At Thursday 24 of November 2011 09:30:39 from Dick Hollenbeck:
> Vladimir,
> 
> Tonight : definitions and some questions
> Tomorrow: a proposal to share/split the work and how to do it
> 
> If you can look over the questions and clear any confusion on my part that
> would be appreciated.  Thanks very much.
> 
> 
> Definitions:
> 
> *) Board Internal Units (BIU). This is a pseudonym for the engineering
> units used by a BOARD when it is in RAM, and only when it is in RAM.  BIU
> is perhaps nanometers in the future, and deci-mils currently.

Name it BILU (Board Internal *Length* units) as there are internal angle units 
(which are 0.1deg)

(cut)

> *) Snap grid. A snap grid is a subset of the full set of possible XY
> coordinates in the BIU coordinate system. Points falling on the snap grid
> are evenly spaced in X and Y directions and are some integer multiple
> apart in this 2D space, usually greater than one BIU apart.
> 
> *) 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.

For two above It is possible that board have heavy mixed metric/imperial 
design. Just because some parts are metric and some are imperial. I. e. SOIC 
and other SMD. 

> 
> Assumptions:
> 
> a) It is OK to modify the board file format in order to handle the BIU
> change.
> 
> b) Boards saved on disk in the new format will not be readable using old
> software.

My intention was to new files could be loaded to old kicad with less accuracy.
For some reason it's not so easy, while most features could be loadable.

> 
> c) Since we have no backwards compatibility obligation, we can make
> significant changes to the file format while we have this disruption
> opportunity.

Break work in small pieces to get it done. First 'break-in' on procedures is 
to add precision without change in units, and which I tested to work.

I'm thinking that load/save procedures could be sort of modules (say, classes 
with unified methods), so we can have any number of them.

> 
> 
> Questions:
> 
> 1) Is it not possible that the board could be saved on disk using
> engineering units other than the BIUs?
> 
> 2) Once the BOARD is in RAM, is it not possible that all objects within the
> BOARD* object use BIUs as their spatial coordinates and BIUs as units of
> measured distances?

Possibly finer quantum may be required for some calculations while final result 
is in BI(L)U.

> 3) Is it not true that the main difference between the user interface in
> play while working on a metric board vs. an imperial board, is the grid
> snap distance (and various computer screen fields and menus) ?

On grid distance:
Because of above (my comment on board types) in many cases it is not possible 
to have one common grid. So gridless solutions could be appreciated.
E. g. Depending on pad shape and pitch in moct cases 1, 2, or 3 max tracks are 
traceable between pads, but when they're locked on a grid, this numbers is 
practically reduced.

Rounding / representaion precision of values in GUI can be an issue. Jean 
pointed on it.

> 4) If sufficient resolution is preserved, is there not some advantage in
> disconnecting the chosen engineering units in a saved BOARD file from the
> BIU? (On the theory that if the BIU needs to be changed again in the
> future, that you do not also have to change the BOARD file format, a
> situation we currently find ourselves in?)

In my POV program could be witten without lock in to specific representation of 
length anywhere it is possible. For dealing with rounding and precision issues 
some sort of generic interface like std::numeric_limits should be provided.

Main issue on load/save is that full-precision, say exactness should be kept, 
at least for the file to be edited (ont only viewed).

> 5) Is is not simply a matter of scaling other engineering units like
> millimeters when loading a BOARD file into the RAM resident form where
> BIUs pertain? In reverse direction for disk saves?
> 
> 6) Is it not simply a matter of scaling to other engineering units like
> millimeters or mils when exporting a RAM resident BOARD (of course using
> BIUs) to other formats such as gerbers?

Exactness should be kept whatever method of save is chosen. Finer the length 
quantum, more significant digits in play.

> 
> 7) Which items among 1) through 6) are new?

More vodka is required to answer all those questions.


-- 

--- KeyFP: DC07 D4C3 BB33 E596 CF5E  CEF9 D4E3 B618 65BA 2B61