Hi Cirilo, quick comment: a progress bar, progress %, or any kind of feedback while performing the 3D export would come in handy. I spent some time deleting footprints to find the problematic step file because the kicad2step process seemed locked up, but it was only a matter of waiting some minutes. The board had 58 step models, exported file was 4.8MB.
Great work by the way. Marcos On Sat, Sep 24, 2016 at 1:04 PM, Wayne Stambaugh <stambau...@gmail.com> wrote: > On 9/22/2016 10:13 PM, Cirilo Bernardo wrote: > > > > > > On Fri, Sep 23, 2016 at 12:18 AM, Wayne Stambaugh <stambau...@gmail.com > > <mailto:stambau...@gmail.com>> wrote: > > > > On 9/21/2016 9:17 PM, Cirilo Bernardo wrote: > > > On Thu, Sep 22, 2016 at 10:07 AM, Wayne Stambaugh < > stambau...@gmail.com <mailto:stambau...@gmail.com>> wrote: > > >> On 9/21/2016 7:27 PM, Cirilo Bernardo wrote: > > >>> OK, I've updated the branch with the following changes: > > >>> > > >>> 1. removed wxT() from kicad2step and dialogs. The remaining wxT() > > >>> instances are created by wxFormBuilder. > > >>> > > >>> 2. refined the Export STEP GUI for cases in which the exporter > > >>> fails (returns an error or segfaults). > > >> > > >> Thanks for the fixes. I got everything merged on my computer at > work so > > >> I'll just pick up where I left off tomorrow. > > >> > > > > > > No problem; thanks for testing the branch. > > > > I tested this and everything looked fine. I did notice in your last > > commit that you used stderr. I'm not sure that has any meaning on > > windows but it didn't seem to break anything. I committed you kicad > > step export branch to the product repo. Great job. Thanks. > > > > > > The stderr was a diagnostic print that I forgot to rip out. I need to > > make a habit > > of checking for stderr before I commit something. > > No problem, send me a patch when you get a chance. > > > > > > > I do have one comment. The vrml exporter includes the silk screen > and > > traces which results in a much more detailed board model. It would > be > > nice if step export had this as well. > > > > > > From an MCAD point of view the traces etc are not nice since they bloat > the > > model and make the MCAD UI painfully slow. Maybe one day people will > want > > more extensive information for heat flow analysis and such, but at the > > moment > > there's no point in guessing what data people will want. There's a STEP > AP > > (310) for electronic assemblies but I'm not familiar with what it covers > > or if > > anyone actually uses it in production. Otherwise, for eyecandy I'd > recommend > > using the VRML export rather than the STEP export which is intended more > > for professionals who need the model solely for work related to > mechanical > > design. > > I was just curious why you would export that level of detail with vrml > and not step. I understand the higher the level of detail, the harder > the modeling software has to work to render it. I've worked for several > companies who worked with that level of detail and the cad jockeys that > did this kind of work had ridiculously powerful computers. I'm fine > with the way it is because I don't need that level of detail but I can > imagine someone asking for it. > > Cheers, > > Wayne > > > > > - Cirilo > > > > > > > > > >>> > > >>> It also just occurred to me that sometimes the OCE library may > > >>> cause a hang. I can work on a generic dialog to launch an > > >>> external app which connects to the apps stdout + stderr and > > >>> which has a CANCEL button to kill the process - any comments? > > >>> Should I put such a dialog into the "common" library? > > >> > > >> I'm wondering if you could make something abstract enough to work > in all > > >> the places where we run external apps. These dialogs always seem > pretty > > >> task specific like the netlist and bom dialogs? You could try I > guess. > > >> > > > > > > The best abstraction I can think of at the moment is to > instantiate a dialog > > > which simply has a window showing the stderr + stdout of the > running app > > > and a cancel button to kill the process if necessary. All other > customizations > > > should be done in a parent window. I'll come up with something and > apply it > > > to the BOM and netlist generation as well. > > > > Given that we've never had any issues with the bom and netlist > external > > processes, it may not be worth the effort although I'm not opposed to > > the idea. > > > > > > > >>> > > >>> The fact that a process using OCE can hang brings up the > > >>> question of whether it is better to leave kicad2step as a > > >>> separate app or whether it is generally OK as a plugin and > > >>> the odd crash due to bugs in OCE and/or the STEP/IGES > > >>> models would be acceptable. We can stuff the plugin > > >>> invocations into their own thread and check for completion, > > >>> but unlike the case with a separate process, we cannot > > >>> guarantee there is no memory corruption or leakage. > > >>> Any thoughts? > > >> > > >> Ughh! You're not making me feel any better about oce. It would > be nice > > >> to be able to kill a rouge process though. Doesn't the oce > library api > > >> provide some kind of error reporting capability? > > >> > > > > > > OCE does have an error reporting scheme but I've seen it hang > > > indefinitely while performing some operations such as shape healing > > > on defective STEP models. In other instances it eventually stops > > > after it has hogged the maximum memory that the system would > > > give it. In both cases it's not possible to get error information > from > > > within OCE. Unfortunately such bad behavior is not unique to OCE; > the > > > MCAD world in particular seems to be full of buggy libraries, but > to > > > be fair the tasks involved are incredibly difficult and users no > doubt > > > are always coming up with cases that the developers hadn't checked > for. > > > > Are we the only project that pushes these libraries that hard? We do > > seem to find our fair share of library issues. > > > > > > > >>> > > >>> Somewhat off-topic: grep shows me that the source code > > >>> and headers are full of wxT(). Since wxT() had been > > >>> deprecated years ago and KiCad is no longer compatible > > >>> with versions of wxWidgets which required wxT(), perhaps > > >>> we should ask devs to purge wxT() from the headers and > > >>> sources which they touch? I think that might also get devs > > >>> into the habit of not using wxT() - even I still use it without > > >>> realizing it - bad habits die hard. :) > > >> > > >> I caught myself using wxT() while writing the legacy schematic > plugin > > >> several times. It will take time to get used to it but we will > get > > >> there. If you happen to be working on a file, please feel free to > > >> remove them. I don't think we need to do the mass purge just yet. > > >> > > > > > > OK; I might create some patches for the bits I'd worked on in the > > > past like VRML export and IDF export. > > > > For small change sets (<= 5 commits), please send me patch sets using > > format-patch or send-email. It's easier than me having to add > remotes > > and go through the whole pull rebase cycle. > > > > Cheers, > > > > Wayne > > > > > > > > - Cirilo > > > > > >>> > > >>> - Cirilo > > >>> > > >>> On Thu, Sep 22, 2016 at 3:04 AM, Wayne Stambaugh > > <stambau...@gmail.com <mailto:stambau...@gmail.com>> wrote: > > >>>> Cirilo, > > >>>> > > >>>> I just tested this since you fixed the windows extension > > issue. The > > >>>> menu item is enabled but I always get an "Unable to create step > > file > > >>>> whenever there are spaces in the file name and/or path." You > > didn't by > > >>>> chance forget to double quote the command line string did you? > > If you > > >>>> don't, spaces in file and/or path names in command strings will > > fail. > > >>>> > > >>>> Just a couple of quick comments nothing major. wxT() macros > are no > > >>>> longer required in wx3 so try to remember not to use it anymore > > since > > >>>> it's slated to be deprecated in the future. It's also not > > necessary to > > >>>> convert path separators in strings when you are already using > > >>>> wxFileName. You can use wxFileName::GetFullPath() which will > > return the > > >>>> native separators no matter what you feed it with. You can > > also convert > > >>>> to the unix file separator for storage by using > > wxFileName::GetFullPath( > > >>>> wxPATH_UNIX ). This removes the need for #ifdef WINDOWS/#endif > > to do > > >>>> the separator conversion. > > >>>> > > >>>> Cheers, > > >>>> > > >>>> Wayne > > >>>> > > >>>> On 9/19/2016 3:53 AM, Nick Østergaard wrote: > > >>>>> Looks good, I will test it soon. But I noticed that it looks > > like you > > >>>>> did not use the copyright template copyright.h from the root > > of the source. > > >>>>> > > >>>>> > > >>>>> Den 19/09/2016 09.46 skrev "Cirilo Bernardo" > > <cirilo.berna...@gmail.com <mailto:cirilo.berna...@gmail.com> > > >>>>> <mailto:cirilo.berna...@gmail.com > > <mailto:cirilo.berna...@gmail.com>>>: > > >>>>> > > >>>>> The kicad-step feature branch now implements a STEP > > Export. The menu > > >>>>> item may need a new icon (I lazily reused the IDF icon). > > Any testing and > > >>>>> comments would be appreciated. The kicad2step utility > > which performs > > >>>>> the conversion is of course dependent on OCE and is only > > built when > > >>>>> KICAD_USE_OCE is defined. The "Export STEP" menu item is > > disabled > > >>>>> if the kicad2step executable is not found in the same > > directory as the > > >>>>> pcbnew executable. > > >>>>> > > >>>>> > > https://code.launchpad.net/~cirilo-bernardo/kicad/+git/ > kicad-oce/+ref/kicad-step > > <https://code.launchpad.net/~cirilo-bernardo/kicad/+git/ > kicad-oce/+ref/kicad-step> > > >>>>> > > <https://code.launchpad.net/~cirilo-bernardo/kicad/+git/ > kicad-oce/+ref/kicad-step > > <https://code.launchpad.net/~cirilo-bernardo/kicad/+git/ > kicad-oce/+ref/kicad-step>> > > >>>>> > > >>>>> - Cirilo > > >>>>> > > >>>>> > > >>>>> _______________________________________________ > > >>>>> Mailing list: https://launchpad.net/~kicad-developers > > <https://launchpad.net/~kicad-developers> > > >>>>> <https://launchpad.net/~kicad-developers > > <https://launchpad.net/~kicad-developers>> > > >>>>> Post to : kicad-developers@lists.launchpad.net > > <mailto:kicad-developers@lists.launchpad.net> > > >>>>> <mailto:kicad-developers@lists.launchpad.net > > <mailto:kicad-developers@lists.launchpad.net>> > > >>>>> Unsubscribe : https://launchpad.net/~kicad-developers > > <https://launchpad.net/~kicad-developers> > > >>>>> <https://launchpad.net/~kicad-developers > > <https://launchpad.net/~kicad-developers>> > > >>>>> More help : https://help.launchpad.net/ListHelp > > <https://help.launchpad.net/ListHelp> > > >>>>> <https://help.launchpad.net/ListHelp > > <https://help.launchpad.net/ListHelp>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> _______________________________________________ > > >>>>> Mailing list: https://launchpad.net/~kicad-developers > > <https://launchpad.net/~kicad-developers> > > >>>>> Post to : kicad-developers@lists.launchpad.net > > <mailto:kicad-developers@lists.launchpad.net> > > >>>>> Unsubscribe : https://launchpad.net/~kicad-developers > > <https://launchpad.net/~kicad-developers> > > >>>>> More help : https://help.launchpad.net/ListHelp > > <https://help.launchpad.net/ListHelp> > > >>>>> > > >>>> > > >>>> _______________________________________________ > > >>>> Mailing list: https://launchpad.net/~kicad-developers > > <https://launchpad.net/~kicad-developers> > > >>>> Post to : kicad-developers@lists.launchpad.net > > <mailto:kicad-developers@lists.launchpad.net> > > >>>> Unsubscribe : https://launchpad.net/~kicad-developers > > <https://launchpad.net/~kicad-developers> > > >>>> More help : https://help.launchpad.net/ListHelp > > <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
