Re: [Kicad-developers] New Pcbnew file format.
Hi Wayne- I deleted the build directory, compiled from scratch and now the issue is gone. So it must have been a cmake cache problem as you suspected. Lesson learned ;) Thanks Lajos On Apr 15, 2012 11:21 AM, Wayne Stambaugh stambau...@verizon.net wrote: On 4/15/2012 11:08 AM, lajos kamocsay wrote: Thanks, Wayne. It might be a configuration cache issue. I'll rebuild it tonight when my real world project is done (bathroom tiling). I've been there and done that! Several times. Have fun! In general I find the cmake caching very frustrating. The only reliable way I found to make sure that the configuration's correct is to delete the whole build folder and rebuild from scratch. Or is there a better way? Not that I have found. Generally I keep separate build configurations around depending on what I am working on. This is not a terribly efficient use of disk space but it prevents the caching problem and I know what to expect for each configuration. Maybe some one else has a better idea. Wayne Thanks- -lajos On Apr 15, 2012 10:57 AM, Wayne Stambaugh stambau...@verizon.net mailto:stambau...@verizon.net wrote: 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 mailto: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 (netnutNum netName) and in other spots like track segments it only has (netnetNum). 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
Re: [Kicad-developers] New Pcbnew file format.
On 16 April 2012 18:06, lajos kamocsay panka.nos...@gmail.com wrote: Hi Wayne- I deleted the build directory, compiled from scratch and now the issue is gone. So it must have been a cmake cache problem as you suspected. Lesson learned ;) Thanks Lajos Sorry, I'm coming to the party late... Did you try: make rebuild_cache It rebuilds cmake's cache. Best Regards, Brian. ___ 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
Re: [Kicad-developers] New Pcbnew file format.
Thanks for the tip Brian, I'll try that next time. On Apr 16, 2012 1:36 PM, Brian Sidebotham brian.sidebot...@gmail.com wrote: On 16 April 2012 18:06, lajos kamocsay panka.nos...@gmail.com wrote: Hi Wayne- I deleted the build directory, compiled from scratch and now the issue is gone. So it must have been a cmake cache problem as you suspected. Lesson learned ;) Thanks Lajos Sorry, I'm coming to the party late... Did you try: make rebuild_cache It rebuilds cmake's cache. Best Regards, Brian. ___ 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
Re: [Kicad-developers] New Pcbnew file format.
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 (netnutNum netName) and in other spots like track segments it only has (netnetNum). 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
Re: [Kicad-developers] New Pcbnew file format.
Like so many suggestions, they are often good ideas that never get done, because they do not rise to a sufficient level of need within an individual capable of doing the work. This is especially true in free software, which in fact is never free. Feature bounties might be a workable solution for boring work. I'm quite confident I'm not he only one doing SMPS design on KiCad, and would be willing to invest about two hours worth at your rate for a few features (just guesstimating from senior sw developers contracting rates). I also feel that that two hours is quite small compensation for the actual effort going in, so I see there is a need for other investors. Another thing you can do with this is add it to the bug list as a wishlist item. Will do that. Otherwise it might get lost on the mailing list. It is not something we can simply add to the board file, and then hope that PCBNEW magically understands as it reads it. My intention was not to demand any implementation, but just find ways to support the feature in the file format currently being defined. Reasoning is commenting on the new file format to avoid a second design round (which would probably get a lot of opposition) and save users from the hassle on multiple format versions. Error messages like This feature is supported on file format version 1.0.2.003b+ might get annoying... I'm sure you understand that this is a minor hi-jacking of the subject thread, but not a bad idea. The only reason of pushing it in this thread is above, even though I agree it may have been better to start separate feature thread. I would also like to thank you, Wayne, JP and others for great advances in KiCad. -Vesa ___ 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
Re: [Kicad-developers] New Pcbnew file format.
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 (netnutNum netName) and in other spots like track segments it only has (netnetNum). 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 This provides symmetry in naming yet provides the freedom to give different trailing attributes in the expression, again, used both for *clipboard* and *.kicad_pcb file. It also reduces the number of parsing tokens down from (draw line ) to (pcb_line ...) 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
Re: [Kicad-developers] New Pcbnew file format.
On 04/13/2012 02:32 AM, Solonen Vesa wrote: Like so many suggestions, they are often good ideas that never get done, because they do not rise to a sufficient level of need within an individual capable of doing the work. This is especially true in free software, which in fact is never free. Feature bounties might be a workable solution for boring work. I'm quite confident I'm not he only one doing SMPS design on KiCad, and would be willing to invest about two hours worth at your rate for a few features (just guesstimating from senior sw developers contracting rates). I also feel that that two hours is quite small compensation for the actual effort going in, so I see there is a need for other investors. Another thing you can do with this is add it to the bug list as a wishlist item. Will do that. Otherwise it might get lost on the mailing list. It is not something we can simply add to the board file, and then hope that PCBNEW magically understands as it reads it. My intention was not to demand any implementation, but just find ways to support the feature in the file format currently being defined. Reasoning is commenting on the new file format to avoid a second design round (which would probably get a lot of opposition) and save users from the hassle on multiple format versions. Error messages like This feature is supported on file format version 1.0.2.003b+ might get annoying... The s-expression format consists of both syntax and grammar. The grammar portion will evolve over time. There is no way to anticipate all future needs. s-expression is very flexible, you can always change the grammar, and elements not understood within a new file can in theory be ignored by an older parser, if it so choses. Maybe if you write a specification you could get more investors to buy into your proposal. This might include proposed s-expression elements to hold the constructs that you need. However, I would not think there is any particular urgency in doing this before we get rolling on this new file format. We won't be doing the switch over for several more weeks, and want to try and get the internal nano-meter support fully working before a switch over. 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
Re: [Kicad-developers] New Pcbnew file format.
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 ^ knows more^ than I really need to get away from my computer :) Wayne That will only make you worse at typing. ___ 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
Re: [Kicad-developers] New Pcbnew file format.
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 (netnutNum netName) and in other spots like track segments it only has (netnetNum). 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
Re: [Kicad-developers] New Pcbnew file format.
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 (netnutNum netName) and in other spots like track segments it only has (netnetNum). 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
Re: [Kicad-developers] New Pcbnew file format.
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. 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 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? 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? ___ 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
Re: [Kicad-developers] New Pcbnew file format.
On 04/11/2012 07:14 AM, Solonen Vesa wrote: Some salt on the popcorn? Regarding net classes handling... Flexible automatic design rules would need differential net classes that means different rules for a net depending on surrounding nets. As an example I'll explain the problem of a traditional power electronics half bridge circuit: HV 400V 10A | Gh--|0-415V 1A0 V(Gh)-V(Sh) 15 | Sh- Out0-400V 10A | Gl---|0-15V 1A | GND-- 0V 10A HV net needs power class clearance and width towards all nets as does Out. Sh needs power class clearance towards all nets, but Gh and width according to control class. Gh needs the same, but control clearance towards Sh. Gl needs control class clearance and width. Curently this system is unrealisable using KiCad DRC. I propose adding a potential class description to net class design rules to address this problem. -Vesa Like so many suggestions, they are often good ideas that never get done, because they do not rise to a sufficient level of need within an individual capable of doing the work. This is especially true in free software, which in fact is never free. Another thing you can do with this is add it to the bug list as a wishlist item. Otherwise it might get lost on the mailing list. It is not something we can simply add to the board file, and then hope that PCBNEW magically understands as it reads it. I'm sure you understand that this is a minor hi-jacking of the subject thread, but not a bad idea. 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
Re: [Kicad-developers] New Pcbnew file format.
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? 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 ___ 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
Re: [Kicad-developers] New Pcbnew file format.
- Original Message - From: Wayne Stambaugh stambau...@verizon.net To: kicad-developers@lists.launchpad.net Cc: Sent: Friday, April 13, 2012 4:53 AM Subject: Re: [Kicad-developers] New Pcbnew file format. [snip] 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? 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. [snip] I would think that the module has its own text because that is the easiest way to associate the text with a particular module and to manipulate the file (delete part, rotate part). If you make all PCB text equal, you will lose the association with the part. Consider a module placed at (X,Y). The text would be placed at (X+dX, Y+dY); if you rotate or move the module it is trivial to calculate the new (correct) position of the text. However, if the text has global coordinates then you need to perform many unnecessary operations - at the least you will need to subtract the offset (X,Y) and determine if there were any rotations previously applied. - Cirilo ___ 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
Re: [Kicad-developers] New Pcbnew file format.
On 04/12/2012 01:53 PM, Wayne Stambaugh wrote: 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. class EDGE_MODULE is derived from DRAWSEGMENT and comes in types S_SEGMENT, S_CIRCLE, S_ARC, S_POLYGON. So it is basically a graphical line, circle, arc, or polygon. Basically a graphic, so that word is one candidate. It is not confined to the module's edge, but is often used to delineate the bounds of the footprint. However you would use one of these to designate PIN 1 on the footprint. It is nearly the same discussion we had about (draw line ) before. You could go with gr_line for S_SEGMENT, gr_circle for S_CIRCLE, etc. The discussion about why not (text..) for both BOARD and MODULE is almost the same discussion about (draw...) [now edge] for BOARD and MODULE. There is an argument to try and unify them. There is also an argument to keep in mind some solution for the case where you pull this text off the clipboard, and now you have to know whether it is for a BOARD or MODULE, and one way to do this is to have unique keywords, but not the only way. Off the top of my head I do not know what class EDGE_MODULE does differently than DRAWSEGMENT. 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. If it can be or is readily computed, then perhaps we don't need to save it? Jean-Pierre? (I am too busy to check code right now.) ___ 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
Re: [Kicad-developers] New Pcbnew file format.
class EDGE_MODULE is derived from DRAWSEGMENT and comes in types S_SEGMENT, S_CIRCLE, S_ARC, S_POLYGON. So it is basically a graphical line, circle, arc, or polygon. Basically a graphic, so that word is one candidate. It is not confined to the module's edge, but is often used to delineate the bounds of the footprint. However you would use one of these to designate PIN 1 on the footprint. It is nearly the same discussion we had about (draw line ) before. You could go with gr_line for S_SEGMENT, gr_circle for S_CIRCLE, etc. calling it gr_line etc. seems more intuitive to me. I was confused and thought that there was board edges (the board outline) inside of modules for some reason. Or that the modules held on to a bounding box called edges. The discussion about why not (text..) for both BOARD and MODULE is almost the same discussion about (draw...) [now edge] for BOARD and MODULE. There is also an argument to keep in mind some solution for the case where you pull this text off the clipboard, and now you have to know whether it is for a BOARD or MODULE, and one way to do this is to have unique keywords, but not the only way. My two cents would be to unify the objects inside of the stored file. This way everything can be read the same way. For instance there would only need to be a single readText function which would get various information about the text, line, or whatever it is that is being loaded. The same argument holds for writing it to disk, and even to the function which actually draws it on screen. Additionally, having the objects be saved differently depending on where they are encourages having the different limitation on the object internally to the program. For example, right now depending on where text is on the board, the user has different amounts of control over it. For instance in a Module, text is centered over the center, and can only be rotated at 0 or 90 degrees. On the Board itself however it can be justified to the left, right or center, and it can be rotated in 90 degree increments. If it was unified internally it would make it a lot easier to add functionality to each type of bboard object. 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. If it can be or is readily computed, then perhaps we don't need to save it? Jean-Pierre? (I am too busy to check code right now.) I didn't word what I was trying to say correctly. If you look closely at the current file format you will find that even though the file format definitions says that it holds on to the endpoints of the arc, and the center is computed internally, in actuality it doe the opposite. What is actually saved is the center of the arc and an endpoint of the arc. Prove it by drawing an arc in the board, record the points where the endpoints and the center are located, then save it and look at the file startX startY is actually centerX and centerY. To Cirilo: I agree with what you are saying, about being difficult to associate individual pieces to a single module if they were all saved the same way. However the module text will still be inside of a module 'tag block'. I would say that the parts that make up a module should be saved as if the module were centered at (0,0) with a rotation of 0. Then the module itself would hold onto where it is on the board, and at what rotation. Internally, it would be trivial to calculate the actual positions of the each module's pieces. ___ 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
Re: [Kicad-developers] New Pcbnew file format.
- Original Message - From: Dan Chianucci trump211...@gmail.com To: Dick Hollenbeck d...@softplc.com Cc: kicad-developers@lists.launchpad.net Sent: Friday, April 13, 2012 9:58 AM Subject: Re: [Kicad-developers] New Pcbnew file format. [snip] To Cirilo: I agree with what you are saying, about being difficult to associate individual pieces to a single module if they were all saved the same way. However the module text will still be inside of a module 'tag block'. I would say that the parts that make up a module should be saved as if the module were centered at (0,0) with a rotation of 0. Then the module itself would hold onto where it is on the board, and at what rotation. Internally, it would be trivial to calculate the actual positions of the each module's pieces. Ah, OK - I probably misunderstood. So the issue is really one of generalizing an object 'text' rather than having an object such as 'pcb_text' and 'module_text'. In that case I agree with you 100% - they are all text but will behave differently when plotted depending on what their parent object is. Even in the old format the context is clear and the tool I am working on to produce STEP assemblies from a (old format) pcb file uses a generic text object rather than separate specialized objects. - Cirilo ___ 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
Re: [Kicad-developers] New Pcbnew file format.
Sorry for top-posting! Just wanted to say well done Wayne! Again, excellent work that is so beneficial to the project! And don't think your UI changes have gone unnoticed, KiCad is a lot more together since you started work on the UI tidy up. Thanks for your continued efforts! :D Best Regards, Brian. On 7 April 2012 19:09, Wayne Stambaugh stambau...@verizon.net wrote: It took long than I anticipated (doesn't always?) but I just committed the code to allow saving board files to the new s-expression based file format. I would like as many folks as possible to save their favorite board file using File-Save As to the new format and take a look at the result. My goal is to get the final file format nailed down as quickly as possible. There are few caveats: * I still have to convert angles to degrees from the current tenths of degrees so please ignore the fact that 270° is saved as 2700°. This fix is coming soon. * The lead developers have decided to drop support for the old segment filled zones (SEGZONES) which have not been used in quite some time. I will be adding a dialog warning the user that they will need to refill their zones using the current polygon filling. I doubt this will effect very many users but I could be wrong. * I rearranged the object ordering slightly compared to the current file format. I moved the graphic items (items with no net connection) before the modules. This way all of the net connectable objects (modules, traces, zones, etc.) will be grouped together. Please take some time to look over the new format. If you find a token (key word) that is not clear, let me know so we can choose names that are as human readable as possible. Please keep in mind that the file size is going to increase dramatically over the current format so try to keep names as brief as possible while still maintaining readability. Also, if you find any indentation or other formatting errors, let me know so I can fix it. I will be working on reading the new file format over the next few days (weeks?) so I would like to wrap up the file format definition in a reasonable amount of time. Thanks in advance for you help. Wayne ___ 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
Re: [Kicad-developers] New Pcbnew file format.
On 04/09/2012 03:52 PM, Miguel Angel Ajo Pelayo wrote: I love the plan, it matches and extends the tiny idea I had but it's well planned!!, About the SWEET_HTTP_LIB source and even SWEET servers, and web apps, I propose that we could use our (future) new python powers, that are proficient in handling XML-RPC, Databases, and similar things with very very few lines and effort. I have a lot of experience about python+networking+xml-rpc+web apps, and if using the underlying python scripting could fit on the plan, then we will just run ... and enjoy our popcorn more happily. Do you prefer Miguel or Mike? I appreciate your enthusiasm for this work and the offer to help with it. It is not going unnoticed, I just need a little time to time slice in my actual real job right now. Will get back to you about how you can help soon. 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
Re: [Kicad-developers] New Pcbnew file format.
On 4/11/2012 4:02 AM, Brian Sidebotham wrote: Sorry for top-posting! Just wanted to say well done Wayne! Again, excellent work that is so beneficial to the project! And don't think your UI changes have gone unnoticed, KiCad is a lot more together since you started work on the UI tidy up. Thanks for your continued efforts! :D Best Regards, Brian. Thanks. It's nice when you efforts get recognized. KiCad development is starting to pick up some momentum which is great for both the users and the developers. Cheers, Wayne On 7 April 2012 19:09, Wayne Stambaugh stambau...@verizon.net wrote: It took long than I anticipated (doesn't always?) but I just committed the code to allow saving board files to the new s-expression based file format. I would like as many folks as possible to save their favorite board file using File-Save As to the new format and take a look at the result. My goal is to get the final file format nailed down as quickly as possible. There are few caveats: * I still have to convert angles to degrees from the current tenths of degrees so please ignore the fact that 270° is saved as 2700°. This fix is coming soon. * The lead developers have decided to drop support for the old segment filled zones (SEGZONES) which have not been used in quite some time. I will be adding a dialog warning the user that they will need to refill their zones using the current polygon filling. I doubt this will effect very many users but I could be wrong. * I rearranged the object ordering slightly compared to the current file format. I moved the graphic items (items with no net connection) before the modules. This way all of the net connectable objects (modules, traces, zones, etc.) will be grouped together. Please take some time to look over the new format. If you find a token (key word) that is not clear, let me know so we can choose names that are as human readable as possible. Please keep in mind that the file size is going to increase dramatically over the current format so try to keep names as brief as possible while still maintaining readability. Also, if you find any indentation or other formatting errors, let me know so I can fix it. I will be working on reading the new file format over the next few days (weeks?) so I would like to wrap up the file format definition in a reasonable amount of time. Thanks in advance for you help. Wayne ___ 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
Re: [Kicad-developers] New Pcbnew file format.
Human readability/usability/ease of learning would also be helped with some standardization. On 8/04/2012 8:23 p.m., Dick Hollenbeck wrote: On 04/08/2012 11:38 AM, lajos kamocsay wrote: Hi Wayne- The new file format looks awesome. Very simple and readable. Would it be possible to standardize the transformation data? Currently there seems to be a couple different formats, some examples: (draw line (pts xy(76.581 47.9425) xy(77.724 47.9425)) (layer 21) (width 0.127)) (size 1.016 1.651) (at -1.524 0) (at (xyz 0 0 0)) (scale (xyz 0.17 0.16 0.16)) (rotate (xyz 0 0 0)) I think having a standard format would be very helpful for external utilities reading/writing kicad data, like: Without diminishing your point about standardization, I suggest that Miquel's scripting interface will soon be the recommended way to write external tools. And as such, folks writing directly to the KiCad file formats will be missing the point of the scripting API, so they will not get any of my attention, at least. Back to the transformation data, we have both 3d and 2d transforms, and it would be sensible to allow them to be different. Also, the SWEET parser is already written, works on 2d transform data, and I assume Wayne took that into consideration. Changing the 2d SWEET stuff is something I would not embrace easily. I am not taking such a position on this new BOARD format yet however, but rather keeping an open mind. However, achieving some 2d transform similarly between SWEET and BOARD might have at least some value. 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
Re: [Kicad-developers] New Pcbnew file format.
On 8/04/2012 8:23 p.m., Dick Hollenbeck wrote: On 04/08/2012 11:38 AM, lajos kamocsay wrote: Hi Wayne- The new file format looks awesome. Very simple and readable. Would it be possible to standardize the transformation data? Currently there seems to be a couple different formats, some examples: (draw line (pts xy(76.581 47.9425) xy(77.724 47.9425)) (layer 21) (width 0.127)) (size 1.016 1.651) (at -1.524 0) (at (xyz 0 0 0)) (scale (xyz 0.17 0.16 0.16)) (rotate (xyz 0 0 0)) Thanks, Wayne for your work. Here is my first thoughts (layer 21) uses an internal pcbnew value to identify a layer. I am thinking something like (layer SILKSCREEN_FRONT) is better. Also I am thinking inside the brd file, a field giving current units is good: something like (unit millimeter) -- Jean-Pierre CHARRAS ___ 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
Re: [Kicad-developers] New Pcbnew file format.
On 4/9/2012 6:28 AM, jean-pierre charras wrote: On 8/04/2012 8:23 p.m., Dick Hollenbeck wrote: On 04/08/2012 11:38 AM, lajos kamocsay wrote: Hi Wayne- The new file format looks awesome. Very simple and readable. Would it be possible to standardize the transformation data? Currently there seems to be a couple different formats, some examples: (draw line (pts xy(76.581 47.9425) xy(77.724 47.9425)) (layer 21) (width 0.127)) (size 1.016 1.651) (at -1.524 0) (at (xyz 0 0 0)) (scale (xyz 0.17 0.16 0.16)) (rotate (xyz 0 0 0)) Thanks, Wayne for your work. Here is my first thoughts (layer 21) uses an internal pcbnew value to identify a layer. I am thinking something like (layer SILKSCREEN_FRONT) is better. JP, Thanks for looking at this. I agree that the layer number is not readable. Do we have any code in place to select the layer number by the description? If not, I'll have to add that in order to load the file. Also I am thinking inside the brd file, a field giving current units is good: something like (unit millimeter) Either that or a comment that the units used within the file are in millimeters. I don't think the design goal was to support different units in the file itself unless I missed something. Wayne ___ 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
Re: [Kicad-developers] New Pcbnew file format.
Hi Wayne- I've had a conversation with Dick, and he asked me to clarify my suggestion about standardizing the transformation data. Standardizing would save you work and debugging time because you would only need to write the encoder and decoder (parser) once. Instead of every object taking care of the work, they could just call two external functions (I don't have the code with me, but let's say S_EXPR::EncodeTransformation() and S_EXPR::DecodeTransformation()). The same functions could read/write transformation data for modules, pads, polygon points etc. As a side effect, the data files would be easier to read and write. And I don't necessarily mean footprint makers, but opening the brd files in emacs. But this is just bonus, the biggest win is less coding and more decoupling. You don't need to pick 1d vs 2d vs 3d vectors. It can easily be a mixture, for example: (object (position (vector2 1 1)) (rotation (vector1 1)) (scale (vector1 1)) ) If certain properties are default value, you might not even need to write them (no rotation, 100% scale): (object (position (vector3 1 1 1)) ) You could also separate out the vector encoder and decoder functions, like S_EXPR::EncodeVector3() and S_EXPR::DecodeVector3(). (Again, I don't have the code with me, so class and function names are just examples, and possibly this is how it's already implemented.) Naming is a secondary issue, point3 vs vector3 vs xyz doesn't matter much (although point or vector seems a bit more generic and reusable). Thanks- -lajos On Mon, Apr 9, 2012 at 10:45 AM, Wayne Stambaugh stambau...@verizon.net wrote: On 4/8/2012 12:38 PM, lajos kamocsay wrote: Hi Wayne- The new file format looks awesome. Very simple and readable. Would it be possible to standardize the transformation data? Currently there seems to be a couple different formats, some examples: (draw line (pts xy(76.581 47.9425) xy(77.724 47.9425)) (layer 21) (width 0.127)) (size 1.016 1.651) (at -1.524 0) (at (xyz 0 0 0)) (scale (xyz 0.17 0.16 0.16)) (rotate (xyz 0 0 0)) I think having a standard format would be very helpful for external utilities reading/writing kicad data, like: (object (position xyz(1, 1, 1)) (rotation xyz(0, 0, 0)) (scale xyz(1, 1, 1)) ) Lajos, Thank you for your comments. I carried over the at token from the new schematic and schematic library file formats. For 2D transforms I want to keep this notation so that it is the same between the schematic and board file formats. I'm fine with using a different notation for 3D transforms. My original though was just to use (scale X Y Z) since this is inside a 3D object it may clear enough to the user that 3D transforms require XYZ. Or if you want shorter names, you could use the p/r/s letters for position/rotation/scale or t/s/r for translation/rotation/scale and v3 for a 3d vector: (object (t v3(1, 1, 1)) (r v3(0, 0, 0)) (s v3(1, 1, 1)) ) I want to avoid abbreviations that are not obvious. The file format must be human readable not developer readable. Most of the developers will know what t/r/s means but a normal user shouldn't be expected to wade thought the source code to find out what t/r/s means. The goal is the minimum verbosity to achieve human readability. Thanks, Wayne Although nowadays storage is usually not an issue, and the file can be optionally compressed with zlib. So probably the more verbose names are better. One of the small boards I saved was 28k in the old format, 52k with s-expr, 6k s-expr compressed. Another alternative would be a 3x3 matrix: (object (transform matrix(1, 1, 1, 0, 0, 0, 1, 1, 1)) ) Thanks- -lajos On Sat, Apr 7, 2012 at 2:58 PM, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote: nice!!!, I will start trying it. 2012/4/7 Wayne Stambaugh stambau...@verizon.net Oops! To be able to save to the new file format you must add -DUSE_PCBNEW_SEXPR_FILE_FORMAT=ON and -DUSE_PCBNEW_NANOMETRES=ON when invoking CMake in order to build the new code. On 4/7/2012 2:09 PM, Wayne Stambaugh wrote: It took long than I anticipated (doesn't always?) but I just committed the code to allow saving board files to the new s-expression based file format. I would like as many folks as possible to save their favorite board file using File-Save As to the new format and take a look at the result. My goal is to get the final file format nailed down as quickly as possible. There are few caveats: * I still have to convert angles to degrees from the current tenths of degrees so please ignore the fact that 270° is saved as 2700°. This fix is coming soon. * The lead developers have decided to drop support for the old segment filled zones (SEGZONES) which have not been used in quite some time. I will be adding a dialog warning the user that they will need to refill their zones using the current polygon filling. I doubt this will effect very many users but I could be
Re: [Kicad-developers] New Pcbnew file format.
Le 09/04/2012 17:02, Wayne Stambaugh a écrit : On 4/9/2012 6:28 AM, jean-pierre charras wrote: On 8/04/2012 8:23 p.m., Dick Hollenbeck wrote: On 04/08/2012 11:38 AM, lajos kamocsay wrote: Hi Wayne- The new file format looks awesome. Very simple and readable. Would it be possible to standardize the transformation data? Currently there seems to be a couple different formats, some examples: (draw line (pts xy(76.581 47.9425) xy(77.724 47.9425)) (layer 21) (width 0.127)) (size 1.016 1.651) (at -1.524 0) (at (xyz 0 0 0)) (scale (xyz 0.17 0.16 0.16)) (rotate (xyz 0 0 0)) Thanks, Wayne for your work. Here is my first thoughts (layer 21) uses an internal pcbnew value to identify a layer. I am thinking something like (layer SILKSCREEN_FRONT) is better. JP, Thanks for looking at this. I agree that the layer number is not readable. Do we have any code in place to select the layer number by the description? If not, I'll have to add that in order to load the file. No code to do that. Also I am thinking inside the brd file, a field giving current units is good: something like (unit millimeter) Either that or a comment that the units used within the file are in millimeters. I don't think the design goal was to support different units in the file itself unless I missed something. Wayne Could be just a comment. -- Jean-Pierre CHARRAS ___ 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
Re: [Kicad-developers] New Pcbnew file format.
On 04/09/2012 10:07 AM, Wayne Stambaugh wrote: On 4/9/2012 9:43 AM, Dick Hollenbeck wrote: Wayne and all, I feel better now about PCBNEW loading a BOARD with USE_PCBNEW_NANOMETRES defined after some work I did this weekend. Dick, Great work! Thanks for fixing this so we can keep the new file format compiled in and still use Pcbnew without having to build a separate version with nanometers disabled. Sorry, I did not do this, at least not intentionally. :) Therefore if you're seeing it, it probably does not work :) Mostly I added DMils2iu( int_constant ) so that the PAD margins would not blow up since they were not being scaled. A hard coded 100 became DMils2iu( 100 ) which then is a sensible internal unit, equal in length to 100 deci-mils. As I said last week, do not save your BOARD in legacy format with a USE_KICAD_NANOMETER build, since it will be saved in millimeters. Yet your footprints will be in deci-mils and you will have a mess. The flag USE_KICAD_NANOMETER tells LEGACY_PLUGIN to convert old board units to nanometers, in RAM during Load() and on disk during Save(). This special build is only for generating the s-expression file, then recompile please. Dick Maybe we can get this fairly well tested over the next few weeks and make it the default build. Thanks again, Wayne I was a little nervous about that. It is still slow to load, I think this has to do with zone calculations being done in the higher resolutions, hopefully Jean-Pierre can help with that. To see Wayne's marvelous work, you can now load, then immediately save using Wayne's alternative file type in the save dialog window. Then check out the new file in a text editor. ___ 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
Re: [Kicad-developers] New Pcbnew file format.
Now that may be we're still in time (well in fact, now I think that could be added lately without big impact..) What do you think about adding a UUID (I see now that you used 'LPID' for SWEET) to the PCB files, and also a revision number (that goes incrementally on every modified save). Also adding LPID to module/footprints would be great, think of the concept for one moment: You could be able to keep your brd files in a database (also distributed), and check if your board version is the latest available, even ask for upgrade from kicad. Also, with LPID + rev number in the modules/footprints, you could ask KiCad to interactively update your footprints from the ones you have in the database. For example, somebody in your company could have updated certain footprint to enhance manufacturability or fix a silly orientation bug... etc. I see a world of opportunities just adding: * LPID (or UUID) * File Revision Number (automatical/autoincremental) And also keeping inside the .brd file: LPID + Rev Number of every module. I really love this idea, and I see that you already thought of it for sch / lib parts. 2012/4/9 Dick Hollenbeck d...@softplc.com On 04/09/2012 10:07 AM, Wayne Stambaugh wrote: On 4/9/2012 9:43 AM, Dick Hollenbeck wrote: Wayne and all, I feel better now about PCBNEW loading a BOARD with USE_PCBNEW_NANOMETRES defined after some work I did this weekend. Dick, Great work! Thanks for fixing this so we can keep the new file format compiled in and still use Pcbnew without having to build a separate version with nanometers disabled. Sorry, I did not do this, at least not intentionally. :) Therefore if you're seeing it, it probably does not work :) Mostly I added DMils2iu( int_constant ) so that the PAD margins would not blow up since they were not being scaled. A hard coded 100 became DMils2iu( 100 ) which then is a sensible internal unit, equal in length to 100 deci-mils. As I said last week, do not save your BOARD in legacy format with a USE_KICAD_NANOMETER build, since it will be saved in millimeters. Yet your footprints will be in deci-mils and you will have a mess. The flag USE_KICAD_NANOMETER tells LEGACY_PLUGIN to convert old board units to nanometers, in RAM during Load() and on disk during Save(). This special build is only for generating the s-expression file, then recompile please. Dick Maybe we can get this fairly well tested over the next few weeks and make it the default build. Thanks again, Wayne I was a little nervous about that. It is still slow to load, I think this has to do with zone calculations being done in the higher resolutions, hopefully Jean-Pierre can help with that. To see Wayne's marvelous work, you can now load, then immediately save using Wayne's alternative file type in the save dialog window. Then check out the new file in a text editor. ___ 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 -- Miguel Angel Ajo Pelayo http://www.nbee.es +34 636 52 25 69 skype: ajoajoajo ___ 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
Re: [Kicad-developers] New Pcbnew file format.
On 04/09/2012 02:55 PM, Miguel Angel Ajo Pelayo wrote: Now that may be we're still in time (well in fact, now I think that could be added lately without big impact..) What do you think about adding a UUID (I see now that you used 'LPID' for SWEET) to the PCB files, and also a revision number (that goes incrementally on every modified save). Also adding LPID to module/footprints would be great, think of the concept for one moment: You could be able to keep your brd files in a database (also distributed), and check if your board version is the latest available, even ask for upgrade from kicad. Also, with LPID + rev number in the modules/footprints, you could ask KiCad to interactively update your footprints from the ones you have in the database. For example, somebody in your company could have updated certain footprint to enhance manufacturability or fix a silly orientation bug... etc. I see a world of opportunities just adding: * LPID (or UUID) * File Revision Number (automatical/autoincremental) And also keeping inside the .brd file: LPID + Rev Number of every module. I really love this idea, and I see that you already thought of it for sch / lib parts. Welcome to a 4 year old conversation. Your conceptual grasp is large. But the conversation is old. I thought about a UUID, but I invested money in an LPID. Does that answer your first question adequately? To summarize my feelings: a) what we have in SWEET is revolutionary, since we bring in inheritance, distributed LIBs, and versioning. Please watch for bullshit patents popping up on it to help me out. b) the opportunity and needs in PCBNEW are comparable or greater than in EESCHEMA, I have tended to think of the task as bigger than EESCHEMA. This is a reason why I started with EESCHEMA, because I was certain that we'd learn things there that would be helpful when PCBNEW was re-worked. I have no interest in deviating from this original strategy because of that single reason. c) Once you add a logical library name, you can then abstract its implementation and location. d) Just last week, Jean-Pierre, Wayne and I exchanged emails on bringing in a logical library name into the *.kicad_brd to better identify the origin of a footprint within a board. I think there is support for just this little bit for now. The prior sentence is the most important one in this email, please read it again. Certainly doing more would require more brain cycles than are available at this time, and can always be done down the road in PCBNEW. I was hoping to abstract the library access methodology in the PLUGIN API, without going to the extent that I am in SWEET. For s-expression libraries, we are currently thinking of simply having a directory of s-expression (module) files, rather than a file of footprints. So a footprint library is merely a directory. This is a scouting report, it does not preclude conquering the world at some future point. But please realize that my commitment never even extended to even completing SWEET myself, let alone anything to do with PCBNEW. Said differently, my SWEET design needs implementors beyond myself to complete. SWEET does not apply and cannot apply directly to PCBNEW, although much that is learned there could eventually be used in PCNEW. The only reason we are cramming in the new file format now was the avalanche of the nanometers entering PCBNEW, did not want to disrupt user's lives inconsiderately with multiple file format changes. In summary, we are left dreaming and imagining, but get to each a little popcorn while we are doing it. My commitments are pretty well documented, and trying to commit resources that I do not have control over is foolish. In lose terms, given *current resources* this is what I see: PCBNEW minimally --- EESCHEMA radically --- PCBNEW better much later There are many things where we need help: nanometers: UI, DRC, dialogs, zoom, grid, status display of perhaps increasing drill down resolution as we zoom in. specctra export, gerber testing, etc. EAGLE PLUGIN: SWEET HTTP_LIB_SOURCE, which is likely to be a hell of a lot of fun. 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
Re: [Kicad-developers] New Pcbnew file format.
I love the plan, it matches and extends the tiny idea I had but it's well planned!!, About the SWEET_HTTP_LIB source and even SWEET servers, and web apps, I propose that we could use our (future) new python powers, that are proficient in handling XML-RPC, Databases, and similar things with very very few lines and effort. I have a lot of experience about python+networking+xml-rpc+web apps, and if using the underlying python scripting could fit on the plan, then we will just run ... and enjoy our popcorn more happily. Cheers, Mike 2012/4/9 Dick Hollenbeck d...@softplc.com On 04/09/2012 02:55 PM, Miguel Angel Ajo Pelayo wrote: Now that may be we're still in time (well in fact, now I think that could be added lately without big impact..) What do you think about adding a UUID (I see now that you used 'LPID' for SWEET) to the PCB files, and also a revision number (that goes incrementally on every modified save). Also adding LPID to module/footprints would be great, think of the concept for one moment: You could be able to keep your brd files in a database (also distributed), and check if your board version is the latest available, even ask for upgrade from kicad. Also, with LPID + rev number in the modules/footprints, you could ask KiCad to interactively update your footprints from the ones you have in the database. For example, somebody in your company could have updated certain footprint to enhance manufacturability or fix a silly orientation bug... etc. I see a world of opportunities just adding: * LPID (or UUID) * File Revision Number (automatical/autoincremental) And also keeping inside the .brd file: LPID + Rev Number of every module. I really love this idea, and I see that you already thought of it for sch / lib parts. Welcome to a 4 year old conversation. Your conceptual grasp is large. But the conversation is old. I thought about a UUID, but I invested money in an LPID. Does that answer your first question adequately? To summarize my feelings: a) what we have in SWEET is revolutionary, since we bring in inheritance, distributed LIBs, and versioning. Please watch for bullshit patents popping up on it to help me out. b) the opportunity and needs in PCBNEW are comparable or greater than in EESCHEMA, I have tended to think of the task as bigger than EESCHEMA. This is a reason why I started with EESCHEMA, because I was certain that we'd learn things there that would be helpful when PCBNEW was re-worked. I have no interest in deviating from this original strategy because of that single reason. c) Once you add a logical library name, you can then abstract its implementation and location. d) Just last week, Jean-Pierre, Wayne and I exchanged emails on bringing in a logical library name into the *.kicad_brd to better identify the origin of a footprint within a board. I think there is support for just this little bit for now. The prior sentence is the most important one in this email, please read it again. Certainly doing more would require more brain cycles than are available at this time, and can always be done down the road in PCBNEW. I was hoping to abstract the library access methodology in the PLUGIN API, without going to the extent that I am in SWEET. For s-expression libraries, we are currently thinking of simply having a directory of s-expression (module) files, rather than a file of footprints. So a footprint library is merely a directory. This is a scouting report, it does not preclude conquering the world at some future point. But please realize that my commitment never even extended to even completing SWEET myself, let alone anything to do with PCBNEW. Said differently, my SWEET design needs implementors beyond myself to complete. SWEET does not apply and cannot apply directly to PCBNEW, although much that is learned there could eventually be used in PCNEW. The only reason we are cramming in the new file format now was the avalanche of the nanometers entering PCBNEW, did not want to disrupt user's lives inconsiderately with multiple file format changes. In summary, we are left dreaming and imagining, but get to each a little popcorn while we are doing it. My commitments are pretty well documented, and trying to commit resources that I do not have control over is foolish. In lose terms, given *current resources* this is what I see: PCBNEW minimally --- EESCHEMA radically --- PCBNEW better much later There are many things where we need help: nanometers: UI, DRC, dialogs, zoom, grid, status display of perhaps increasing drill down resolution as we zoom in. specctra export, gerber testing, etc. EAGLE PLUGIN: SWEET HTTP_LIB_SOURCE, which is likely to be a hell of a lot of fun. Dick -- Miguel Angel Ajo Pelayo
Re: [Kicad-developers] New Pcbnew file format.
Hi Wayne- The new file format looks awesome. Very simple and readable. Would it be possible to standardize the transformation data? Currently there seems to be a couple different formats, some examples: (draw line (pts xy(76.581 47.9425) xy(77.724 47.9425)) (layer 21) (width 0.127)) (size 1.016 1.651) (at -1.524 0) (at (xyz 0 0 0)) (scale (xyz 0.17 0.16 0.16)) (rotate (xyz 0 0 0)) I think having a standard format would be very helpful for external utilities reading/writing kicad data, like: (object (position xyz(1, 1, 1)) (rotation xyz(0, 0, 0)) (scale xyz(1, 1, 1)) ) Or if you want shorter names, you could use the p/r/s letters for position/rotation/scale or t/s/r for translation/rotation/scale and v3 for a 3d vector: (object (t v3(1, 1, 1)) (r v3(0, 0, 0)) (s v3(1, 1, 1)) ) Although nowadays storage is usually not an issue, and the file can be optionally compressed with zlib. So probably the more verbose names are better. One of the small boards I saved was 28k in the old format, 52k with s-expr, 6k s-expr compressed. Another alternative would be a 3x3 matrix: (object (transform matrix(1, 1, 1, 0, 0, 0, 1, 1, 1)) ) Thanks- -lajos On Sat, Apr 7, 2012 at 2:58 PM, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote: nice!!!, I will start trying it. 2012/4/7 Wayne Stambaugh stambau...@verizon.net Oops! To be able to save to the new file format you must add -DUSE_PCBNEW_SEXPR_FILE_FORMAT=ON and -DUSE_PCBNEW_NANOMETRES=ON when invoking CMake in order to build the new code. On 4/7/2012 2:09 PM, Wayne Stambaugh wrote: It took long than I anticipated (doesn't always?) but I just committed the code to allow saving board files to the new s-expression based file format. I would like as many folks as possible to save their favorite board file using File-Save As to the new format and take a look at the result. My goal is to get the final file format nailed down as quickly as possible. There are few caveats: * I still have to convert angles to degrees from the current tenths of degrees so please ignore the fact that 270° is saved as 2700°. This fix is coming soon. * The lead developers have decided to drop support for the old segment filled zones (SEGZONES) which have not been used in quite some time. I will be adding a dialog warning the user that they will need to refill their zones using the current polygon filling. I doubt this will effect very many users but I could be wrong. * I rearranged the object ordering slightly compared to the current file format. I moved the graphic items (items with no net connection) before the modules. This way all of the net connectable objects (modules, traces, zones, etc.) will be grouped together. Please take some time to look over the new format. If you find a token (key word) that is not clear, let me know so we can choose names that are as human readable as possible. Please keep in mind that the file size is going to increase dramatically over the current format so try to keep names as brief as possible while still maintaining readability. Also, if you find any indentation or other formatting errors, let me know so I can fix it. I will be working on reading the new file format over the next few days (weeks?) so I would like to wrap up the file format definition in a reasonable amount of time. Thanks in advance for you help. Wayne ___ 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 -- Miguel Angel Ajo Pelayo http://www.nbee.es +34 636 52 25 69 skype: ajoajoajo ___ 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
Re: [Kicad-developers] New Pcbnew file format.
On 04/08/2012 11:38 AM, lajos kamocsay wrote: Hi Wayne- The new file format looks awesome. Very simple and readable. Would it be possible to standardize the transformation data? Currently there seems to be a couple different formats, some examples: (draw line (pts xy(76.581 47.9425) xy(77.724 47.9425)) (layer 21) (width 0.127)) (size 1.016 1.651) (at -1.524 0) (at (xyz 0 0 0)) (scale (xyz 0.17 0.16 0.16)) (rotate (xyz 0 0 0)) I think having a standard format would be very helpful for external utilities reading/writing kicad data, like: Without diminishing your point about standardization, I suggest that Miquel's scripting interface will soon be the recommended way to write external tools. And as such, folks writing directly to the KiCad file formats will be missing the point of the scripting API, so they will not get any of my attention, at least. Back to the transformation data, we have both 3d and 2d transforms, and it would be sensible to allow them to be different. Also, the SWEET parser is already written, works on 2d transform data, and I assume Wayne took that into consideration. Changing the 2d SWEET stuff is something I would not embrace easily. I am not taking such a position on this new BOARD format yet however, but rather keeping an open mind. However, achieving some 2d transform similarly between SWEET and BOARD might have at least some value. 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
Re: [Kicad-developers] New Pcbnew file format.
I must be doing something very silly just pulled from bzr, and then mkdir building cd building cmake -i ../ make and make says nothing at all, and exists :-? I must re-read the compiling guide ':-) 2012/4/8 Dick Hollenbeck d...@softplc.com On 04/08/2012 11:38 AM, lajos kamocsay wrote: Hi Wayne- The new file format looks awesome. Very simple and readable. Would it be possible to standardize the transformation data? Currently there seems to be a couple different formats, some examples: (draw line (pts xy(76.581 47.9425) xy(77.724 47.9425)) (layer 21) (width 0.127)) (size 1.016 1.651) (at -1.524 0) (at (xyz 0 0 0)) (scale (xyz 0.17 0.16 0.16)) (rotate (xyz 0 0 0)) I think having a standard format would be very helpful for external utilities reading/writing kicad data, like: Without diminishing your point about standardization, I suggest that Miquel's scripting interface will soon be the recommended way to write external tools. And as such, folks writing directly to the KiCad file formats will be missing the point of the scripting API, so they will not get any of my attention, at least. Back to the transformation data, we have both 3d and 2d transforms, and it would be sensible to allow them to be different. Also, the SWEET parser is already written, works on 2d transform data, and I assume Wayne took that into consideration. Changing the 2d SWEET stuff is something I would not embrace easily. I am not taking such a position on this new BOARD format yet however, but rather keeping an open mind. However, achieving some 2d transform similarly between SWEET and BOARD might have at least some value. 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 -- Miguel Angel Ajo Pelayo http://www.nbee.es +34 636 52 25 69 skype: ajoajoajo ___ 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
Re: [Kicad-developers] New Pcbnew file format.
Hi Miguel- You probably figured it out already, but here's my super simple build script for the latest. Assuming you already have the bzr branch in this structure: 42 |- build_latest# build script, chmod a+x |- kicad.latest# as it says |- build.latest # this folder the script makes automatically -lajos #/bin/zsh -f mkdir -p build.latest cd build.latest cmake ../kicad.latest -DKICAD_STABLE_VERSION=ON -DCMAKE_BUILD_TYPE=Release \ -DUSE_PCBNEW_SEXPR_FILE_FORMAT=ON -DUSE_PCBNEW_NANOMETRES=ON \ -DCMAKE_INSTALL_PREFIX=/usr make On Sun, Apr 8, 2012 at 3:25 PM, Miguel Angel Ajo Pelayo miguelan...@nbee.es wrote: I must be doing something very silly just pulled from bzr, and then mkdir building cd building cmake -i ../ make and make says nothing at all, and exists :-? I must re-read the compiling guide ':-) 2012/4/8 Dick Hollenbeck d...@softplc.com On 04/08/2012 11:38 AM, lajos kamocsay wrote: Hi Wayne- The new file format looks awesome. Very simple and readable. Would it be possible to standardize the transformation data? Currently there seems to be a couple different formats, some examples: (draw line (pts xy(76.581 47.9425) xy(77.724 47.9425)) (layer 21) (width 0.127)) (size 1.016 1.651) (at -1.524 0) (at (xyz 0 0 0)) (scale (xyz 0.17 0.16 0.16)) (rotate (xyz 0 0 0)) I think having a standard format would be very helpful for external utilities reading/writing kicad data, like: Without diminishing your point about standardization, I suggest that Miquel's scripting interface will soon be the recommended way to write external tools. And as such, folks writing directly to the KiCad file formats will be missing the point of the scripting API, so they will not get any of my attention, at least. Back to the transformation data, we have both 3d and 2d transforms, and it would be sensible to allow them to be different. Also, the SWEET parser is already written, works on 2d transform data, and I assume Wayne took that into consideration. Changing the 2d SWEET stuff is something I would not embrace easily. I am not taking such a position on this new BOARD format yet however, but rather keeping an open mind. However, achieving some 2d transform similarly between SWEET and BOARD might have at least some value. 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 -- Miguel Angel Ajo Pelayo http://www.nbee.es +34 636 52 25 69 skype: ajoajoajo ___ 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
Re: [Kicad-developers] New Pcbnew file format.
Oops! To be able to save to the new file format you must add -DUSE_PCBNEW_SEXPR_FILE_FORMAT=ON and -DUSE_PCBNEW_NANOMETRES=ON when invoking CMake in order to build the new code. On 4/7/2012 2:09 PM, Wayne Stambaugh wrote: It took long than I anticipated (doesn't always?) but I just committed the code to allow saving board files to the new s-expression based file format. I would like as many folks as possible to save their favorite board file using File-Save As to the new format and take a look at the result. My goal is to get the final file format nailed down as quickly as possible. There are few caveats: * I still have to convert angles to degrees from the current tenths of degrees so please ignore the fact that 270° is saved as 2700°. This fix is coming soon. * The lead developers have decided to drop support for the old segment filled zones (SEGZONES) which have not been used in quite some time. I will be adding a dialog warning the user that they will need to refill their zones using the current polygon filling. I doubt this will effect very many users but I could be wrong. * I rearranged the object ordering slightly compared to the current file format. I moved the graphic items (items with no net connection) before the modules. This way all of the net connectable objects (modules, traces, zones, etc.) will be grouped together. Please take some time to look over the new format. If you find a token (key word) that is not clear, let me know so we can choose names that are as human readable as possible. Please keep in mind that the file size is going to increase dramatically over the current format so try to keep names as brief as possible while still maintaining readability. Also, if you find any indentation or other formatting errors, let me know so I can fix it. I will be working on reading the new file format over the next few days (weeks?) so I would like to wrap up the file format definition in a reasonable amount of time. Thanks in advance for you help. Wayne ___ 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
