← Back to team overview

kicad-developers team mailing list archive

Re: Concerns about clearing disagreements before committing.

 

Dick and Vladimir,
Thanks for trying to solve this together!

I agree with your assessment. I think I read that board-files will be saved in a defined unit (engineering unit). I think this is great especially if the board-file also has the information on which unit is used (mm, mil, nm, whatever).
Ok, probably not whatever, but one really small imperial unit, one really small metric unit and perhaps a really small mil-based unit (centi-mill?).

I am also in favour in rolling-back the commits as for the moment it does not compile for me (needs the fabs-patch, floating abs, which is trivial, but not necessary). 

I will do my best to do OSX-testing of your results. (we actually use KiCAD on all 3 platforms).

Break a leg ;-)
Martijn



On Nov 24, 2011, at 5:30 AM, Dick Hollenbeck wrote:

> 
> 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.
> A BIU refers typically to a measurement or a position on an XY grid, and this is
> because this grid is dimensioned in BIUs along both its X and Y axes. Both X and
> Y can be either positive or negative on this grid. In the case of measurements
> or scalars, there can be a radius, a diameter, a distance (length), and all of
> these can and should be expressed in BIUs, when we are in RAM and when we are
> talking about the objects within the class BOARD instance. One special
> feature of XY points within the BIU coordinate system is that they will always
> be integers. In contrast, distances and other forms of measurements are not
> subject to the same limitation by the very nature of physics. Coordinates are
> always integers because we use signed whole numbers to represent these BIU
> coordinates.
> 
> *) 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.
> 
> 
> 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.
> 
> c) Since we have no backwards compatibility obligation, we can make significant
> changes to the file format while we have this disruption opportunity.
> 
> 
> 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?
> 
> 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) ?
> 
> 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?)
> 
> 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?
> 
> 7) Which items among 1) through 6) are new?
> 
> Dick
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp



Follow ups

References