kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

Le 17/03/2017 à 00:32, José Ignacio a écrit :
> eeschema uses mils, which are exactly 25400 nanometers, eeschema can be losslessly converted to
> nanometers. Another advantage of using nm in eeschema would be that it would be possible to use
> round metric quantities (right now it's impossible and confusing as numbers are rounded to the
> nearest mil) while being able to open older schematics losslessly.

But Gerbview uses 10 nanometers.
1 nanometer in Gerbview creates integer overflow in some gerber files, which can use large
coordinates (usually due to a large offset when plotting files).

Eeschema has other constraints.
Especially, you cannot easily mix mils and mm for the working grid, because items are connected when
the end points are at the same location (no magnetic pin).


A correct handling of the actual internal units is for me the better (and the easier) way.

> 
> On Thu, Mar 16, 2017 at 2:16 PM, Wayne Stambaugh <stambaughw@xxxxxxxxx
> <mailto:stambaughw@xxxxxxxxx>> wrote:
> 
> 
>     On 3/16/2017 3:03 PM, jp charras wrote:
>     > Le 16/03/2017 à 11:21, John Beard a écrit :
>     >> Hi JP,
>     >>
>     >> Thank for checking this. Internal units always confuse me, since
>     >> they're always different and nothing in common can ever use anything
>     >> to do with IUs, as they're only defined in some end executables.
>     >>
>     >> How should this be done correctly?
>     >>
>     >> Cheers,
>     >>
>     >> John
>     >>
>     >
>     > IUs are not very easy to handle, and currently I am not very happy by the way they are handled.
> 
>     Me neither.  I've never been a big fan of compiling the same source code
>     file multiple times (see include/convert_to_bui.h) depending on a
>     definition specified at compile time.  I would much rather see some type
>     of abstract class be used to define the app specific internal units.  Of
>     course you would have to modify the tools to use this object to provide
>     the proper internal units.
> 
>     >
>     > About the GAL layer, sorry, but I am not a GAL specialist.
>     > However I just know this issue is serious and must be solved.
> 
>     This makes me reluctant to merge this patch even though it sounds like
>     this issue already exists elsewhere in the "common" tool framework.  It
>     also means that none of the "common" gal tools that use nanometer units
>     will be usable in the schematic editor and no I don't think nanometer
>     units make any sense for the schematic editor.
> 
>     >
>     > Until now, GAL was used only by Pcbnew.
>     > Unfortunately, in a few places, I saw a conversion to nanometers using fixed scaling factor.
>     > (A golden advice I learned when writing Kicad code: do not use a fixed scaling factor in code)
>     >
>     > Now GAL is very near to be used by other applications.
>     > Conversion to nanometers just by using a fixed scaling factor is therefore a bug, and from my point
>     > of view, even in Pcbnew.
>     > Who know: we could change one day the internal unit value. It already happened.
>     >
>     > I just leave guys who have a good knowledge of the GAL code taking the best decision.
>     >
>     > Thanks, John.
>     >
> 
>     _______________________________________________
>     Mailing list: https://launchpad.net/~kicad-developers <https://launchpad.net/%7Ekicad-developers>
>     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     Unsubscribe : https://launchpad.net/~kicad-developers <https://launchpad.net/%7Ekicad-developers>
>     More help   : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>
> 
> 
> 
> 
> _______________________________________________
> 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
> 


-- 
Jean-Pierre CHARRAS