kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx>]

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 <cirilo.bernardo@xxxxxxxxx
> wrote:

>
>
> On Fri, Sep 23, 2016 at 12:18 AM, Wayne Stambaugh <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>
>> 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 <
>> 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>>:
>> >>>>>
>> >>>>>     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     : 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
>> >>>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> 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
>> >>
>>
>
>