kicad-developers team mailing list archive

[jean-pierre charras <jp.charras@xxxxxxxxxx>]

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.


> > >       5) Why does Modules have a different text tag than the pcb itself?  Why not just
> > > have a single text tag which can be placed anywhere?
>
> I agree.  Any text definition within a module grouping obviously is an
> TEXTE_MODULE object and a text definition anywhere else is a TEXTE_PCB
> object.
>
>
> Wayne


--
Jean-Pierre CHARRAS