Re: [Kicad-developers] Undo stack limit?
+1 - Just a user here, Thank You for this. On 8/4/2015 5:32 PM, Chris Pavlina wrote: In any case, here's the patch to make undo configurable. I can edit it to change the default if you like. ___ 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
[Kicad-developers] proposed changes to VRML and IDF exporters
Hi folks, I'd like an opinion on some changes I'd like to make to the VRML and IDF exporters before the stable release. 1. VRML: In "Export VRML" the choices of unit in the output file are Inch, mm, and meter. In my opinion the 'meter' option is 100% useless and I propose to change this to 100 mil (or equivalently, 0.1 inch). This will push the VRML exporter 1 step closer to being able to export a model which can be reused as a subassembly within KiCad. I don't know the current state of the VRML parser code - but if the parser currently resolves URNs then adding this 0.1 inch option will indeed produce models which can be fed back into KiCad. 2. IDF: My treatment of the 'offset' values in the IDF exporter is wrong; this is a bug although not a bug which is likely to be seen in action. I propose to fix this bug before the release. It might sound silly that I ask for an opinion before doing this task, but the reason I ask is that I really haven't got much free time at all so I wouldn't bother unless others believed that I should fix the bug immediately. - 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] Export to Solidworks
Hi Saumell, When you need to give your 3d artwork to MCAD people you have to use step as interchange format. Any other format would not be accepted. Before the kicad stepup script the only way I know to export the pcb with models was to export vrml and then convert it to step; but any model converted from vrml would be very un-optimal and not very useful for mechanical design (I learned the hard way)... the conversion, using whatever sw you find, will generate a bunch of triangles. as Cirilo suggested, please have a try with kicad-stepup script: http://bazaar.launchpad.net/~easyw/kicad-stepup/trunk/files http://sourceforge.net/projects/kicadstepup/ I'm going to write an howto to be included in kicad doc. At the moment the README.txt file gives you a small explanation. @youtube you can see also a small howto video https://www.youtube.com/watch?v=Ukd47VXYzQU I've also added the option to move the board and modules to a base point, and the bounding boxes option (to export all or selected modules to bbox) At the moment the kicad library lacks of STEP modules... I've suggested to add to the 3D repository at least models generated from FreeCAD https://github.com/KiCad/kicad-library/issues/186 FreeCAD could be used as second source to model 3D object to kicad, side by side with wings3d. Moreover FreeCAD can create parametric model, with real dimensions as per the physical objects. Anyway, if you need just a rapid solution, you can get 3d models at http://3dcontentcentral.com/ the only requirement for the script to work is to have the single models as a single fused object you can find some tips to align and use the modules here: https://forum.kicad.info/t/kicad-stepup-new-exporter-for-3d-mcad-feedbacks-are-welcome/1048 To test the script in real world, I used hackrf-one board and I generated all 3d vrml modules to be used in kicad, directly from step modules downloaded from the manufacturers or from 3dcontent central library. All the modules converted from FreeCAD to wrl has been used in kicad 3d-viewer without any issue. The STEP generated model has been tested in Solid Works and it is fine without any geometry problem. Could you please give me a feed back of your test, so to improve the script usability for kicad users? thank you Maurice On 05/08/2015 00.17, Cirilo Bernardo wrote: There are a number of options: 1. Recently Maurice wrote a script which uses FreeCAD to create a STEP modelusing the bare board IDF file and other data in the .kicad_pcb file: http://bazaar.launchpad.net/~easyw/kicad-stepup/trunk/files No doubt there are still some issues but this is currently the best method for exporting a detailed mechanical model. 2. IDF: If you do nothing and simply opt to export the board then you only get a bare board - this step is necessary anyway if you use Maurice's script to create a STEP model. If you wish for a more detailed IDF model you will need to spend some time creating the associated component outline files. The official IDF documentation is here: https://github.com/ciampix/kicad-doc/tree/master/src/IDF_Exporter but if you can't generate the documentation and want a PDF version the original (more inaccurate) version is here: https://drive.google.com/open?id=0By_XTJN-s8aXbkM5UTE0Zm5SN28 Now for Solidworks to process an IDF file you need CircuitWorks which is only provided with "Solidworks Premium" - bummer. Fortunately you can now convert IDF to IGES (which any MCAD can understand) using the 'idf2igs' tool in the IGES library which is in development: https://github.com/cbernardo/libIGES There are also online tools to help such as: https://www.ecad.io That site provides all the functionality of CircuitWorks - you can substitute real models for the simplistic IDF outlines. However, if the simple IDF outlines are fine for your mechanical work then the libIGES tool is a completely free solution. Expect more MCAD exchange features in the future, though the wait may be a little long due to limited resources. My libIGES already has the capability to create models of the bare PCB and to add other existing IGES models to the mechanical assembly and I plan to add an IGES export to KiCad some time after the pending stable release. Unfortunately I also need to do some major work on the KiCad code base before I add this code so it could be another 6 months or more before you see that feature in KiCad. There have also been discussions on adding a STEP export facility using the OpenCascade libraries, but this is also dependent on those code changes which I need to make to KiCad. So for now, Maurice's scripts are really the best option for creating a detailed mechanical model. - Cirilo On Wed, Aug 5, 2015 at 7:21 AM, Jose A. Saumell mailto:saumell.j...@gmail.com>> wrote: Hello group, I have been trying to export a 3D model of a populated PCB to Solidworks and after a few days I want to ask you for help. I've generated VRML files for each componen
Re: [Kicad-developers] proposed changes to VRML and IDF exporters
Hi Cirilo, which is the offset problem in IDF exporter? At the moment the only issue I've found in the IDF exported file is the offset of the pcb when you rotate the board and components inside kicad pcbnew before export the IDF file (but I think is a quite improbable case)... thank you Maurice On 05/08/2015 10.22, Cirilo Bernardo wrote: Hi folks, I'd like an opinion on some changes I'd like to make to the VRML and IDF exporters before the stable release. 1. VRML: In "Export VRML" the choices of unit in the output file are Inch, mm, and meter. In my opinion the 'meter' option is 100% useless and I propose to change this to 100 mil (or equivalently, 0.1 inch). This will push the VRML exporter 1 step closer to being able to export a model which can be reused as a subassembly within KiCad. I don't know the current state of the VRML parser code - but if the parser currently resolves URNs then adding this 0.1 inch option will indeed produce models which can be fed back into KiCad. 2. IDF: My treatment of the 'offset' values in the IDF exporter is wrong; this is a bug although not a bug which is likely to be seen in action. I propose to fix this bug before the release. It might sound silly that I ask for an opinion before doing this task, but the reason I ask is that I really haven't got much free time at all so I wouldn't bother unless others believed that I should fix the bug immediately. - 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 ___ 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
[Kicad-developers] Segfault when pcbnew starts with an invalid file
Pcbnew without scripting support crashes when run with an invalid file given as a parameter (stack overflow in ~wxSingleInstanceChecker()). There is a fix for that, but wrapped with #ifdef KICAD_SCRIPTING_WXPYTHON .. #endif. I removed the mentioned directives and it seems fine here, but I am not confident enough to commit it immediately. Any thoughts? Regards, Orson diff --git a/common/single_top.cpp b/common/single_top.cpp index 5c2dcd4..1de8cd0 100644 --- a/common/single_top.cpp +++ b/common/single_top.cpp @@ -288,9 +288,8 @@ bool PGM_SINGLE_TOP::OnPgmInit( wxApp* aWxApp ) // We've already initialized things at this point, but wx won't call OnExit if // we fail out. Call our own cleanup routine here to ensure the relevant resources // are freed at the right time (if they aren't, segfaults will occur). -#if defined( KICAD_SCRIPTING_WXPYTHON ) OnPgmExit(); -#endif + // Fail the process startup if the file could not be opened, // although this is an optional choice, one that can be reversed // also in the KIFACE specific OpenProjectFiles() return value. signature.asc Description: OpenPGP digital signature ___ 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] proposed changes to VRML and IDF exporters
Hi Maurice, The X,Y,Z offset associated with the individual IDF component models is interpreted as whatever the currently selected pcbnew units are (mm, inch) so the interpretation varies. I need to change the code so that the XYZ offset is always interpreted as inches. The board offset is a different matter; I use an approximation of the board center for (0,0) but it would be much better if the reference point can be specified so the user can control this. - Cirilo On Wed, Aug 5, 2015 at 6:37 PM, easyw wrote: > Hi Cirilo, > > which is the offset problem in IDF exporter? > At the moment the only issue I've found in the IDF exported file is the > offset of the pcb when you rotate the board and components inside kicad > pcbnew before export the IDF file (but I think is a quite improbable > case)... > > thank you > Maurice > > > > On 05/08/2015 10.22, Cirilo Bernardo wrote: > >> Hi folks, >> >> I'd like an opinion on some changes I'd like to make to the VRML >> and IDF exporters before the stable release. >> >> 1. VRML: In "Export VRML" the choices of unit in the output file are >> Inch, mm, and meter. In my opinion the 'meter' option is 100% >> useless and I propose to change this to 100 mil (or equivalently, >> 0.1 inch). This will push the VRML exporter 1 step closer to being >> able to export a model which can be reused as a subassembly >> within KiCad. I don't know the current state of the VRML parser >> code - but if the parser currently resolves URNs then adding this >> 0.1 inch option will indeed produce models which can be fed back >> into KiCad. >> >> 2. IDF: My treatment of the 'offset' values in the IDF exporter is >> wrong; this is a bug although not a bug which is likely to be >> seen in action. I propose to fix this bug before the release. It might >> sound silly that I ask for an opinion before doing this task, but >> the reason I ask is that I really haven't got much free time at all >> so I wouldn't bother unless others believed that I should fix the bug >> immediately. >> >> - 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 >> >> ___ 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] official web page
@Marco what could I do to prepare a small tutorial for the kicad stepup script? do you accept libre-office file or pdf file? I'm sorry but I'm new to the doc side :) thank you Maurice On 17/07/2015 15.12, Wayne Stambaugh wrote: On 7/17/2015 3:36 AM, Mário Luzeiro wrote: Excellent! Do you (all) think should be nice to have a small step tutorial / explanation how can someone reproduce identical results for another boards? Yes. Any help we can provide our users is a good thing. Something like this should be added to the user documentation either as part of the Pcbnew manual or as a stand alone tutorial. I don't have a preference one way or another so I'll leave that decision to our documentation experts. Mario Luzeiro From: Kicad-developers [kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on behalf of easyw [ea...@katamail.com] Sent: 17 July 2015 02:43 To: Marcos Chaparro; KiCad Developers Subject: Re: [Kicad-developers] official web page Hi Marcos and all, it took me a bit but here is the hackrf-one generated with STEP models by kicad stepup script and the hackrf-one in kicad 3d-viewer with all the 3d-models generated from the conversion of the STEP models. I also checked the geometries of the generated board with models and there are no problems ... The rendering result shows that the two scenarios are exactly the same, and I didn't get any problem in rendering all the vrml models in kicad. generating the 3D modes in FreeCAD will produce a vrml 3D models with no shading issues and with mechanical respect of all the dimensions It would be nice if some of these screenshots could be in the official web page... please let me know what you think ___ 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] official web page
Maurice, I think Marco is currently on vacation. The new documentation format is asciidoc. You can use git to clone the current documentation at https://github.com/ciampix/kicad-doc. Information on how to use asciidoc can be found at http://www.methods.co.nz/asciidoc/ Wayne On 8/5/2015 8:23 AM, easyw wrote: > @Marco > > what could I do to prepare a small tutorial for the kicad stepup script? > do you accept libre-office file or pdf file? > I'm sorry but I'm new to the doc side :) > > thank you > Maurice > > On 17/07/2015 15.12, Wayne Stambaugh wrote: >> On 7/17/2015 3:36 AM, Mário Luzeiro wrote: >>> Excellent! >>> >>> Do you (all) think should be nice to have a small step tutorial / >>> explanation how can someone reproduce identical results for another >>> boards? >> >> Yes. Any help we can provide our users is a good thing. Something like >> this should be added to the user documentation either as part of the >> Pcbnew manual or as a stand alone tutorial. I don't have a preference >> one way or another so I'll leave that decision to our documentation >> experts. >> >>> >>> Mario Luzeiro >>> >>> From: Kicad-developers >>> [kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on >>> behalf of easyw [ea...@katamail.com] >>> Sent: 17 July 2015 02:43 >>> To: Marcos Chaparro; KiCad Developers >>> Subject: Re: [Kicad-developers] official web page >>> >>> Hi Marcos and all, >>> >>> it took me a bit but here is the hackrf-one generated with STEP models >>> by kicad stepup script and the hackrf-one in kicad 3d-viewer with all >>> the 3d-models generated from the conversion of the STEP models. >>> I also checked the geometries of the generated board with models and >>> there are no problems ... >>> >>> The rendering result shows that the two scenarios are exactly the same, >>> and I didn't get any problem in rendering all the vrml models in kicad. >>> >>> generating the 3D modes in FreeCAD will produce a vrml 3D models with no >>> shading issues and with mechanical respect of all the dimensions >>> >>> It would be nice if some of these screenshots could be in the official >>> web page... >>> >>> please let me know what you think >>> > > ___ > 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] [PATCH] Minor fix: FlexGrid dimensions in DIALOG_EESCHEMA_OPTIONS under GTK
Patch committed in product branch r6051. Thanks. On 8/3/2015 10:09 AM, Chris Pavlina wrote: > The FlexGridSizer in DIALOG_EESCHEMA_OPTIONS is not set to have flexible > row heights. This makes it ugly under many GTK themes, which do not > properly support both the dropdown list button and the numeric > spin-buttons at all sizes. This is a quick patch to set the flexible > direction to "both" instead of "horizontal" to allow all of these > elements to take on their natural dimension as preferred by the system > theme. > > -- > Chris > > > > ___ > 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] [PATCH] Small string formatting annoyance
Your patch has been committed in the product branch r6052. Thank you for your contribution to KiCad. Cheers, Wayne On 8/1/2015 9:50 PM, Jon Neal wrote: > Hi, > > I noticed a long time ago that in the pcbnew plot dialog there is an > extra space in the text for selecting the gerber version. I'm not sure > if this is intentional, but this patch removes the extra space. > > If this gets submitted are there any changes needed for translating the > string? > > Thanks, > Jon Neal > > > ___ > 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] Segfault when pcbnew starts with an invalid file
Chris has pointed out that it was already discussed [1] and the change was not entirely clear. Apparently it had not been wrapped before revision 5834, so maybe OnPgmExit() should be still called for both Python and non-Python versions of pcbnew? Regards, Orson 1. https://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg14014.html On 08/05/2015 11:22 AM, Maciej Sumiński wrote: > Pcbnew without scripting support crashes when run with an invalid file > given as a parameter (stack overflow in ~wxSingleInstanceChecker()). > > There is a fix for that, but wrapped with #ifdef > KICAD_SCRIPTING_WXPYTHON .. #endif. I removed the mentioned directives > and it seems fine here, but I am not confident enough to commit it > immediately. Any thoughts? > > Regards, > Orson > > > > ___ > 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 > signature.asc Description: OpenPGP digital signature ___ 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] Undo stack limit?
Patch committed in product branch r6053. Thanks. On 8/4/2015 5:32 PM, Chris Pavlina wrote: > In any case, here's the patch to make undo configurable. I can edit it > to change the default if you like. > > On Mon, Aug 04, 2015 at 11:53:18AM -0400, Wayne Stambaugh wrote: >> Since it's a refinement to an existing feature (undo) and the risk is >> low that there will be any issues, go ahead and make the change and I >> will commit it. It looks like we have some time since there are a few >> segfault bugs that need to be addressed. You may also want to make an >> undo value of zero be infinite undo/redo. >> >> On 8/3/2015 8:07 AM, Chris Pavlina wrote: >>> Good point. I think I'll prepare a patch, then, that adds to both >>> eeschema and pcbnew an option in the preferences dialog: "Maximum number >>> of undo items", which defaults to 50 and can be set to any positive >>> integer. Up to you and Wayne, of course, whether you'd rather hold onto >>> it until after the stable release (I'm fine with that), but I would >>> definitely like to see this changed in the near future. >>> >>> On Mon, Aug 03, 2015 at 02:02:42PM +0200, jp charras wrote: Le 03/08/2015 13:38, Chris Pavlina a écrit : > It seems I'm not the only one who occasionally finds the undo stack size > limit of ten to be, er, limiting. Would anyone object to raising this > limit to something like fifty? I can't see any place where that is > likely to cause issues, and the data doesn't use very much memory. > > -- > Chris There is not technical reason to limit the undo stack to 10. It can be increased to a larger value. However if it is increased, developers need an user option (the best for me is a choice in config setup) to set this limit to a lower value when debugging/testing kicad. Why? Just because some bugs hard to find can be seen only when the undo stack reaches this limit. When this limit is reached, items in undo stack are actually deleted. And bugs like double deletion or a pointer to deleted items can be seen only when the limit is reached. -- 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 >>> >>> ___ >>> 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 ___ 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] Segfault when pcbnew starts with an invalid file
On 8/5/2015 10:16 AM, Maciej Sumiński wrote: > Chris has pointed out that it was already discussed [1] and the change > was not entirely clear. Apparently it had not been wrapped before > revision 5834, so maybe OnPgmExit() should be still called for both > Python and non-Python versions of pcbnew? This was done because the problem did not occur when wxPython scripting was disabled and Dick is planning on add wxPython on top of Kicad rather than a bolted onto the side like our current implementation. Compiling OnPgmExit() out of non wxPython builds was at his request. The original crash had to do with wxPython clean up not being called properly. I just tried to duplicate this bug on a 32 bit build on windows by running 'pcbnew foo` with no scripting enabled, and I cannot get it to crash. Are you testing this on Linux? > > Regards, > Orson > > 1. > https://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg14014.html > > On 08/05/2015 11:22 AM, Maciej Sumiński wrote: >> Pcbnew without scripting support crashes when run with an invalid file >> given as a parameter (stack overflow in ~wxSingleInstanceChecker()). >> >> There is a fix for that, but wrapped with #ifdef >> KICAD_SCRIPTING_WXPYTHON .. #endif. I removed the mentioned directives >> and it seems fine here, but I am not confident enough to commit it >> immediately. Any thoughts? >> >> Regards, >> Orson >> >> >> >> ___ >> 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] Segfault when pcbnew starts with an invalid file
On 08/05/2015 04:39 PM, Wayne Stambaugh wrote: > On 8/5/2015 10:16 AM, Maciej Sumiński wrote: >> Chris has pointed out that it was already discussed [1] and the change >> was not entirely clear. Apparently it had not been wrapped before >> revision 5834, so maybe OnPgmExit() should be still called for both >> Python and non-Python versions of pcbnew? > > This was done because the problem did not occur when wxPython scripting > was disabled and Dick is planning on add wxPython on top of Kicad rather > than a bolted onto the side like our current implementation. > Compiling OnPgmExit() out of non wxPython builds was at his request. > The original crash had to do with wxPython clean up not being called > properly. I just tried to duplicate this bug on a 32 bit build on > windows by running 'pcbnew foo` with no scripting enabled, and I cannot > get it to crash. Are you testing this on Linux? Yes, but please try with a file with invalid contents, so there is an IO_ERROR exception thrown. Regards, Orson >> >> Regards, >> Orson >> >> 1. >> https://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg14014.html >> >> On 08/05/2015 11:22 AM, Maciej Sumiński wrote: >>> Pcbnew without scripting support crashes when run with an invalid file >>> given as a parameter (stack overflow in ~wxSingleInstanceChecker()). >>> >>> There is a fix for that, but wrapped with #ifdef >>> KICAD_SCRIPTING_WXPYTHON .. #endif. I removed the mentioned directives >>> and it seems fine here, but I am not confident enough to commit it >>> immediately. Any thoughts? >>> >>> Regards, >>> Orson >>> >>> >>> >>> ___ >>> 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 > signature.asc Description: OpenPGP digital signature ___ 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] Segfault when pcbnew starts with an invalid file
On 8/5/2015 10:41 AM, Maciej Sumiński wrote: > On 08/05/2015 04:39 PM, Wayne Stambaugh wrote: >> On 8/5/2015 10:16 AM, Maciej Sumiński wrote: >>> Chris has pointed out that it was already discussed [1] and the change >>> was not entirely clear. Apparently it had not been wrapped before >>> revision 5834, so maybe OnPgmExit() should be still called for both >>> Python and non-Python versions of pcbnew? >> >> This was done because the problem did not occur when wxPython scripting >> was disabled and Dick is planning on add wxPython on top of Kicad rather >> than a bolted onto the side like our current implementation. >> Compiling OnPgmExit() out of non wxPython builds was at his request. >> The original crash had to do with wxPython clean up not being called >> properly. I just tried to duplicate this bug on a 32 bit build on >> windows by running 'pcbnew foo` with no scripting enabled, and I cannot >> get it to crash. Are you testing this on Linux? > > Yes, but please try with a file with invalid contents, so there is an > IO_ERROR exception thrown. Tried that too, no difference. I cannot get pcbnew to crash. It just pops up a dialog complaining about the parse error and exits normally as I expect. I'll take a look at this on Linux tonight when I get home. > > Regards, > Orson > >>> >>> Regards, >>> Orson >>> >>> 1. >>> https://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg14014.html >>> >>> On 08/05/2015 11:22 AM, Maciej Sumiński wrote: Pcbnew without scripting support crashes when run with an invalid file given as a parameter (stack overflow in ~wxSingleInstanceChecker()). There is a fix for that, but wrapped with #ifdef KICAD_SCRIPTING_WXPYTHON .. #endif. I removed the mentioned directives and it seems fine here, but I am not confident enough to commit it immediately. Any thoughts? Regards, Orson ___ 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 >> > > ___ 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] Gerber output units?
Agreed 90%. I don't have so much of a problem with "fixing" the dimensions as long as they're only fixed in the Gerber export, not in the master - it's just part of exporting, you're rendering things with the features available to you in the destination format. But that's a minor point, obviously I don't want to turn the alternative units back on if they don't work. I wasn't aware of this problem. On Wed, Aug 05, 2015 at 10:56:02AM -0400, Wayne Stambaugh wrote: > > > On 8/4/2015 3:03 PM, jp charras wrote: > > Le 04/08/2015 08:29, Lorenzo Marcantonio a écrit : > >> On Tue, 04 Aug 2015 05:38:26 +0200, > >> Chris Pavlina wrote: > >>> > >>> pcbnew used to be able to plot Gerbers in imperial units. What happened > >>> to that? Some (particularly older and non-Asian) board houses still > >>> expect those... Is there any reason they were removed, or did they just > >>> "fall out"? And can they be put back in? > >> > >> Since the new plotting infrastructure the gerber plotter already > >> supported both units; the IN was simply the compatibility default and it > >> only needed an UI option to be bound. > >> > >> If someone changed the default without adding a radio button or > >> something then blame to him:P > >> > >> AFAIK there would be no technical reason to not do inch plotting... > >> > > > > There is a technical reason to not do inch plotting. > > I recently explained it. > > > > Pcbnew internally uses nanometers, corresponding to 6 digits mantissa in > > Gerber. > > > > If we use a 6 digits mantissa and mm in Gerber, there is no rounding issue. > > If we convert these values to inches, I am pretty sure rounding issues > > will appear. > > > > For most of coordinates, a rounding issue has no matter. > > However, for complex polygons (copper zones) rounding coordinates can > > create self intersecting polygons from non intersecting polygons. > > Self intersecting polygons are not allowed in Gerber files (see gerber > > file format spec). > > > > The advice from Ucamco is (especially for this issue) is: > > use the max resolution for coordinates (see also the gerber file format > > spec). > > > > > > The only one reason the 5 digits mantissa option exists in Pcbnew is the > > fact Ucamco told me a few Gerbers tools do not accept the 6 digits. > > > > I verified some Gerber files which are OK with 6 digits mantissa create > > self intersecting polygons when using 5 digits from the same board. > > (Tests with GC-Preview) > > > > (to tell the True, the Gerber image on screen was the same) > > > > We already have a bug report about self intersecting polygons in Gerber > > files from Kicad. > > > > It also explains why a Gerber reader can gives warnings about that > > issue, and an other Gerber reader does not find any issue: it depends > > also on internal units of the reader. > > > > > > Therefore, until someone give me a *very good reason* why inches are > > better than mm in Gerber files, I *do not want* a inch option in Gerber > > plot menu ( or, if this option exists, commit an algo to avoid self > > intersecting polygons). > > > > I'm going to side with JP on this one. Simply enabling the conversion > from the internal nanometer units to inches for gerber plotting is not > an acceptable solution no matter how harmless it may seem on the > surface. The combination of loss of precision and the floating point > rounding errors can potentially lead to self intersecting polygons as JP > has mentioned. Whether or not these errors are significant is design > dependent. It's most likely that they would not result in an issue for > most designs but I would rather error on the side of caution on this issue. > > Any solution to this problem must include an algorithm to detect and > potentially correct the problem. The issue I see with this is the > correction algorithm. Programmatically fixing the self intersecting > polygons when they occur may or may not be what the user intended. The > question then becomes what to do about. One option is to warn the user > and tell them to fix the offending object dimensions. Another option is > to fix the offending object and warn the user of the change. I would > oppose silently fixing the offending objects without the user's knowledge. > > ___ > 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] PATCH: improve library install script a little
Patch committed in the product branch r6054. Thanks. On 8/4/2015 9:30 PM, Henner Zeller wrote: > Hi, > Some small changes for the library-repos-install.sh script. > > https://github.com/hzeller/kicad/compare/master...hzeller:script-no-grep-dependency.diff > > Suggested commit message: > > o library install script improvements >- Make WORKING_TREES configurable with environment variable to > simplify external install scripts. >- Don't use grep but native sed functionality to find relevant > lines in github JSON (grep can create trouble if there is a > global --color=always setting) > > (guess how I found out about the color setting haha). > > -h > > > ___ > 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] Gerber output units?
On 8/4/2015 3:03 PM, jp charras wrote: > Le 04/08/2015 08:29, Lorenzo Marcantonio a écrit : >> On Tue, 04 Aug 2015 05:38:26 +0200, >> Chris Pavlina wrote: >>> >>> pcbnew used to be able to plot Gerbers in imperial units. What happened >>> to that? Some (particularly older and non-Asian) board houses still >>> expect those... Is there any reason they were removed, or did they just >>> "fall out"? And can they be put back in? >> >> Since the new plotting infrastructure the gerber plotter already >> supported both units; the IN was simply the compatibility default and it >> only needed an UI option to be bound. >> >> If someone changed the default without adding a radio button or >> something then blame to him:P >> >> AFAIK there would be no technical reason to not do inch plotting... >> > > There is a technical reason to not do inch plotting. > I recently explained it. > > Pcbnew internally uses nanometers, corresponding to 6 digits mantissa in > Gerber. > > If we use a 6 digits mantissa and mm in Gerber, there is no rounding issue. > If we convert these values to inches, I am pretty sure rounding issues > will appear. > > For most of coordinates, a rounding issue has no matter. > However, for complex polygons (copper zones) rounding coordinates can > create self intersecting polygons from non intersecting polygons. > Self intersecting polygons are not allowed in Gerber files (see gerber > file format spec). > > The advice from Ucamco is (especially for this issue) is: > use the max resolution for coordinates (see also the gerber file format > spec). > > > The only one reason the 5 digits mantissa option exists in Pcbnew is the > fact Ucamco told me a few Gerbers tools do not accept the 6 digits. > > I verified some Gerber files which are OK with 6 digits mantissa create > self intersecting polygons when using 5 digits from the same board. > (Tests with GC-Preview) > > (to tell the True, the Gerber image on screen was the same) > > We already have a bug report about self intersecting polygons in Gerber > files from Kicad. > > It also explains why a Gerber reader can gives warnings about that > issue, and an other Gerber reader does not find any issue: it depends > also on internal units of the reader. > > > Therefore, until someone give me a *very good reason* why inches are > better than mm in Gerber files, I *do not want* a inch option in Gerber > plot menu ( or, if this option exists, commit an algo to avoid self > intersecting polygons). > I'm going to side with JP on this one. Simply enabling the conversion from the internal nanometer units to inches for gerber plotting is not an acceptable solution no matter how harmless it may seem on the surface. The combination of loss of precision and the floating point rounding errors can potentially lead to self intersecting polygons as JP has mentioned. Whether or not these errors are significant is design dependent. It's most likely that they would not result in an issue for most designs but I would rather error on the side of caution on this issue. Any solution to this problem must include an algorithm to detect and potentially correct the problem. The issue I see with this is the correction algorithm. Programmatically fixing the self intersecting polygons when they occur may or may not be what the user intended. The question then becomes what to do about. One option is to warn the user and tell them to fix the offending object dimensions. Another option is to fix the offending object and warn the user of the change. I would oppose silently fixing the offending objects without the user's knowledge. ___ 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
[Kicad-developers] Gerber output units?
On Wed, 5 Aug 2015, Wayne Stambaugh wrote: > >>> to that? Some (particularly older and non-Asian) board houses still > >>> expect those... Is there any reason they were removed so, an articulated use case for the inch output >> AFAIK there would be no technical reason to not do inch >> plotting... > If we use a 6 digits mantissa and mm in Gerber, there is no > rounding issue. or perhaps it just crops up more rarely? Absent edge path interference auditting, it would seem so I guess I don't see how using any numbering system in the output side does not carry the prospect for potential overlap. I _think_ you are saying 'using the same precision' for internal representation rather than transitions 'back and forth' and so having accumulating 'roundoff indeterminancy / error' terms in play helps avoid inadvertently producing: Self intersecting polygons at gerber output time, minimizes this occurring? > > We already have a bug report about self intersecting polygons in Gerber > > files from Kicad. This seems like 'papering over' an issue, rather than detecting closure (and, so, an inadvertent failure to close), and 'intrusion' by adjacent entities (a convex hull / boundry problem) -- Russ herrold ___ 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] Undo stack limit?
Le 05/08/2015 16:29, Wayne Stambaugh a écrit : > Patch committed in product branch r6053. Thanks. > > On 8/4/2015 5:32 PM, Chris Pavlina wrote: >> In any case, here's the patch to make undo configurable. I can edit it >> to change the default if you like. Thanks, Chris. I just tested this feature. It looks good but I noticed a minor and strange issue (only tested on Windows currently): the undo level value seems not (or incorrectly) read from config for the schematic editor only. After closing the schematic editor and re-run it, the undo level selection is always 0 (regardless the previous setting) if it is run from kicad manager However, if Eeschema is run in stand alone mode, after closing Eeschema and re-run it, the undo level selection is good (is is the last saved value) I am thinking this is a read config issue when eeschema is run from kicad manager. (Because if I run eeschema from kicad manager and set the undo stack to 3 and close kicad, if I run eeschema in stand alone, the undo stack is 3 (as expected), but if I run eeschema from kicad manager, the undo stack is 0) No problem for other editors. -- 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] Undo stack limit?
Okay, thanks for letting me know. I'm working on something else at the moment but will investigate shortly. On Wed, Aug 05, 2015 at 06:46:43PM +0200, jp charras wrote: > Le 05/08/2015 16:29, Wayne Stambaugh a écrit : > > Patch committed in product branch r6053. Thanks. > > > > On 8/4/2015 5:32 PM, Chris Pavlina wrote: > >> In any case, here's the patch to make undo configurable. I can edit it > >> to change the default if you like. > > Thanks, Chris. > > I just tested this feature. > It looks good but I noticed a minor and strange issue (only tested on > Windows currently): > > the undo level value seems not (or incorrectly) read from config for the > schematic editor only. > After closing the schematic editor and re-run it, the undo level > selection is always 0 (regardless the previous setting) if it is run > from kicad manager > However, if Eeschema is run in stand alone mode, after closing Eeschema > and re-run it, the undo level selection is good (is is the last saved value) > I am thinking this is a read config issue when eeschema is run from > kicad manager. > (Because if I run eeschema from kicad manager and set the undo stack to > 3 and close kicad, if I run eeschema in stand alone, the undo stack is 3 > (as expected), but if I run eeschema from kicad manager, the undo stack > is 0) > > No problem for other editors. > > > > -- > 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 ___ 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] Gerber output units?
I do not understand why 6 significant digit will cause rounding error if Gerber generation uses inches as unit. you have a nanometer resolution which provides 6 decimals for millimeter units. When you divide this number by 25.4 to convert to inches, you might loose a bit of resolution, but you will not generate a rounding error. 123.456789mm = 4.86050350” wich is now 4.860503 when using only 6 decimals. Where is the rounding error coming from? From the software processing gerber data? I really doubt that CAM software will care about 1 micro-inch error. Just curious, Jean-Paul AC9GH > On Aug 4, 2015, at 3:03 PM, jp charras wrote: > > Le 04/08/2015 08:29, Lorenzo Marcantonio a écrit : >> On Tue, 04 Aug 2015 05:38:26 +0200, >> Chris Pavlina wrote: >>> >>> pcbnew used to be able to plot Gerbers in imperial units. What happened >>> to that? Some (particularly older and non-Asian) board houses still >>> expect those... Is there any reason they were removed, or did they just >>> "fall out"? And can they be put back in? >> >> Since the new plotting infrastructure the gerber plotter already >> supported both units; the IN was simply the compatibility default and it >> only needed an UI option to be bound. >> >> If someone changed the default without adding a radio button or >> something then blame to him:P >> >> AFAIK there would be no technical reason to not do inch plotting... >> > > There is a technical reason to not do inch plotting. > I recently explained it. > > Pcbnew internally uses nanometers, corresponding to 6 digits mantissa in > Gerber. > > If we use a 6 digits mantissa and mm in Gerber, there is no rounding issue. > If we convert these values to inches, I am pretty sure rounding issues > will appear. > > For most of coordinates, a rounding issue has no matter. > However, for complex polygons (copper zones) rounding coordinates can > create self intersecting polygons from non intersecting polygons. > Self intersecting polygons are not allowed in Gerber files (see gerber > file format spec). > > The advice from Ucamco is (especially for this issue) is: > use the max resolution for coordinates (see also the gerber file format > spec). > > > The only one reason the 5 digits mantissa option exists in Pcbnew is the > fact Ucamco told me a few Gerbers tools do not accept the 6 digits. > > I verified some Gerber files which are OK with 6 digits mantissa create > self intersecting polygons when using 5 digits from the same board. > (Tests with GC-Preview) > > (to tell the True, the Gerber image on screen was the same) > > We already have a bug report about self intersecting polygons in Gerber > files from Kicad. > > It also explains why a Gerber reader can gives warnings about that > issue, and an other Gerber reader does not find any issue: it depends > also on internal units of the reader. > > > Therefore, until someone give me a *very good reason* why inches are > better than mm in Gerber files, I *do not want* a inch option in Gerber > plot menu ( or, if this option exists, commit an algo to avoid self > intersecting polygons). > > -- > 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 ___ 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] Gerber output units?
Le 05/08/2015 19:41, Jean-Paul Louis a écrit : > I do not understand why 6 significant digit will cause rounding error if > Gerber generation uses inches as unit. > you have a nanometer resolution which provides 6 decimals for millimeter > units. > When you divide this number by 25.4 to convert to inches, you might loose a > bit of resolution, but you will not generate a rounding error. > 123.456789mm = 4.86050350” wich is now 4.860503 when using only 6 decimals. > > Where is the rounding error coming from? From the software processing gerber > data? I really doubt that CAM software will care about 1 micro-inch error. > > Just curious, > > Jean-Paul > AC9GH > When rounding a coordinate, you slightly move corners of polygons. 1 micro-inch (25 pcbnew internal units) error has no matter for CAM software (and users...) as long it does not create self intersecting polygons. If happens, an error report is made. I am guessing this issue does not create actual problems (at least, when happens, I did not see any issue with Gerber viewers I used). But I already received bug reports about that issue. And what is the reason a Gerber file needs inches ? Currently I do not yet see the answer to my question. I understand a Gerber reader (for instance Gerbview) has to accept a Gerber file both in inches and mm (like all Gerber readers), but why this is needed for Gerber file creation? Moreover, there are many other parameters for Gerber coordinates notation. First versions of Pcbnew have these options in plot dialog. But because very few users are able to correctly choose these options, they are now removed. I never saw a board house which is unable to read Gerbers files in mm. I cannot even imagine it could exist in 2015. But if happens to me, be sure I will use an other board house. -- 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] Segfault when pcbnew starts with an invalid file
Regardless of Dick's future plans wrt Python, I do not see why it would be desirable to call OnPgmExit inside OnRun instead of inside OnExit. It seems clear to me that this is the correct location for it. wx documentation and wx source appear to confirm this, as I indicated earlier. On Wed, Aug 05, 2015 at 10:39:54AM -0400, Wayne Stambaugh wrote: > On 8/5/2015 10:16 AM, Maciej Sumiński wrote: > > Chris has pointed out that it was already discussed [1] and the change > > was not entirely clear. Apparently it had not been wrapped before > > revision 5834, so maybe OnPgmExit() should be still called for both > > Python and non-Python versions of pcbnew? > > This was done because the problem did not occur when wxPython scripting > was disabled and Dick is planning on add wxPython on top of Kicad rather > than a bolted onto the side like our current implementation. > Compiling OnPgmExit() out of non wxPython builds was at his request. > The original crash had to do with wxPython clean up not being called > properly. I just tried to duplicate this bug on a 32 bit build on > windows by running 'pcbnew foo` with no scripting enabled, and I cannot > get it to crash. Are you testing this on Linux? > > > > > Regards, > > Orson > > > > 1. > > https://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg14014.html > > > > On 08/05/2015 11:22 AM, Maciej Sumiński wrote: > >> Pcbnew without scripting support crashes when run with an invalid file > >> given as a parameter (stack overflow in ~wxSingleInstanceChecker()). > >> > >> There is a fix for that, but wrapped with #ifdef > >> KICAD_SCRIPTING_WXPYTHON .. #endif. I removed the mentioned directives > >> and it seems fine here, but I am not confident enough to commit it > >> immediately. Any thoughts? > >> > >> Regards, > >> Orson > >> > >> > >> > >> ___ > >> 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 ___ 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] Export to Solidworks
Hi Maurice, Cirilo and everyone, Thanks for the advise. I was able to run the demo with FreeCAD script, as was shown in youtube video. What I have now is a complete 3D model of my own board I can view on PCBnew 3D viewer. That looks fine and uses WRL models for each individual component ( Usually downloaded and modified with FreeCAD and later Wings3D for WRL. I've generated an .emn file and run the macro, it gave me an error when it could not find step files for components. So, if I understand correctly, I would need two formats for each component, WRL for kicad 3D viewer and step for the StepUp FreeCAD Macro, correct?. Apparently going from VRML to STEP is not recommended so I should create components in STEP format from FreeCAD. Regarding documentation, I can tell you what my experience has been. I've followed instructions to get a complete 3D model I could view with PCBnew, assuming I was going to be able to export that to Solidworks somehow. For kicad users maybe would be good to know STEP procedure before generating all WRL models, or generating both at the same time. It is the first time in my career that I attempt to generate a 3D model of a PCB and interface with MCAD engineers this way.It is pretty exciting and should save a lot of time in meetings. Thanks! On Wed, Aug 5, 2015 at 5:31 AM easyw wrote: > Hi Saumell, > > When you need to give your 3d artwork to MCAD people you have to use > step as interchange format. > Any other format would not be accepted. > Before the kicad stepup script the only way I know to export the pcb > with models was to export vrml and then convert it to step; but any > model converted from vrml would be very un-optimal and not very useful > for mechanical design (I learned the hard way)... the conversion, using > whatever sw you find, will generate a bunch of triangles. > > as Cirilo suggested, please have a try with kicad-stepup script: > http://bazaar.launchpad.net/~easyw/kicad-stepup/trunk/files > http://sourceforge.net/projects/kicadstepup/ > I'm going to write an howto to be included in kicad doc. > At the moment the README.txt file gives you a small explanation. > @youtube you can see also a small howto video > https://www.youtube.com/watch?v=Ukd47VXYzQU > I've also added the option to move the board and modules to a base > point, and the bounding boxes option (to export all or selected modules > to bbox) > > At the moment the kicad library lacks of STEP modules... > I've suggested to add to the 3D repository at least models generated > from FreeCAD > https://github.com/KiCad/kicad-library/issues/186 > FreeCAD could be used as second source to model 3D object to kicad, side > by side with wings3d. > Moreover FreeCAD can create parametric model, with real dimensions as > per the physical objects. > > Anyway, if you need just a rapid solution, you can get 3d models at > http://3dcontentcentral.com/ > the only requirement for the script to work is to have the single models > as a single fused object > you can find some tips to align and use the modules here: > > https://forum.kicad.info/t/kicad-stepup-new-exporter-for-3d-mcad-feedbacks-are-welcome/1048 > > To test the script in real world, I used hackrf-one board and I > generated all 3d vrml modules to be used in kicad, directly from step > modules downloaded from the manufacturers or from 3dcontent central > library. > All the modules converted from FreeCAD to wrl has been used in kicad > 3d-viewer without any issue. > The STEP generated model has been tested in Solid Works and it is fine > without any geometry problem. > > Could you please give me a feed back of your test, so to improve the > script usability for kicad users? > > thank you > Maurice > > On 05/08/2015 00.17, Cirilo Bernardo wrote: > > There are a number of options: > > > > 1. Recently Maurice wrote a script which uses FreeCAD to create a > > STEP modelusing the bare board IDF file and other data in the > > .kicad_pcb file: > > > > http://bazaar.launchpad.net/~easyw/kicad-stepup/trunk/files > > > > No doubt there are still some issues but this is currently the best > > method for exporting a detailed mechanical model. > > > > 2. IDF: If you do nothing and simply opt to export the board then > > you only get a bare board - this step is necessary anyway if you > > use Maurice's script to create a STEP model. If you wish for a more > > detailed IDF model you will need to spend some time creating the > > associated component outline files. The official IDF documentation > > is here: > > > > https://github.com/ciampix/kicad-doc/tree/master/src/IDF_Exporter > > > > but if you can't generate the documentation and want a PDF version > > the original (more inaccurate) version is here: > > > > https://drive.google.com/open?id=0By_XTJN-s8aXbkM5UTE0Zm5SN28 > > > > Now for Solidworks to process an IDF file you need CircuitWorks which > > is only provided with "Solidworks Premium" - bummer. Fortunately you > > can now convert IDF to IGES (which an
Re: [Kicad-developers] official web page
Hi Maurice, I'm not that Marco and I'm not involved in documentation, but this week I tested your script and its really nice. It is key to have a repository of wrl+step models, it was a bit painful to get the step models for an old project but once the setup is ready the workflow is good. I'd suggest to include in the tutorial the creation of a simple part in freecad, it took me a while to realize that it doesn't handle well multiple part objects, and I still can't fuse parts while preserving the colors. I made a DCDC converter step model, a buzzer and downloaded a SO16 step. I'm not sure where to get open source models so we can add them to your repo. Freecad has some models, for example /free-cad-code/src/Mod/Idf/lib/0805_SMD.stp they could be bettery though. Thanks a lot for this work. Marcos On Wed, Aug 5, 2015 at 9:27 AM, Wayne Stambaugh wrote: > Maurice, > > I think Marco is currently on vacation. The new documentation format is > asciidoc. You can use git to clone the current documentation at > https://github.com/ciampix/kicad-doc. Information on how to use > asciidoc can be found at http://www.methods.co.nz/asciidoc/ > > Wayne > > On 8/5/2015 8:23 AM, easyw wrote: > > @Marco > > > > what could I do to prepare a small tutorial for the kicad stepup script? > > do you accept libre-office file or pdf file? > > I'm sorry but I'm new to the doc side :) > > > > thank you > > Maurice > > > > On 17/07/2015 15.12, Wayne Stambaugh wrote: > >> On 7/17/2015 3:36 AM, Mário Luzeiro wrote: > >>> Excellent! > >>> > >>> Do you (all) think should be nice to have a small step tutorial / > >>> explanation how can someone reproduce identical results for another > >>> boards? > >> > >> Yes. Any help we can provide our users is a good thing. Something like > >> this should be added to the user documentation either as part of the > >> Pcbnew manual or as a stand alone tutorial. I don't have a preference > >> one way or another so I'll leave that decision to our documentation > >> experts. > >> > >>> > >>> Mario Luzeiro > >>> > >>> From: Kicad-developers > >>> [kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on > >>> behalf of easyw [ea...@katamail.com] > >>> Sent: 17 July 2015 02:43 > >>> To: Marcos Chaparro; KiCad Developers > >>> Subject: Re: [Kicad-developers] official web page > >>> > >>> Hi Marcos and all, > >>> > >>> it took me a bit but here is the hackrf-one generated with STEP models > >>> by kicad stepup script and the hackrf-one in kicad 3d-viewer with all > >>> the 3d-models generated from the conversion of the STEP models. > >>> I also checked the geometries of the generated board with models and > >>> there are no problems ... > >>> > >>> The rendering result shows that the two scenarios are exactly the same, > >>> and I didn't get any problem in rendering all the vrml models in kicad. > >>> > >>> generating the 3D modes in FreeCAD will produce a vrml 3D models with > no > >>> shading issues and with mechanical respect of all the dimensions > >>> > >>> It would be nice if some of these screenshots could be in the official > >>> web page... > >>> > >>> please let me know what you think > >>> > > > > ___ > > 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] Undo stack limit?
Fixed, patch attached.
On Wed, Aug 05, 2015 at 06:46:43PM +0200, jp charras wrote:
> Le 05/08/2015 16:29, Wayne Stambaugh a écrit :
> > Patch committed in product branch r6053. Thanks.
> >
> > On 8/4/2015 5:32 PM, Chris Pavlina wrote:
> >> In any case, here's the patch to make undo configurable. I can edit it
> >> to change the default if you like.
>
> Thanks, Chris.
>
> I just tested this feature.
> It looks good but I noticed a minor and strange issue (only tested on
> Windows currently):
>
> the undo level value seems not (or incorrectly) read from config for the
> schematic editor only.
> After closing the schematic editor and re-run it, the undo level
> selection is always 0 (regardless the previous setting) if it is run
> from kicad manager
> However, if Eeschema is run in stand alone mode, after closing Eeschema
> and re-run it, the undo level selection is good (is is the last saved value)
> I am thinking this is a read config issue when eeschema is run from
> kicad manager.
> (Because if I run eeschema from kicad manager and set the undo stack to
> 3 and close kicad, if I run eeschema in stand alone, the undo stack is 3
> (as expected), but if I run eeschema from kicad manager, the undo stack
> is 0)
>
> No problem for other editors.
>
>
>
> --
> 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
commit d66ccb3a3e6846368696460e38991d716c70ce30
Author: Chris Pavlina
Date: Wed Aug 5 16:07:23 2015 -0400
Fix loading of undo settings
diff --git a/common/draw_frame.cpp b/common/draw_frame.cpp
index fcffdc9..1b5d3ad 100644
--- a/common/draw_frame.cpp
+++ b/common/draw_frame.cpp
@@ -676,8 +676,8 @@ void EDA_DRAW_FRAME::LoadSettings( wxConfigBase* aCfg )
if( m_LastGridSizeId < 0 )
m_LastGridSizeId = 0;
-GetScreen()->SetMaxUndoItems( aCfg->Read( baseCfgName + MaxUndoItemsEntry,
-long( DEFAULT_MAX_UNDO_ITEMS ) ) );
+m_UndoRedoCountMax = aCfg->Read( baseCfgName + MaxUndoItemsEntry,
+long( DEFAULT_MAX_UNDO_ITEMS ) );
}
diff --git a/eeschema/files-io.cpp b/eeschema/files-io.cpp
index b4135fd..c898c38 100644
--- a/eeschema/files-io.cpp
+++ b/eeschema/files-io.cpp
@@ -430,7 +430,9 @@ bool SCH_EDIT_FRAME::AppendOneEEProject()
sheet->SetName( tmp );
sheet->SetFileName( wxString::Format( wxT( "file%8.8lX.sch" ), (long) newtimestamp ) );
-sheet->SetScreen( new SCH_SCREEN( &Kiway() ) );
+SCH_SCREEN* screen = new SCH_SCREEN( &Kiway() );
+screen->SetMaxUndoItems( m_UndoRedoCountMax );
+sheet->SetScreen( screen );
sheet->GetScreen()->SetFileName( sheet->GetFileName() );
}
// clear annotation and init new time stamp for the new components
diff --git a/eeschema/libeditframe.cpp b/eeschema/libeditframe.cpp
index b428b30..0eb1d36 100644
--- a/eeschema/libeditframe.cpp
+++ b/eeschema/libeditframe.cpp
@@ -206,13 +206,14 @@ LIB_EDIT_FRAME::LIB_EDIT_FRAME( KIWAY* aKiway, wxWindow* aParent ) :
icon.CopyFromBitmap( KiBitmap( libedit_icon_xpm ) );
SetIcon( icon );
+LoadSettings( config() );
+
SetScreen( new SCH_SCREEN( aKiway ) );
GetScreen()->m_Center = true;
+GetScreen()->SetMaxUndoItems( m_UndoRedoCountMax );
SetCrossHairPosition( wxPoint( 0, 0 ) );
-LoadSettings( config() );
-
// Ensure m_LastGridSizeId is an offset inside the allowed schematic range
if( m_LastGridSizeId < ID_POPUP_GRID_LEVEL_50 - ID_POPUP_GRID_LEVEL_1000 )
m_LastGridSizeId = ID_POPUP_GRID_LEVEL_50 - ID_POPUP_GRID_LEVEL_1000;
diff --git a/eeschema/load_one_schematic_file.cpp b/eeschema/load_one_schematic_file.cpp
index 4afc8fd..5d4e345 100644
--- a/eeschema/load_one_schematic_file.cpp
+++ b/eeschema/load_one_schematic_file.cpp
@@ -66,6 +66,9 @@ bool SCH_EDIT_FRAME::LoadOneEEFile( SCH_SCREEN* aScreen, const wxString& aFullFi
if( aFullFileName.IsEmpty() )
return false;
+// Place the undo limit into the screen
+aScreen->SetMaxUndoItems( m_UndoRedoCountMax );
+
// If path is relative, this expands it from the project directory.
wxString fname = Prj().AbsolutePath( aFullFileName );
diff --git a/eeschema/sch_sheet.cpp b/eeschema/sch_sheet.cpp
index c9afde7..ddce303 100644
--- a/eeschema/sch_sheet.cpp
+++ b/eeschema/sch_sheet.cpp
@@ -755,9 +755,9 @@ bool SCH_SHEET::Load( SCH_EDIT_FRAME* aFrame )
{
bool success = true;
+SCH_SCREEN* screen = NULL;
if( !m_screen )
{
-SCH_SCREEN* screen = NULL;
g_RootSheet->SearchHierarchy( m_fileName, &screen );
if( screen )
diff --git a/eeschema/schframe.cpp b/eeschema/schframe.cpp
index 15ee725..d0aa2f4 100644
--- a/eeschema/schframe.cp
Re: [Kicad-developers] Eeschema config keyboard mnemonics
I really like the wording changes in the dialogs. They are much more consistent and understandable in my opinion. I am definitely +1 on this. However, I think this needs a bit more work as the mnemonics aren't working on my system. (I have alerted Chris to this on IRC, just want to make sure this doesn't get committed accidentally). Other than the marked letters/mnemonics not working correctly everything else seems to be correct. Jon Neal On Wed, Aug 5, 2015 at 3:05 PM, Chris Pavlina wrote: > Here's a patch to fix the option dialog mnemonics. > > - Fix conflicting mnemonics in eeschema options > - Add mnemonics to pcbnew, modedit, libedit options > > While I was doing it, I also cleaned up the padding/spacing in the > dialogs (there were a few misaligned labels), and I removed an obsolete > dialog DIALOG_LIBEDIT_DIMENSIONS (this appears to have been merged into > DIALOG_LIBEDIT_OPTIONS a while ago and there is no remaining codepath > that calls it). > > -- > Chris > > On Tue, Aug 04, 2015 at 02:28:47PM -0400, Wayne Stambaugh wrote: > > On 8/3/2015 1:02 PM, Chris Pavlina wrote: > > > Hi, > > > > > > The keyboard mnemonics (underlined letters) in the eeschema and libedit > > > config boxes are a bit messy. There is at least one conflict (two items > > > sharing L), and many items missing mnemonics. > > > > > > I could easily patch this, but I'd rather discuss: perhaps they should > > > be removed? It is not usual to have mnemonics in large, complicated > > > dialogs like this - they're not particularly useful there, and they are > > > error-prone as the current state demonstrates. People forget to add > > > them, or miss conflicts. Mnemonics are much more useful in dialogs that > > > are used frequently like text edit dialogs, where a user might want, > for > > > example, to jump quickly to the "text size" field. With so many > options, > > > nobody is going to remember the mnemonics anyway (note what "mnemonic" > > > means: it's a memory aid!), and it doesn't save any time when one has > to > > > squint at all the options to find the underlined letter. > > > > > > Of course the possibility for inconsistency goes even farther: I > haven't > > > even checked the localizations to see how they behave. > > > > > > Anybody else in favor of just removing them from these two dialogs? The > > > pcbnew and modedit dialogs already do not use them, and most other GUI > > > applications that I checked now also do not use them in their > > > Preferences boxes. > > > > > > > > > -- > > > Chris > > > > > > > While your logic make sense, my preference is to keep the mnemonics, fix > > any duplicates, and add the missing ones in any offending dialogs. I > > realize on some complex dialogs, it can be difficult to set unique > > mnemonics but that's pretty rare. There are still a lot of us old > > timers around who prefer our keyboards over reaching for the mouse > > whenever possible. I know it's passe and quaint but I'm not ready to > > give it up just yet :) > > > > ___ > > 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] Eeschema config keyboard mnemonics
Indeed, something strange is going on with the mnemonics. It's not responding to the correct ones in the correct places in this dialog. Don't commit this. I'll have a closer look tonight. On Wed, Aug 05, 2015 at 05:39:34PM -0400, Jon Neal wrote: > I really like the wording changes in the dialogs. They are much more > consistent and understandable in my opinion. I am definitely +1 on this. > > However, I think this needs a bit more work as the mnemonics aren't working > on my system. (I have alerted Chris to this on IRC, just want to make sure > this doesn't get committed accidentally). > > Other than the marked letters/mnemonics not working correctly everything > else seems to be correct. > > Jon Neal > > > > On Wed, Aug 5, 2015 at 3:05 PM, Chris Pavlina > wrote: > > > Here's a patch to fix the option dialog mnemonics. > > > > - Fix conflicting mnemonics in eeschema options > > - Add mnemonics to pcbnew, modedit, libedit options > > > > While I was doing it, I also cleaned up the padding/spacing in the > > dialogs (there were a few misaligned labels), and I removed an obsolete > > dialog DIALOG_LIBEDIT_DIMENSIONS (this appears to have been merged into > > DIALOG_LIBEDIT_OPTIONS a while ago and there is no remaining codepath > > that calls it). > > > > -- > > Chris > > > > On Tue, Aug 04, 2015 at 02:28:47PM -0400, Wayne Stambaugh wrote: > > > On 8/3/2015 1:02 PM, Chris Pavlina wrote: > > > > Hi, > > > > > > > > The keyboard mnemonics (underlined letters) in the eeschema and libedit > > > > config boxes are a bit messy. There is at least one conflict (two items > > > > sharing L), and many items missing mnemonics. > > > > > > > > I could easily patch this, but I'd rather discuss: perhaps they should > > > > be removed? It is not usual to have mnemonics in large, complicated > > > > dialogs like this - they're not particularly useful there, and they are > > > > error-prone as the current state demonstrates. People forget to add > > > > them, or miss conflicts. Mnemonics are much more useful in dialogs that > > > > are used frequently like text edit dialogs, where a user might want, > > for > > > > example, to jump quickly to the "text size" field. With so many > > options, > > > > nobody is going to remember the mnemonics anyway (note what "mnemonic" > > > > means: it's a memory aid!), and it doesn't save any time when one has > > to > > > > squint at all the options to find the underlined letter. > > > > > > > > Of course the possibility for inconsistency goes even farther: I > > haven't > > > > even checked the localizations to see how they behave. > > > > > > > > Anybody else in favor of just removing them from these two dialogs? The > > > > pcbnew and modedit dialogs already do not use them, and most other GUI > > > > applications that I checked now also do not use them in their > > > > Preferences boxes. > > > > > > > > > > > > -- > > > > Chris > > > > > > > > > > While your logic make sense, my preference is to keep the mnemonics, fix > > > any duplicates, and add the missing ones in any offending dialogs. I > > > realize on some complex dialogs, it can be difficult to set unique > > > mnemonics but that's pretty rare. There are still a lot of us old > > > timers around who prefer our keyboards over reaching for the mouse > > > whenever possible. I know it's passe and quaint but I'm not ready to > > > give it up just yet :) > > > > > > ___ > > > 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] Export to Solidworks
Hi Saumell, sorry for lacking in documentation, but the script is just new... I'm going to add it, but just refer to README.txt as a base Kicad 3d rendering is based on VRML engine and exporting VRML 3D artwork of board and models was the way to exchange 3D data with other CADs and the standard modeler is Wings3D, which cannot export the model in STEP. Unfortunately, there is no way (as per my knowledge) to convert VRML models to 3D solid models, without having generated a bunch of triangles. The procedure that I used to give MCAD people something enough usable was: - export board and models from kicad to VRML - scale and convert it to collada (dae) format with Meshlab - open collada in FreeCAD and create shape from mesh - export part to STEP but the result was a solid, but quite big in byte dimensions, with a lot of faces and not really suitable for MCAD environment, but good enough to have the the size of your board and modules in MCAD. When I discovered that the recent version of Kicad and FreeCAD where compatible I developed the script... When I say compatible I mean that kicad can read and display correctly any VRML 3D model exported from FreeCAD So now you will have the two words with the same appearance; one can design in kicad EDA and transfer the artwork to MCAD (FreeCAD) smoothly WYSIWYG :) to have the script ready to go you need to have a library with STEP models and VRML models located at the usual kicad path. You can find a lot of STEP models at 3dcontentcentral or RScomponents site... the license, it seems to me, allows the user to download these models for MCAD purposes, but they stated that you cannot make an online repo. Many of these models also are multipart and they cannot always correctly fused by freecad So these models are not suitable to be used in kicad repos. for that reason I would like to have a kicad repo with freecad models... FreeCAD can create parametric MCAD models to be fully aligned to the component datasheet, and can be fully scripted to generate components and it is open source :) Please let me know if you model some components in FreeCAD and if you like to share these with kicad's people... here there is an example of model done in FreeCAD at the official repo https://github.com/KiCad/kicad-library/blob/master/modules/packages3d/Displays_7-Segment.3dshapes/Cx56-12.fcstd exported to vrml https://github.com/KiCad/kicad-library/blob/master/modules/packages3d/Displays_7-Segment.3dshapes/Cx56-12.wrl and ready to go for the script https://github.com/easyw/kicad-3d-models-in-freecad/raw/master/misc/Cx56-12.step thank you Maurice On 05/08/2015 21.29, Jose A. Saumell wrote: Hi Maurice, Cirilo and everyone, Thanks for the advise. I was able to run the demo with FreeCAD script, as was shown in youtube video. What I have now is a complete 3D model of my own board I can view on PCBnew 3D viewer. That looks fine and uses WRL models for each individual component ( Usually downloaded and modified with FreeCAD and later Wings3D for WRL. I've generated an .emn file and run the macro, it gave me an error when it could not find step files for components. So, if I understand correctly, I would need two formats for each component, WRL for kicad 3D viewer and step for the StepUp FreeCAD Macro, correct?. Apparently going from VRML to STEP is not recommended so I should create components in STEP format from FreeCAD. Regarding documentation, I can tell you what my experience has been. I've followed instructions to get a complete 3D model I could view with PCBnew, assuming I was going to be able to export that to Solidworks somehow. For kicad users maybe would be good to know STEP procedure before generating all WRL models, or generating both at the same time. It is the first time in my career that I attempt to generate a 3D model of a PCB and interface with MCAD engineers this way.It is pretty exciting and should save a lot of time in meetings. Thanks! On Wed, Aug 5, 2015 at 5:31 AM easyw wrote: Hi Saumell, When you need to give your 3d artwork to MCAD people you have to use step as interchange format. Any other format would not be accepted. Before the kicad stepup script the only way I know to export the pcb with models was to export vrml and then convert it to step; but any model converted from vrml would be very un-optimal and not very useful for mechanical design (I learned the hard way)... the conversion, using whatever sw you find, will generate a bunch of triangles. as Cirilo suggested, please have a try with kicad-stepup script: http://bazaar.launchpad.net/~easyw/kicad-stepup/trunk/files http://sourceforge.net/projects/kicadstepup/ I'm going to write an howto to be included in kicad doc. At the moment the README.txt file gives you a small explanation. @youtube you can see also a small howto video https://www.youtube.com/watch?v=Ukd47VXYzQU I've also added the option to move the board and modules to a base point, and the boundi
Re: [Kicad-developers] Eeschema config keyboard mnemonics
I'll hold off committing this until I see your update. On 8/5/2015 5:41 PM, Chris Pavlina wrote: > Indeed, something strange is going on with the mnemonics. It's not > responding to the correct ones in the correct places in this dialog. > Don't commit this. I'll have a closer look tonight. > > On Wed, Aug 05, 2015 at 05:39:34PM -0400, Jon Neal wrote: >> I really like the wording changes in the dialogs. They are much more >> consistent and understandable in my opinion. I am definitely +1 on this. >> >> However, I think this needs a bit more work as the mnemonics aren't working >> on my system. (I have alerted Chris to this on IRC, just want to make sure >> this doesn't get committed accidentally). >> >> Other than the marked letters/mnemonics not working correctly everything >> else seems to be correct. >> >> Jon Neal >> >> >> >> On Wed, Aug 5, 2015 at 3:05 PM, Chris Pavlina >> wrote: >> >>> Here's a patch to fix the option dialog mnemonics. >>> >>> - Fix conflicting mnemonics in eeschema options >>> - Add mnemonics to pcbnew, modedit, libedit options >>> >>> While I was doing it, I also cleaned up the padding/spacing in the >>> dialogs (there were a few misaligned labels), and I removed an obsolete >>> dialog DIALOG_LIBEDIT_DIMENSIONS (this appears to have been merged into >>> DIALOG_LIBEDIT_OPTIONS a while ago and there is no remaining codepath >>> that calls it). >>> >>> -- >>> Chris >>> >>> On Tue, Aug 04, 2015 at 02:28:47PM -0400, Wayne Stambaugh wrote: On 8/3/2015 1:02 PM, Chris Pavlina wrote: > Hi, > > The keyboard mnemonics (underlined letters) in the eeschema and libedit > config boxes are a bit messy. There is at least one conflict (two items > sharing L), and many items missing mnemonics. > > I could easily patch this, but I'd rather discuss: perhaps they should > be removed? It is not usual to have mnemonics in large, complicated > dialogs like this - they're not particularly useful there, and they are > error-prone as the current state demonstrates. People forget to add > them, or miss conflicts. Mnemonics are much more useful in dialogs that > are used frequently like text edit dialogs, where a user might want, >>> for > example, to jump quickly to the "text size" field. With so many >>> options, > nobody is going to remember the mnemonics anyway (note what "mnemonic" > means: it's a memory aid!), and it doesn't save any time when one has >>> to > squint at all the options to find the underlined letter. > > Of course the possibility for inconsistency goes even farther: I >>> haven't > even checked the localizations to see how they behave. > > Anybody else in favor of just removing them from these two dialogs? The > pcbnew and modedit dialogs already do not use them, and most other GUI > applications that I checked now also do not use them in their > Preferences boxes. > > > -- > Chris > While your logic make sense, my preference is to keep the mnemonics, fix any duplicates, and add the missing ones in any offending dialogs. I realize on some complex dialogs, it can be difficult to set unique mnemonics but that's pretty rare. There are still a lot of us old timers around who prefer our keyboards over reaching for the mouse whenever possible. I know it's passe and quaint but I'm not ready to give it up just yet :) ___ 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 > ___ 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] Eeschema config keyboard mnemonics
Actually it is not a problem with my patch. It may be a wx bug or a kicad bug - this needs further investigation. Maybe someone is listening who knows wx better? The mnemonics are broken even without my patch. Many items do not respond. After trying to get them working, I have a pile of these in my terminal: (eeschema:32117): Gtk-WARNING **: widget `wxPizza' isn't suitable for mnemonic activation What the everliving /hell/ is a wxPizza. I can find very little documentation on it, other than someone else also complaining that it is interfering with his events (with no follow-up). Anybody? On Wed, Aug 05, 2015 at 06:02:02PM -0400, Wayne Stambaugh wrote: > I'll hold off committing this until I see your update. > > On 8/5/2015 5:41 PM, Chris Pavlina wrote: > > Indeed, something strange is going on with the mnemonics. It's not > > responding to the correct ones in the correct places in this dialog. > > Don't commit this. I'll have a closer look tonight. > > > > On Wed, Aug 05, 2015 at 05:39:34PM -0400, Jon Neal wrote: > >> I really like the wording changes in the dialogs. They are much more > >> consistent and understandable in my opinion. I am definitely +1 on this. > >> > >> However, I think this needs a bit more work as the mnemonics aren't working > >> on my system. (I have alerted Chris to this on IRC, just want to make sure > >> this doesn't get committed accidentally). > >> > >> Other than the marked letters/mnemonics not working correctly everything > >> else seems to be correct. > >> > >> Jon Neal > >> > >> > >> > >> On Wed, Aug 5, 2015 at 3:05 PM, Chris Pavlina > >> wrote: > >> > >>> Here's a patch to fix the option dialog mnemonics. > >>> > >>> - Fix conflicting mnemonics in eeschema options > >>> - Add mnemonics to pcbnew, modedit, libedit options > >>> > >>> While I was doing it, I also cleaned up the padding/spacing in the > >>> dialogs (there were a few misaligned labels), and I removed an obsolete > >>> dialog DIALOG_LIBEDIT_DIMENSIONS (this appears to have been merged into > >>> DIALOG_LIBEDIT_OPTIONS a while ago and there is no remaining codepath > >>> that calls it). > >>> > >>> -- > >>> Chris > >>> > >>> On Tue, Aug 04, 2015 at 02:28:47PM -0400, Wayne Stambaugh wrote: > On 8/3/2015 1:02 PM, Chris Pavlina wrote: > > Hi, > > > > The keyboard mnemonics (underlined letters) in the eeschema and libedit > > config boxes are a bit messy. There is at least one conflict (two items > > sharing L), and many items missing mnemonics. > > > > I could easily patch this, but I'd rather discuss: perhaps they should > > be removed? It is not usual to have mnemonics in large, complicated > > dialogs like this - they're not particularly useful there, and they are > > error-prone as the current state demonstrates. People forget to add > > them, or miss conflicts. Mnemonics are much more useful in dialogs that > > are used frequently like text edit dialogs, where a user might want, > >>> for > > example, to jump quickly to the "text size" field. With so many > >>> options, > > nobody is going to remember the mnemonics anyway (note what "mnemonic" > > means: it's a memory aid!), and it doesn't save any time when one has > >>> to > > squint at all the options to find the underlined letter. > > > > Of course the possibility for inconsistency goes even farther: I > >>> haven't > > even checked the localizations to see how they behave. > > > > Anybody else in favor of just removing them from these two dialogs? The > > pcbnew and modedit dialogs already do not use them, and most other GUI > > applications that I checked now also do not use them in their > > Preferences boxes. > > > > > > -- > > Chris > > > > While your logic make sense, my preference is to keep the mnemonics, fix > any duplicates, and add the missing ones in any offending dialogs. I > realize on some complex dialogs, it can be difficult to set unique > mnemonics but that's pretty rare. There are still a lot of us old > timers around who prefer our keyboards over reaching for the mouse > whenever possible. I know it's passe and quaint but I'm not ready to > give it up just yet :) > > ___ > 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-
Re: [Kicad-developers] Gerber output units?
I think a big problem which is not in our control was already mentioned by Jean-Pierre: some Gerber readers do not accept the longer decimal strings. So even if you could detect and fix intersecting polygons in inch units you also have to ensure that defective readers don't choke. UCAMCO have declared that no one is obliged to support such defective products and in fact discourages such support in order to promote more uniform behavior of software, but the reality is that there will be defective software out there for a very long time. Since there seems to be no problem with mm output I'd say it's a non-issue. If anyone has Gerber software which will not display a mm file on an imperial grid I would question the suitability of that software. - Cirilo On Thu, Aug 6, 2015 at 1:00 AM, Chris Pavlina wrote: > Agreed 90%. I don't have so much of a problem with "fixing" the > dimensions as long as they're only fixed in the Gerber export, not in > the master - it's just part of exporting, you're rendering things with > the features available to you in the destination format. But that's a > minor point, obviously I don't want to turn the alternative units back > on if they don't work. I wasn't aware of this problem. > > On Wed, Aug 05, 2015 at 10:56:02AM -0400, Wayne Stambaugh wrote: > > > > > > On 8/4/2015 3:03 PM, jp charras wrote: > > > Le 04/08/2015 08:29, Lorenzo Marcantonio a écrit : > > >> On Tue, 04 Aug 2015 05:38:26 +0200, > > >> Chris Pavlina wrote: > > >>> > > >>> pcbnew used to be able to plot Gerbers in imperial units. What > happened > > >>> to that? Some (particularly older and non-Asian) board houses still > > >>> expect those... Is there any reason they were removed, or did they > just > > >>> "fall out"? And can they be put back in? > > >> > > >> Since the new plotting infrastructure the gerber plotter already > > >> supported both units; the IN was simply the compatibility default and > it > > >> only needed an UI option to be bound. > > >> > > >> If someone changed the default without adding a radio button or > > >> something then blame to him:P > > >> > > >> AFAIK there would be no technical reason to not do inch plotting... > > >> > > > > > > There is a technical reason to not do inch plotting. > > > I recently explained it. > > > > > > Pcbnew internally uses nanometers, corresponding to 6 digits mantissa > in > > > Gerber. > > > > > > If we use a 6 digits mantissa and mm in Gerber, there is no rounding > issue. > > > If we convert these values to inches, I am pretty sure rounding issues > > > will appear. > > > > > > For most of coordinates, a rounding issue has no matter. > > > However, for complex polygons (copper zones) rounding coordinates can > > > create self intersecting polygons from non intersecting polygons. > > > Self intersecting polygons are not allowed in Gerber files (see gerber > > > file format spec). > > > > > > The advice from Ucamco is (especially for this issue) is: > > > use the max resolution for coordinates (see also the gerber file format > > > spec). > > > > > > > > > The only one reason the 5 digits mantissa option exists in Pcbnew is > the > > > fact Ucamco told me a few Gerbers tools do not accept the 6 digits. > > > > > > I verified some Gerber files which are OK with 6 digits mantissa create > > > self intersecting polygons when using 5 digits from the same board. > > > (Tests with GC-Preview) > > > > > > (to tell the True, the Gerber image on screen was the same) > > > > > > We already have a bug report about self intersecting polygons in Gerber > > > files from Kicad. > > > > > > It also explains why a Gerber reader can gives warnings about that > > > issue, and an other Gerber reader does not find any issue: it depends > > > also on internal units of the reader. > > > > > > > > > Therefore, until someone give me a *very good reason* why inches are > > > better than mm in Gerber files, I *do not want* a inch option in Gerber > > > plot menu ( or, if this option exists, commit an algo to avoid self > > > intersecting polygons). > > > > > > > I'm going to side with JP on this one. Simply enabling the conversion > > from the internal nanometer units to inches for gerber plotting is not > > an acceptable solution no matter how harmless it may seem on the > > surface. The combination of loss of precision and the floating point > > rounding errors can potentially lead to self intersecting polygons as JP > > has mentioned. Whether or not these errors are significant is design > > dependent. It's most likely that they would not result in an issue for > > most designs but I would rather error on the side of caution on this > issue. > > > > Any solution to this problem must include an algorithm to detect and > > potentially correct the problem. The issue I see with this is the > > correction algorithm. Programmatically fixing the self intersecting > > polygons when they occur may or may not be what the user intended. The > > question then becomes what to do a
Re: [Kicad-developers] Eeschema config keyboard mnemonics
On 6 August 2015 at 10:09, Chris Pavlina wrote: > > What the everliving /hell/ is a wxPizza. I can find very little > documentation on it, other than someone else also complaining that it is > interfering with his events (with no follow-up). Never heard of it before, but it seems to be a generic base class for wxGTK: "GtkPizza is the name of a custom GTK widget that wxWidgets has implemented to help with things like wx.Panel, generic controls, etc." [1] Maybe the warning message is reporting with the name of the base class rather than the derived class? Can't be of more help I'm afraid. Blair [1] http://wxpython-users.wxwidgets.narkive.com/IbiAscA7/gtkpizza-i-didn-t-order-any-pizza ___ 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] official web page
Hi Maurice, I suggest you open up a pull request to include your script in https://github.com/KiCad/kicad-library-utils. Regards, Carl On Wed, Aug 5, 2015 at 3:40 PM, Marcos Chaparro wrote: > Hi Maurice, > I'm not that Marco and I'm not involved in documentation, but this week I > tested your script and its really nice. It is key to have a repository of > wrl+step models, it was a bit painful to get the step models for an old > project but once the setup is ready the workflow is good. > > I'd suggest to include in the tutorial the creation of a simple part in > freecad, it took me a while to realize that it doesn't handle well multiple > part objects, and I still can't fuse parts while preserving the colors. > > I made a DCDC converter step model, a buzzer and downloaded a SO16 step. > I'm not sure where to get open source models so we can add them to your > repo. Freecad has some models, for example > /free-cad-code/src/Mod/Idf/lib/0805_SMD.stp they could be bettery though. > > Thanks a lot for this work. > > > > > Marcos > > On Wed, Aug 5, 2015 at 9:27 AM, Wayne Stambaugh > wrote: > >> Maurice, >> >> I think Marco is currently on vacation. The new documentation format is >> asciidoc. You can use git to clone the current documentation at >> https://github.com/ciampix/kicad-doc. Information on how to use >> asciidoc can be found at http://www.methods.co.nz/asciidoc/ >> >> Wayne >> >> On 8/5/2015 8:23 AM, easyw wrote: >> > @Marco >> > >> > what could I do to prepare a small tutorial for the kicad stepup script? >> > do you accept libre-office file or pdf file? >> > I'm sorry but I'm new to the doc side :) >> > >> > thank you >> > Maurice >> > >> > On 17/07/2015 15.12, Wayne Stambaugh wrote: >> >> On 7/17/2015 3:36 AM, Mário Luzeiro wrote: >> >>> Excellent! >> >>> >> >>> Do you (all) think should be nice to have a small step tutorial / >> >>> explanation how can someone reproduce identical results for another >> >>> boards? >> >> >> >> Yes. Any help we can provide our users is a good thing. Something >> like >> >> this should be added to the user documentation either as part of the >> >> Pcbnew manual or as a stand alone tutorial. I don't have a preference >> >> one way or another so I'll leave that decision to our documentation >> >> experts. >> >> >> >>> >> >>> Mario Luzeiro >> >>> >> >>> From: Kicad-developers >> >>> [kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on >> >>> behalf of easyw [ea...@katamail.com] >> >>> Sent: 17 July 2015 02:43 >> >>> To: Marcos Chaparro; KiCad Developers >> >>> Subject: Re: [Kicad-developers] official web page >> >>> >> >>> Hi Marcos and all, >> >>> >> >>> it took me a bit but here is the hackrf-one generated with STEP models >> >>> by kicad stepup script and the hackrf-one in kicad 3d-viewer with all >> >>> the 3d-models generated from the conversion of the STEP models. >> >>> I also checked the geometries of the generated board with models and >> >>> there are no problems ... >> >>> >> >>> The rendering result shows that the two scenarios are exactly the >> same, >> >>> and I didn't get any problem in rendering all the vrml models in >> kicad. >> >>> >> >>> generating the 3D modes in FreeCAD will produce a vrml 3D models with >> no >> >>> shading issues and with mechanical respect of all the dimensions >> >>> >> >>> It would be nice if some of these screenshots could be in the official >> >>> web page... >> >>> >> >>> please let me know what you think >> >>> >> > >> > ___ >> > 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 > > ___ 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] official web page
Hi Marco! thank you for your feedback I had to learn myself too that FreeCAD has a not an easy fuse tool... please have a look at: http://forum.freecadweb.org/viewtopic.php?t=8451#p69489 it explains why sometimes when you fuse objects, the saved model is still multi-part or have geometry problems... DesignSpark Mechanical is a nice tool to open the STEP artwork and check if there are geometry problems (unfortunately only for windows, not for linux or osx) Sometimes you just need to extend a bit a solid into the other... After a bit of learning I managed to fuse all components and board together (only in case of lot of small objects, which are not useful for MCAD exchange, the fusion doesn't work) If you would like to share your models, I will upload them to the repo that I'm trying to build I've ask also to let the official repo to accept FreeCAD models.. that would be enough to improve the conversion job... Please find attached a block reference that I use to import in FreeCAD when modeling the 3D part, to have a reference in alignment (if you import the STEP file, the part will be included in the document you are working with) I'm working also on a FreeCAD macro to easily move and rotate objects, when ready to deploy I will upload it beside the script Which FreeCAD version are you using? I don't have any problem in fusing parts and preserving colors I attached the demo board with all the components fused as one single object, with all the colors preserved (I'm adding to the script also the option to fuse all the boards objects) I added also the option to have bounding boxes for all, or part of the 3d models of the pcb. I attached also a picture of hackrf-one with all bbox except the connectors keep in touch Maurice On 05/08/2015 21.40, Marcos Chaparro wrote: Hi Maurice, I'm not that Marco and I'm not involved in documentation, but this week I tested your script and its really nice. It is key to have a repository of wrl+step models, it was a bit painful to get the step models for an old project but once the setup is ready the workflow is good. I'd suggest to include in the tutorial the creation of a simple part in freecad, it took me a while to realize that it doesn't handle well multiple part objects, and I still can't fuse parts while preserving the colors. I made a DCDC converter step model, a buzzer and downloaded a SO16 step. I'm not sure where to get open source models so we can add them to your repo. Freecad has some models, for example /free-cad-code/src/Mod/Idf/lib/0805_SMD.stp they could be bettery though. Thanks a lot for this work. Marcos On Wed, Aug 5, 2015 at 9:27 AM, Wayne Stambaugh wrote: Maurice, I think Marco is currently on vacation. The new documentation format is asciidoc. You can use git to clone the current documentation at https://github.com/ciampix/kicad-doc. Information on how to use asciidoc can be found at http://www.methods.co.nz/asciidoc/ Wayne On 8/5/2015 8:23 AM, easyw wrote: @Marco what could I do to prepare a small tutorial for the kicad stepup script? do you accept libre-office file or pdf file? I'm sorry but I'm new to the doc side :) thank you Maurice On 17/07/2015 15.12, Wayne Stambaugh wrote: On 7/17/2015 3:36 AM, Mário Luzeiro wrote: Excellent! Do you (all) think should be nice to have a small step tutorial / explanation how can someone reproduce identical results for another boards? Yes. Any help we can provide our users is a good thing. Something like this should be added to the user documentation either as part of the Pcbnew manual or as a stand alone tutorial. I don't have a preference one way or another so I'll leave that decision to our documentation experts. Mario Luzeiro From: Kicad-developers [kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on behalf of easyw [ea...@katamail.com] Sent: 17 July 2015 02:43 To: Marcos Chaparro; KiCad Developers Subject: Re: [Kicad-developers] official web page Hi Marcos and all, it took me a bit but here is the hackrf-one generated with STEP models by kicad stepup script and the hackrf-one in kicad 3d-viewer with all the 3d-models generated from the conversion of the STEP models. I also checked the geometries of the generated board with models and there are no problems ... The rendering result shows that the two scenarios are exactly the same, and I didn't get any problem in rendering all the vrml models in kicad. generating the 3D modes in FreeCAD will produce a vrml 3D models with no shading issues and with mechanical respect of all the dimensions It would be nice if some of these screenshots could be in the official web page... please let me know what you think ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.la
Re: [Kicad-developers] Undo stack limit?
Patch committed in product branch r6055. Thanks. On 8/5/2015 4:09 PM, Chris Pavlina wrote: > Fixed, patch attached. > > On Wed, Aug 05, 2015 at 06:46:43PM +0200, jp charras wrote: >> Le 05/08/2015 16:29, Wayne Stambaugh a écrit : >>> Patch committed in product branch r6053. Thanks. >>> >>> On 8/4/2015 5:32 PM, Chris Pavlina wrote: In any case, here's the patch to make undo configurable. I can edit it to change the default if you like. >> >> Thanks, Chris. >> >> I just tested this feature. >> It looks good but I noticed a minor and strange issue (only tested on >> Windows currently): >> >> the undo level value seems not (or incorrectly) read from config for the >> schematic editor only. >> After closing the schematic editor and re-run it, the undo level >> selection is always 0 (regardless the previous setting) if it is run >> from kicad manager >> However, if Eeschema is run in stand alone mode, after closing Eeschema >> and re-run it, the undo level selection is good (is is the last saved value) >> I am thinking this is a read config issue when eeschema is run from >> kicad manager. >> (Because if I run eeschema from kicad manager and set the undo stack to >> 3 and close kicad, if I run eeschema in stand alone, the undo stack is 3 >> (as expected), but if I run eeschema from kicad manager, the undo stack >> is 0) >> >> No problem for other editors. >> >> >> >> -- >> 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 >> >> >> ___ >> 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] Eeschema config keyboard mnemonics
They seem to work ok on windows so it must be wxGTK that is the issue. On 8/5/2015 6:09 PM, Chris Pavlina wrote: > Actually it is not a problem with my patch. It may be a wx bug or a > kicad bug - this needs further investigation. Maybe someone is listening > who knows wx better? > > The mnemonics are broken even without my patch. Many items do not > respond. After trying to get them working, I have a pile of these in my > terminal: > > (eeschema:32117): Gtk-WARNING **: widget `wxPizza' isn't suitable for > mnemonic activation > > What the everliving /hell/ is a wxPizza. I can find very little > documentation on it, other than someone else also complaining that it is > interfering with his events (with no follow-up). > > Anybody? > > > On Wed, Aug 05, 2015 at 06:02:02PM -0400, Wayne Stambaugh wrote: >> I'll hold off committing this until I see your update. >> >> On 8/5/2015 5:41 PM, Chris Pavlina wrote: >>> Indeed, something strange is going on with the mnemonics. It's not >>> responding to the correct ones in the correct places in this dialog. >>> Don't commit this. I'll have a closer look tonight. >>> >>> On Wed, Aug 05, 2015 at 05:39:34PM -0400, Jon Neal wrote: I really like the wording changes in the dialogs. They are much more consistent and understandable in my opinion. I am definitely +1 on this. However, I think this needs a bit more work as the mnemonics aren't working on my system. (I have alerted Chris to this on IRC, just want to make sure this doesn't get committed accidentally). Other than the marked letters/mnemonics not working correctly everything else seems to be correct. Jon Neal On Wed, Aug 5, 2015 at 3:05 PM, Chris Pavlina wrote: > Here's a patch to fix the option dialog mnemonics. > > - Fix conflicting mnemonics in eeschema options > - Add mnemonics to pcbnew, modedit, libedit options > > While I was doing it, I also cleaned up the padding/spacing in the > dialogs (there were a few misaligned labels), and I removed an obsolete > dialog DIALOG_LIBEDIT_DIMENSIONS (this appears to have been merged into > DIALOG_LIBEDIT_OPTIONS a while ago and there is no remaining codepath > that calls it). > > -- > Chris > > On Tue, Aug 04, 2015 at 02:28:47PM -0400, Wayne Stambaugh wrote: >> On 8/3/2015 1:02 PM, Chris Pavlina wrote: >>> Hi, >>> >>> The keyboard mnemonics (underlined letters) in the eeschema and libedit >>> config boxes are a bit messy. There is at least one conflict (two items >>> sharing L), and many items missing mnemonics. >>> >>> I could easily patch this, but I'd rather discuss: perhaps they should >>> be removed? It is not usual to have mnemonics in large, complicated >>> dialogs like this - they're not particularly useful there, and they are >>> error-prone as the current state demonstrates. People forget to add >>> them, or miss conflicts. Mnemonics are much more useful in dialogs that >>> are used frequently like text edit dialogs, where a user might want, > for >>> example, to jump quickly to the "text size" field. With so many > options, >>> nobody is going to remember the mnemonics anyway (note what "mnemonic" >>> means: it's a memory aid!), and it doesn't save any time when one has > to >>> squint at all the options to find the underlined letter. >>> >>> Of course the possibility for inconsistency goes even farther: I > haven't >>> even checked the localizations to see how they behave. >>> >>> Anybody else in favor of just removing them from these two dialogs? The >>> pcbnew and modedit dialogs already do not use them, and most other GUI >>> applications that I checked now also do not use them in their >>> Preferences boxes. >>> >>> >>> -- >>> Chris >>> >> >> While your logic make sense, my preference is to keep the mnemonics, fix >> any duplicates, and add the missing ones in any offending dialogs. I >> realize on some complex dialogs, it can be difficult to set unique >> mnemonics but that's pretty rare. There are still a lot of us old >> timers around who prefer our keyboards over reaching for the mouse >> whenever possible. I know it's passe and quaint but I'm not ready to >> give it up just yet :) >> >> ___ >> 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 :
Re: [Kicad-developers] Eeschema config keyboard mnemonics
Huh, strange. In that case I suppose you can commit this patch, there's nothing wrong with the patch itself. I'll have to look further into why the mnemonics aren't working properly on wxgtk... They do in most other dialogs, so I imagine even if it is a wx bug, there's likely a workaround. On Wed, Aug 05, 2015 at 08:12:12PM -0400, Wayne Stambaugh wrote: > They seem to work ok on windows so it must be wxGTK that is the issue. > > On 8/5/2015 6:09 PM, Chris Pavlina wrote: > > Actually it is not a problem with my patch. It may be a wx bug or a > > kicad bug - this needs further investigation. Maybe someone is listening > > who knows wx better? > > > > The mnemonics are broken even without my patch. Many items do not > > respond. After trying to get them working, I have a pile of these in my > > terminal: > > > > (eeschema:32117): Gtk-WARNING **: widget `wxPizza' isn't suitable for > > mnemonic activation > > > > What the everliving /hell/ is a wxPizza. I can find very little > > documentation on it, other than someone else also complaining that it is > > interfering with his events (with no follow-up). > > > > Anybody? > > > > > > On Wed, Aug 05, 2015 at 06:02:02PM -0400, Wayne Stambaugh wrote: > >> I'll hold off committing this until I see your update. > >> > >> On 8/5/2015 5:41 PM, Chris Pavlina wrote: > >>> Indeed, something strange is going on with the mnemonics. It's not > >>> responding to the correct ones in the correct places in this dialog. > >>> Don't commit this. I'll have a closer look tonight. > >>> > >>> On Wed, Aug 05, 2015 at 05:39:34PM -0400, Jon Neal wrote: > I really like the wording changes in the dialogs. They are much more > consistent and understandable in my opinion. I am definitely +1 on this. > > However, I think this needs a bit more work as the mnemonics aren't > working > on my system. (I have alerted Chris to this on IRC, just want to make > sure > this doesn't get committed accidentally). > > Other than the marked letters/mnemonics not working correctly everything > else seems to be correct. > > Jon Neal > > > > On Wed, Aug 5, 2015 at 3:05 PM, Chris Pavlina > wrote: > > > Here's a patch to fix the option dialog mnemonics. > > > > - Fix conflicting mnemonics in eeschema options > > - Add mnemonics to pcbnew, modedit, libedit options > > > > While I was doing it, I also cleaned up the padding/spacing in the > > dialogs (there were a few misaligned labels), and I removed an obsolete > > dialog DIALOG_LIBEDIT_DIMENSIONS (this appears to have been merged into > > DIALOG_LIBEDIT_OPTIONS a while ago and there is no remaining codepath > > that calls it). > > > > -- > > Chris > > > > On Tue, Aug 04, 2015 at 02:28:47PM -0400, Wayne Stambaugh wrote: > >> On 8/3/2015 1:02 PM, Chris Pavlina wrote: > >>> Hi, > >>> > >>> The keyboard mnemonics (underlined letters) in the eeschema and > >>> libedit > >>> config boxes are a bit messy. There is at least one conflict (two > >>> items > >>> sharing L), and many items missing mnemonics. > >>> > >>> I could easily patch this, but I'd rather discuss: perhaps they should > >>> be removed? It is not usual to have mnemonics in large, complicated > >>> dialogs like this - they're not particularly useful there, and they > >>> are > >>> error-prone as the current state demonstrates. People forget to add > >>> them, or miss conflicts. Mnemonics are much more useful in dialogs > >>> that > >>> are used frequently like text edit dialogs, where a user might want, > > for > >>> example, to jump quickly to the "text size" field. With so many > > options, > >>> nobody is going to remember the mnemonics anyway (note what "mnemonic" > >>> means: it's a memory aid!), and it doesn't save any time when one has > > to > >>> squint at all the options to find the underlined letter. > >>> > >>> Of course the possibility for inconsistency goes even farther: I > > haven't > >>> even checked the localizations to see how they behave. > >>> > >>> Anybody else in favor of just removing them from these two dialogs? > >>> The > >>> pcbnew and modedit dialogs already do not use them, and most other GUI > >>> applications that I checked now also do not use them in their > >>> Preferences boxes. > >>> > >>> > >>> -- > >>> Chris > >>> > >> > >> While your logic make sense, my preference is to keep the mnemonics, > >> fix > >> any duplicates, and add the missing ones in any offending dialogs. I > >> realize on some complex dialogs, it can be difficult to set unique > >> mnemonics but that's pretty rare. There are still a lot of us old > >> timers around who prefer our keyboards over reaching for the mouse > >> whenev
Re: [Kicad-developers] Eeschema config keyboard mnemonics
Okay, I definitely have no clue what's going on. On my system, out of eleven items in the wxFlexGridSizer that holds the first set of options items, exactly one responds properly to its mnemonic: m_spinAutoSaveInterval. I cannot discern any way in which it is different from the rest. Another responds to the *wrong* mnemonic: m_spinBusWidth responds to the mnemonic for m_choiceUnits, two items above it. WTF! The other nine just barf out the weird message about wxPizza. All of the wxCheckBoxes in the bottom section work perfectly. Any wxwidgets wizards here? I'm at a complete loss. On Wed, Aug 05, 2015 at 08:12:12PM -0400, Wayne Stambaugh wrote: > They seem to work ok on windows so it must be wxGTK that is the issue. > > On 8/5/2015 6:09 PM, Chris Pavlina wrote: > > Actually it is not a problem with my patch. It may be a wx bug or a > > kicad bug - this needs further investigation. Maybe someone is listening > > who knows wx better? > > > > The mnemonics are broken even without my patch. Many items do not > > respond. After trying to get them working, I have a pile of these in my > > terminal: > > > > (eeschema:32117): Gtk-WARNING **: widget `wxPizza' isn't suitable for > > mnemonic activation > > > > What the everliving /hell/ is a wxPizza. I can find very little > > documentation on it, other than someone else also complaining that it is > > interfering with his events (with no follow-up). > > > > Anybody? > > > > > > On Wed, Aug 05, 2015 at 06:02:02PM -0400, Wayne Stambaugh wrote: > >> I'll hold off committing this until I see your update. > >> > >> On 8/5/2015 5:41 PM, Chris Pavlina wrote: > >>> Indeed, something strange is going on with the mnemonics. It's not > >>> responding to the correct ones in the correct places in this dialog. > >>> Don't commit this. I'll have a closer look tonight. > >>> > >>> On Wed, Aug 05, 2015 at 05:39:34PM -0400, Jon Neal wrote: > I really like the wording changes in the dialogs. They are much more > consistent and understandable in my opinion. I am definitely +1 on this. > > However, I think this needs a bit more work as the mnemonics aren't > working > on my system. (I have alerted Chris to this on IRC, just want to make > sure > this doesn't get committed accidentally). > > Other than the marked letters/mnemonics not working correctly everything > else seems to be correct. > > Jon Neal > > > > On Wed, Aug 5, 2015 at 3:05 PM, Chris Pavlina > wrote: > > > Here's a patch to fix the option dialog mnemonics. > > > > - Fix conflicting mnemonics in eeschema options > > - Add mnemonics to pcbnew, modedit, libedit options > > > > While I was doing it, I also cleaned up the padding/spacing in the > > dialogs (there were a few misaligned labels), and I removed an obsolete > > dialog DIALOG_LIBEDIT_DIMENSIONS (this appears to have been merged into > > DIALOG_LIBEDIT_OPTIONS a while ago and there is no remaining codepath > > that calls it). > > > > -- > > Chris > > > > On Tue, Aug 04, 2015 at 02:28:47PM -0400, Wayne Stambaugh wrote: > >> On 8/3/2015 1:02 PM, Chris Pavlina wrote: > >>> Hi, > >>> > >>> The keyboard mnemonics (underlined letters) in the eeschema and > >>> libedit > >>> config boxes are a bit messy. There is at least one conflict (two > >>> items > >>> sharing L), and many items missing mnemonics. > >>> > >>> I could easily patch this, but I'd rather discuss: perhaps they should > >>> be removed? It is not usual to have mnemonics in large, complicated > >>> dialogs like this - they're not particularly useful there, and they > >>> are > >>> error-prone as the current state demonstrates. People forget to add > >>> them, or miss conflicts. Mnemonics are much more useful in dialogs > >>> that > >>> are used frequently like text edit dialogs, where a user might want, > > for > >>> example, to jump quickly to the "text size" field. With so many > > options, > >>> nobody is going to remember the mnemonics anyway (note what "mnemonic" > >>> means: it's a memory aid!), and it doesn't save any time when one has > > to > >>> squint at all the options to find the underlined letter. > >>> > >>> Of course the possibility for inconsistency goes even farther: I > > haven't > >>> even checked the localizations to see how they behave. > >>> > >>> Anybody else in favor of just removing them from these two dialogs? > >>> The > >>> pcbnew and modedit dialogs already do not use them, and most other GUI > >>> applications that I checked now also do not use them in their > >>> Preferences boxes. > >>> > >>> > >>> -- > >>> Chris > >>> > >> > >> While your logic make sense, my preference is to keep the mnemonics, > >> fix > >> any duplicate
Re: [Kicad-developers] Eeschema config keyboard mnemonics
mm ... bad (corrupted) IDs which show on Linux but not MSWin? Is there a difference between debug and release build? Perhaps even a compiler or platform dependent initialization (race condition)? - Cirilo On Thu, Aug 6, 2015 at 11:28 AM, Chris Pavlina wrote: > Okay, I definitely have no clue what's going on. On my system, out of > eleven items in the wxFlexGridSizer that holds the first set of options > items, exactly one responds properly to its mnemonic: > m_spinAutoSaveInterval. I cannot discern any way in which it is > different from the rest. Another responds to the *wrong* mnemonic: > m_spinBusWidth responds to the mnemonic for m_choiceUnits, two items > above it. WTF! The other nine just barf out the weird message about > wxPizza. All of the wxCheckBoxes in the bottom section work perfectly. > > Any wxwidgets wizards here? I'm at a complete loss. > > > On Wed, Aug 05, 2015 at 08:12:12PM -0400, Wayne Stambaugh wrote: > > They seem to work ok on windows so it must be wxGTK that is the issue. > > > > On 8/5/2015 6:09 PM, Chris Pavlina wrote: > > > Actually it is not a problem with my patch. It may be a wx bug or a > > > kicad bug - this needs further investigation. Maybe someone is > listening > > > who knows wx better? > > > > > > The mnemonics are broken even without my patch. Many items do not > > > respond. After trying to get them working, I have a pile of these in my > > > terminal: > > > > > > (eeschema:32117): Gtk-WARNING **: widget `wxPizza' isn't suitable for > mnemonic activation > > > > > > What the everliving /hell/ is a wxPizza. I can find very little > > > documentation on it, other than someone else also complaining that it > is > > > interfering with his events (with no follow-up). > > > > > > Anybody? > > > > > > > > > On Wed, Aug 05, 2015 at 06:02:02PM -0400, Wayne Stambaugh wrote: > > >> I'll hold off committing this until I see your update. > > >> > > >> On 8/5/2015 5:41 PM, Chris Pavlina wrote: > > >>> Indeed, something strange is going on with the mnemonics. It's not > > >>> responding to the correct ones in the correct places in this dialog. > > >>> Don't commit this. I'll have a closer look tonight. > > >>> > > >>> On Wed, Aug 05, 2015 at 05:39:34PM -0400, Jon Neal wrote: > > I really like the wording changes in the dialogs. They are much more > > consistent and understandable in my opinion. I am definitely +1 on > this. > > > > However, I think this needs a bit more work as the mnemonics aren't > working > > on my system. (I have alerted Chris to this on IRC, just want to > make sure > > this doesn't get committed accidentally). > > > > Other than the marked letters/mnemonics not working correctly > everything > > else seems to be correct. > > > > Jon Neal > > > > > > > > On Wed, Aug 5, 2015 at 3:05 PM, Chris Pavlina < > pavlina.ch...@gmail.com> > > wrote: > > > > > Here's a patch to fix the option dialog mnemonics. > > > > > > - Fix conflicting mnemonics in eeschema options > > > - Add mnemonics to pcbnew, modedit, libedit options > > > > > > While I was doing it, I also cleaned up the padding/spacing in the > > > dialogs (there were a few misaligned labels), and I removed an > obsolete > > > dialog DIALOG_LIBEDIT_DIMENSIONS (this appears to have been merged > into > > > DIALOG_LIBEDIT_OPTIONS a while ago and there is no remaining > codepath > > > that calls it). > > > > > > -- > > > Chris > > > > > > On Tue, Aug 04, 2015 at 02:28:47PM -0400, Wayne Stambaugh wrote: > > >> On 8/3/2015 1:02 PM, Chris Pavlina wrote: > > >>> Hi, > > >>> > > >>> The keyboard mnemonics (underlined letters) in the eeschema and > libedit > > >>> config boxes are a bit messy. There is at least one conflict > (two items > > >>> sharing L), and many items missing mnemonics. > > >>> > > >>> I could easily patch this, but I'd rather discuss: perhaps they > should > > >>> be removed? It is not usual to have mnemonics in large, > complicated > > >>> dialogs like this - they're not particularly useful there, and > they are > > >>> error-prone as the current state demonstrates. People forget to > add > > >>> them, or miss conflicts. Mnemonics are much more useful in > dialogs that > > >>> are used frequently like text edit dialogs, where a user might > want, > > > for > > >>> example, to jump quickly to the "text size" field. With so many > > > options, > > >>> nobody is going to remember the mnemonics anyway (note what > "mnemonic" > > >>> means: it's a memory aid!), and it doesn't save any time when > one has > > > to > > >>> squint at all the options to find the underlined letter. > > >>> > > >>> Of course the possibility for inconsistency goes even farther: I > > > haven't > > >>> even checked the localizations to see how they behave. > > >>> > > >>> Anybo
Re: [Kicad-developers] Gerber output units?
On Wed, 05 Aug 2015 16:56:02 +0200, Wayne Stambaugh wrote: > > There is a technical reason to not do inch plotting. > > I recently explained it. Seems a pretty good reason, actually... sorry I don't ready every thread on the list. > > Therefore, until someone give me a *very good reason* why inches are > > better than mm in Gerber files, I *do not want* a inch option in Gerber > > plot menu ( or, if this option exists, commit an algo to avoid self > > intersecting polygons). Silly question: couldn't we raise the decimal figures on MOIN too, to avoid the problem or is it already at the max? Or maybe the rounding creep is of that kind that couldn't by fixed by brute force but only using 'correctly directed' rounding (i.e. point on the left rounded up, point on right rounded down or something like that). Just curious, I don't actually expect that someone could reject a MOMM gerber file... (OTOH I know people which would reject a metric gencad file :( -- Lorenzo Marcantonio Logos Srl ___ 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] Gerber output units?
On Thu, 06 Aug 2015 00:39:47 +0200, Cirilo Bernardo wrote: > If anyone has Gerber software which will not display a mm file on > an imperial grid I would question the suitability of that software. Sadly all the 'niche' industries (i.e. all of that ones without millions of licenses around...) tends to have software that sucks really hard:P To make a name Xilinx is one of these (at least with ISE, I don't know Vivado since I use generation 6 parts). So if you, for example, used prontoplace to handle board manufacturing you would see *all the fscking silk and drawings* flipped over because they misinterpreted the gencad specs (which is quite clear, BTW). They acknowledge the bug but you have to flip them by yourself (or add an option to flip it:P:P) -- Lorenzo Marcantonio Logos Srl ___ 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
