kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx>]

Thanks Marcos,

 I'll see if OCE has some scheme for guessing at progress; otherwise the best
I can do is capture stdout and print information on the file which is
to be loaded
next such as the name and file size.

- Cirilo

On Tue, Sep 27, 2016 at 5:06 AM, Marcos Chaparro <nitrousnrg@xxxxxxxxx> wrote:
> 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 <stambaughw@xxxxxxxxx>
> wrote:
>>
>> 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>
>> >     >>
>> >
>> >
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>
>