kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 11/24/2011 01:52 PM, Vladimir Uryvaev wrote:
> 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)

/// a type to express rotation:
typedef double    DEGREES;


BIU reads better for me and pertains to lengths by definition.  Even an X coordinate is
actually a "length" from the origin along the x axis.



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

You see it the way I do.  We agree.

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

Not worth the effort.  We should pledge ourselves to making new code work, and to progress.
Those that want to use old software can use old features.  We will not charge them for the
upgrade.

>> 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.
This is not clear what you mean here.

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

Yes, I agree.  We have had contact and discussion about this with some people working with
CERN.  I will put this in my proposed plan.

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

We get this if the intermediate products and quotients are in either

double or
long double

and then there is a consistent rounding strategy used when coming back into the integer
domain.

This is basically what they do in boost::polygon.



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

There was some UI work recently which allows setting an offset into the "grid origin".  It
seems this, along with having either metric or imperial grid might be OK.  Or a
sufficiently small grid is tantamount to having no grid.


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

Agreed.

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

I think now there are no terribly conflicting differences in our views.

I will try and get out a proposal soon, after the vodka wears off.  It is Thanksgiving
Holiday here, so that has been more demanding than I expected.


Dick