kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

Dick Hollenbeck wrote:
> viking632 wrote:
>> Note: Subject changed from: Re: Metric and English grids sizes.
>>
>> --- In kicad-devel@xxxxxxxxxxxxxxx, Wayne Stambaugh <stambaughw@...> wrote:
>> 
>>> The units for .pcb and .mod files are 0.0001". The units for .sch and
>>> .lib files are 0.001". This will break every Kicad file format except
>>> the project file although it make break some of settings in it. You
>>> will not likely make many friends unless you provide complete backwards
>>> compatibility with the current file formats. You would have to rewrite
>>> the file parsers to handle the new units and modify the current file
>>> parsers to convert the current file format to the new units internally.
>>> You will also have to modify all the code in Kicad that manipulates the
>>> current units. It will be one hell of a patch:)
>>>
>>> Wayne
>>> 
>> You're right, backwards compatibility is a must, and doing it as one big patch will be a major pain (virtually impossible) due to other devel work.
>>
>> I've given this some thought, and metric grids and coords is a pain, due to the rounding errors, so I still think it would be worth doing.
>> It'll have to be done in stages though, some of which will take "sligthly" longer than others:
>>
>> First, introduce a new header file that defines the internal unit, which must initially be set to the current value (1mil resp. 1dmil for eeschema resp. pcbnew/cvpcb).
>> The header file must also include a number of conversion routines in the form of #define's, macros and/or inline functions, which eventually must become the only valid way of manipulating units (internal and external).
>> Also, the type (currently double, 32bit int in the future) of all coordinates, etc., must be defined here, and routines for pretty-printing of coords also belongs here, I think.

Units in Kicad are defined as int not double. They are converted to
double for calculating the grid coordinates and display purposes. I
believe JP made this change (JP please correct me if I am wrong) due to
rounding errors when attempting to draw the grid when metric units are
selected. If I remember correctly, this needed to be fixed when I
changed the zoom code to allow for less than whole integer numbers.
Maybe this is where the internal units need to be changed. They may
only need to be changed to perform the grid and display cooridinate
calculations.

>>
>> Second, add a single-line comment to each and every source file (C++ and maybe the header files as well) that states, that this file hasn't been inspected for change of internal unit yet.
>>
>> Third, inspect the source (yes, that's right, all 180k+ lines of it ...) and change it to use the new unit defines/macros/functions and typedef.
>> This can be done a few files at a time, and will hopefully only require major changes to a limited number of files (fingers crossed).
>> When a file has been inspected/changed, replace the "not-inspected" comment with a "#include <internalunit.h>" or a comment saying
>> "file independent on the internal unit", as the case may be.
>>
>> This third step will take some time (TM), but can be taken a byte (pun intended :-) at a time, just like eating an elephant (eventually, you will be done) ...
>> Also, it can be shared between several, to speed up the process.
>>
>> Both the "not-inspected" and "independant" comments and the #include should be unique and easily recognizable.
>> This means greppable, preferably yielding all three possibilities (and only those) with a single, well chosen pattern :-)
>>
>> Fourth, when all code has been visited, change the internal unit in the header file to 100nm (or one IU, 1kÅ, 1decimicron, ...), and we're done.
>>
>> This four-step process will change the internal unit, but will keep everything else unchanged, so file formats will be the same, but the code that reads/writes them does something different (converts to/from another unit).
>>
>> After this (or in parallel), the code that reads/writes files can be enhanced to include support for new fileformats, which supports the new unit, i.e. allows saving the exact coord values, instead of rounding everything off to 1mil resp. 1dmil.
>>
>> The ability to read the current fileformats must of course be retained "forever", and when saving files, a choice between old or new format must be given - a per-project setting will probably be the best solution, and will provide backwards compatibility if you need it, or better metric precision if you don't.
>> At least initially, the default should be "use the old units".
>>
>> The new file formats can be made virtually identical to the current ones, by adding only an "InternalUnit" line near the top, and an increase in version number, to signal to older kicad programs that this file is incompatible.
>>
>> If there are other planned features that will also require an incompatible change (pad stacks ?), include these as well, so that only one new (set of) format(s) is required.
>>
>> One other thing needs to be addressed, and that is the library files included with kicad.
>> The eeschema .lib and the pcbnew .mod/.mdc files can be provided in two variants, and the same can be done with the 3D .wrl files, just choose a naming scheme that ensures zero risk of filename collision.
>>
>> I'm working on a new set of libs for pcbnew (see msg #3358), where all parts are defined by their dimensions and some perl code, so providing both old and new format libs would be pretty easy (will require only a dozen or so extra lines of code).
>>
>> What about eeschema - it would be nice to be able to choose between mil and mm based grids (i.e. pin and trace spacing) in eeschema as well ?
>> This could be done by providing two versions of all parts, or better yet, if all pins are created on a common grid, the parts can simply be scaled between e.g. 100mil (2.54mm) and 2.5mm, depending on your choice between imperial or metric grid.
>>
>> Øyvind.
>> 
> 
> Among the 4 solutions which have been discussed, this is my least 
> favorite. If we really look at what your problem is, it is not 
> engineering units, but rather granularity at which these units are 
> expressed in a *.brd file.
> 
> Engineering units can be converted trivially internal by the software 
> without it affecting the file format (it *already* does this). But the 
> current conversion is hampered by the *granularity* of the values 
> contained in a board file. I think your path to support two file 
> formats (both of which are based on the existing format with some 
> tweaks) is a can of worms.

I for one would not want to maintain the file parsing code to support
multiple file formats. I also think multiple library files to support
the old and new format is not practical. I think the real question is
do we need better than 0.0001" resolution for PCB layouts and 0.001"
resolution for drawing schematics? The answer to that question should
drive the file format.

Wayne

> 
> Lorenzo put something on the table, as did some others. Can you at 
> least go back and summarize all these options for us before you get too 
> far into this please. This is an exercise that will be helpful for all 
> of us, but especially for you.
> 
> 
> If we fix the granularity, would not your problem be solved?
> 
> 
> Thanks,
> 
> Dick