← Back to team overview

kicad-developers team mailing list archive

Re: Improving usability of KiCad


Hash: SHA1

On 10/12/2010 03:07 PM, Dick Hollenbeck wrote:
> Alex, I said nothing about metric.
> ------
> I'd like to see support for both metric and imperial (which we mostly
> have), along with the 3rd notion of integer based internal units.  The
> problem we have now is that the granularity of the internal unit is not
> fine enough to avoid round trip conversion errors.  The finer we go, the
> more memory the internal "cell" based autorouter (in PCBNEW) needs, and
> the longer it will take.  The change in memory and speed will likely be
> related to the square in the granularity change.  So if you increase the
> granularity by 100, then you'll need 10,000 times as much memory and
> time to run it.
Last time I checked, the autorouter took more resources and time to
tackle a job if the grid in PCBNEW was reduced in size. It may be just
my impression, but if you don't select a nanometer-grid, the autorouter
won't use one. I last used the autorouter two months ago, so things
might have changed.

> (So maybe you decide at that point to simply toss it out and use
> freerouter.)
> If you take the autorouter off the table, then the question becomes, "is
> there a downside to having granularity that is finer than you need?" 
> This is a question, not a suggestion.
The only downside that I see is the limitation in board size. Of course,
with a 64-bit represantation you can use femto-scale units (smaller than
an electron) and still have an 18km board. I don't see a downside.

> Here is a posting which claims to have found the greatest common
> denominator, GCD, for a new internal unit:
> https://lists.launchpad.net/kicad-developers/msg03757.html
> Here is another opinion:
> https://lists.launchpad.net/kicad-developers/msg03729.html
> Here is the root of the thread:
> https://lists.launchpad.net/kicad-developers/msg03720.html
Mathematically correct. 20nm minimum, and there's no reason to not go as
safe as 1nm. I agree

> Until we revise the file format for PCBNEW, along with a comprehensive
> migration plan, including a *.brd board converter, the best we can do is
> plan and summarize, and schedule for later completion.  

Why not have a flag that specifies the unit used in the file? When the
footprint is loaded, it's automatically converted to the proper internal

> A summarizing
> paragraph could be formulated on this mailing list and then copied to a
> blueprint after it is agreed to by a majority, inclusive of someone
> willing to do the work.
The internal unit system of kicad shall be implemented as 1nm (one
nanometer). A nanometer-scale internal unit enables the _exact_
representation of metric units _and_ imperial down to 1/100 (one
hundredth) mil.
Preferrably, support for nanometer-scaling would be provided by
conditional compilation. A flag would be added to CMakeLists.txt to
enable conditional compilation for nanometer support. Once support
reaches a stable and usable state, old code may be removed.

Hope this sounds reasonable. Feel free to correct and complete

Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/


Follow ups