kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 4/14/2012 11:18 PM, lajos kamocsay wrote:
> Hi-
> 
> 
> When I build revno 3511, the tracks that I draw in pcbnew are huge
> (wider than the default page) (screenshot attached).
> I use these flags for cmake:
> 
> cmake ../kicad.latest -DKICAD_STABLE_VERSION=ON -DCMAKE_BUILD_TYPE=Release \
> 	-DCMAKE_INSTALL_PREFIX=/usr
> 
> Am I missing a flag? Or is this just a temporary bug?

It could be.  Are you sure that USE_PCBNEW_NANOMETRES=OFF in your
CMakeCache.txt?  If USE_PCBNEW_NANOMETRES=ON, than you should expect
some object and units scaling to be broken.  I have already fixed the
page reference and title block, grid, and zoom scaling for nanometers in
my development branch which I hope to commit some time today.

FYI when building the testing branch, use -DKICAD_TESTING_VERSION=ON.  I
believe -DKICAD_STABLE_VERSION=0N should only be used when building the
stable branch of KiCad.  Although that shouldn't effect the Pcbnew
internal units.

I cannot duplicate this problem so it may be a build configurations issue.

Wayne

> 
> 
> Thanks-
> -lajos
> 
> 
> 
> On Fri, Apr 13, 2012 at 1:42 PM, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
>> On 04/13/2012 10:18 AM, Wayne Stambaugh wrote:
>>> On 4/13/2012 8:39 AM, Dick Hollenbeck wrote:
>>>> On 04/13/2012 02:04 AM, jean-pierre charras wrote:
>>>>> Le 12/04/2012 20:53, Wayne Stambaugh a écrit :
>>>>>> On 4/12/2012 9:05 AM, Dick Hollenbeck wrote:
>>>>>>> On 04/11/2012 06:41 PM, Dan Chianucci wrote:
>>>>>>>> This new format looks great, I have a few comments/questions
>>>>>>>>
>>>>>>>>       1) in some spots like module pads there is (net<nutNum>  <netName>) and in other
>>>>>>>> spots like track segments it only has (net<netNum>).
>>>>>>>>       2)What do the edge tags represent in the Module
>>>>>>> Exactly.  It might not be the first English tag that comes to mind for this. eh?  I'm not
>>>>>>> even sure these are limited to "edges".
>>>>>> This is one of those areas where I am relying on the knowledge of
>>>>>> someone who know about the BOARD_ITEM internals that I do.  If there is
>>>>>> a more descriptive name or way to present this information, I am
>>>>>> certainly open to suggestion.
>>>>>>
>>>>>>>>       3)Draw arc has tags start and end.  I'm not sure if this has changed, but the file
>>>>>>>> format before this held onto the center of the arc, and an endpoint of the arc...
>>>>>>>>          The file format definitions also say it holds onto the starting point and the
>>>>>>>> ending point, which caused a lot of headaches when I wrote my file format converter
>>>>>> I've saved the object information as defined in the current file format
>>>>>> document as closely as possible.  If arcs are defined this way in
>>>>>> current file format, then they will be defined that way in the new file
>>>>>> format.  Otherwise, some transformation will have to be made when
>>>>>> reading the file.
>>>>>>
>>>>>>>>       4) What are the two (at) tags in module_text for? why not only 1
>>>>>>>>                Is one a position relative to the module and one a position relative to
>>>>>>>> the board?
>>>>>> Good question.  It appears that TEXTE_MODULE::m_Pos0 which is relative
>>>>>> to the anchor position of the module is the only position saved in the
>>>>>> current format and EDA_TEXT::m_Pos is the absolute position on the board
>>>>>> which I'm guessing is determined from the position of the module.  I'm
>>>>>> not sure why it was done this way.  Is there any reason not to dump
>>>>>> TEXTE_MODULE::m_Pos0 and just use EDA_TEXT::m_Pos?
>>>>> All items inside a MODULE have a position on board (m_Pos, m_Start ...
>>>>> and the corresponding parameter relative to the module anchor.
>>>>> The reason is m_Pos *should always* be calculated from m_Pos0 after a rotation transform,
>>>>> due to rounding issues.
>>>>> Only 90 degrees rotations do not have rounding issues.
>>>>> Therefore, after some rotations (for instance 10 rotations each for 9 degrees),
>>>>> when using only m_Pos, there is a significant error between one 90 deg rotation
>>>>> and 10 x 9 deg rotations.
>>>>>
>>>>> Because absolute coordinates are calculated from relative coordinates,
>>>>> only relative coordinates need to be saved on files.
>>>>> (absolute position and rotation of the MODULE are known)
>>>>>
>>>>> I have not a strong opinion about how flipped footprints should store relative coordinates,
>>>>> but I am thinking the stored values (coordinates, text mirroring, layers and layer masks) could be
>>>>> stored as non flipped values, i.e. a flipped footprint is "un-flipped", saved and flipped (restored).
>>>>> Actual values will be restored after reading the file.
>>>>>
>>>>> Eeschema stores (in lib) shapes in position 0, orientation/mirroring 0,
>>>>> and stores the geometric transform for each component.
>>>>>
>>>>> This is perhaps not a bad idea to do the same in Pcbnew.
>>>>>
>>>>> Some other files format use the same thing,
>>>>> and this could make file format conversion more easy.
>>>>
>>>>
>>>> We seem to have no extraneous C++ objects.  And this conversation should not diverge into
>>>> changing C++ objects, but should remain largely focused on file format.
>>>>
>>>>
>>>> However, I will not let go of the importance of this format's effect on our ability to
>>>> perform clipboard operations later.  From day one going back 4-5 years ago, this has
>>>> always been a main objective of the s-expression format of mine.
>>>>
>>>>
>>>> Within a BOARD C++ object, there are two kinds of text C++ objects, two kinds of line C++
>>>> objects, two kinds of arc objects, etc, with one relative to the board and one relative to
>>>> the module/footprint.  This is status quo.
>>>>
>>>>
>>>> We need:
>>>>
>>>>
>>>> 1) to differentiate these later when pulling them off the clipboard,
>>>> 2) to create different C++ objects at file load and at clipboard parsing time.
>>>> 3) to augment them with different trailing s-expression elements.
>>>>
>>>>
>>>> So I suggest:
>>>>
>>>> pcb_text, pcb_line, pcb_arc, pcb_circle, pcb_poly
>>>>
>>>>
>>>> fp_text, fp_line, fp_arc, fp_circle, fp_poly
>>> Sounds reasonable.  I'm assuming fp is short for footprint.  If we drop
>>> the module prefix from the file format, I think we should internally
>>> rename all things MODULE to FOOTPRINT for the same symmetry reasoning.
>>> This gives developers a clearer understanding between the file format
>>> and the objects they are related to.  If we keep module concept in
>>> source code and footprint in the file format, that will just add to the
>>> confusion.  A simple global search and replace can resolve this issue.
>>> If no one objects, I'll go ahead and rename the board objects when I
>>> change the s-expression token for these objects.
>>>
>>> Wayne
>>
>>
>> I agree that what we have is a footprint, i.e. class MODULE is better named FOOTPRINT.
>>
>> However, I think that although renaming the class MODULE to FOOTPRINT might be easy,
>> renaming all the automatic variables which are spelled "module" and "Module", and keeping
>> them separated from other comments, is not easy.  Then one asks, how helpful is this if we
>> have class FOOTPRINT, but variables named "module"?
>>
>>
>> I would not be in favor of having class FOOTPRINT with variables named "module" and "Module".
>>
>>
>> Agreed, what we have looks like footprints to me.
>>
>> At some point in the future, what would a genuine module look like?
>>
>> A "module" could be a fragment of a BOARD consisting of a number of footprints and tracks.
>>
>> This is good homework for my grandkids, because that's about the time it would get done, IMO.
>>
>> Until then, what we have looks like footprints, but I could be blind and not know it.
>>
>> Do you want to rename both variables and the class name?  If not, then maybe wait until we
>> have actual modules, and simply comment the class header with this information.
>>
>>
>> All or none is my suggestion.  The compiler won't care, and you probably won't after the
>> PCB_IO class is done.
>>
>> Where it is more important is in the UI, consisting of dialogs and documentation.
>>
>>
>> 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
>>
>>
>> _______________________________________________
>> 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