← Back to team overview

kicad-developers team mailing list archive

Re: STEP Export

 

On 9/22/2016 10:13 PM, Cirilo Bernardo wrote:
> 
> 
> On Fri, Sep 23, 2016 at 12:18 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx
> <mailto:stambaughw@xxxxxxxxx>> wrote:
> 
>     On 9/21/2016 9:17 PM, Cirilo Bernardo wrote:
>     > On Thu, Sep 22, 2016 at 10:07 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>> 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
>     <stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>> 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.bernardo@xxxxxxxxx <mailto:cirilo.bernardo@xxxxxxxxx>
>     >>>>> <mailto:cirilo.bernardo@xxxxxxxxx
>     <mailto:cirilo.bernardo@xxxxxxxxx>>>:
>     >>>>>
>     >>>>>     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@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     >>>>>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>     >>>>>     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@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     >>>>> 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@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     >>>> Unsubscribe : https://launchpad.net/~kicad-developers
>     <https://launchpad.net/~kicad-developers>
>     >>>> More help   : https://help.launchpad.net/ListHelp
>     <https://help.launchpad.net/ListHelp>
>     >>
> 
> 



Follow ups

References