Oops .. I meant STEP AP210 for electronic assemblies rather than AP 310. At any rate, what the kicad2step tool creates at the moment is AP214; I don't believe OCE currently has support for AP210.
- Cirilo On Fri, Sep 23, 2016 at 12:13 PM, Cirilo Bernardo <[email protected] > wrote: > > > On Fri, Sep 23, 2016 at 12:18 AM, Wayne Stambaugh <[email protected]> > wrote: > >> On 9/21/2016 9:17 PM, Cirilo Bernardo wrote: >> > On Thu, Sep 22, 2016 at 10:07 AM, Wayne Stambaugh <[email protected]> >> 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. > > >> 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. > > - 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 < >> [email protected]> 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" < >> [email protected] >> >>>>> <mailto:[email protected]>>: >> >>>>> >> >>>>> 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/kica >> d-oce/+ref/kicad-step >> >>>>> <https://code.launchpad.net/~cirilo-bernardo/kicad/+git/kic >> ad-oce/+ref/kicad-step> >> >>>>> >> >>>>> - Cirilo >> >>>>> >> >>>>> >> >>>>> _______________________________________________ >> >>>>> Mailing list: https://launchpad.net/~kicad-developers >> >>>>> <https://launchpad.net/~kicad-developers> >> >>>>> Post to : [email protected] >> >>>>> <mailto:[email protected]> >> >>>>> 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 : [email protected] >> >>>>> Unsubscribe : https://launchpad.net/~kicad-developers >> >>>>> More help : https://help.launchpad.net/ListHelp >> >>>>> >> >>>> >> >>>> _______________________________________________ >> >>>> Mailing list: https://launchpad.net/~kicad-developers >> >>>> Post to : [email protected] >> >>>> Unsubscribe : https://launchpad.net/~kicad-developers >> >>>> More help : https://help.launchpad.net/ListHelp >> >> >> > >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
