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 <d...@softplc.com> 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@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
