kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Wed, Nov 23, 2011 at 11:30:39PM -0600, Dick Hollenbeck wrote:

OK, so typically an 'int' in decimils (now); will become nanos or
10nanos when we'll decide. 

> *) Snap grid. A snap grid is a subset of the full set of possible XY coordinates

Like in 'dimension/grid size', expressed in BIUs, right?

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

Why do a distinction? when measured in nanos an imperial board become
metric (by the definition of the current inch). It's more a user
interface issure (the mm/inch buttons).

> a) It is OK to modify the board file format in order to handle the BIU change.

Necessarily, unless you want to do fractional decimils (the horror!)

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

A 'compatibility mode' *could* be added where you 'round' the
coordinates to decimil. This way you could keep the basic file structure
(you need to keep backward *loading* compatibility, otherwise I'll linch
you personally :D); so instead of:

DS 120 130 140 150

you could have 

DS 1200* 1300* 1400* 1500*

where numbers would be suitably scaled and * would be a 'suitable'
marker. Then define an I/O routine to recognize the marker and you're
ok. Or simply flag in the header that the unit is BIU instead of
decimils and keep the same string representation (think about *MOIN and
*MOMM in gerbers)

> 1) Is it not possible that the board could be saved on disk using engineering
> units other than the BIUs?

A simple way is indeed to simply use BIUs instead of decimils;
a slightly more complex one is to accept things like

10mm 11mi 12nm 13in

like my parser for edit boxed. That would somewhat useful for hand
edited/generate modules, in particular. But I'd say only *useful*, not
required.

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

In ram only BIU, don't shoot yourself in the foot... think about TeX,
inside it's everything in scaled points (1/65536 of pt), fixed point too
(a big design issue in TeX was that in these days FP wasn't standardised
and Knuth wanted repeatability of the output...)

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

Only UI (in fact only edit boxes and the status bar); I can confirm that
because I sweeped the code during the input box patch. The only
nonstandard handling IIRC is during grid dimension processing and some
report (like drill tables); as I said before: all BIU, inches and mm are
only a (superficial) UI feature.

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

Put the BIU in the header, like BIU = 10nm or something. But I think it
complicates unnecessarily the format. OTOH MicroStation did this until
a few versions ago (when AutoCAD required an FPU, MicroStation was still
fully fixed point!); this could be another *useful* but not required
thing in my book (still, it should be easy to implement).

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

Like in my example 10mm 11mi and so on you mean?

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

Exactly, that's the 'reporting' issue I said before.

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

Sorry, didn't get the question... all of this IIRC were already been
proposed on the list.

-- 
Lorenzo Marcantonio
Logos Srl