kicad-developers team mailing list archive

[lajos kamocsay <panka.nospam@xxxxxxxxx>]

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?


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

Attachment: 2012-04-14-231517_1366x768_scrot.png
Description: PNG image