We are looking at adding some new code examples to Solid Edge. The question is, what examples would be best?
I'd like to hear what you all think. Also, if someone has a good idea, let me know if you like it too so development knows which are most important.
Posted by: Mark Burhop
Post date: 8/25/2011 3:36:30 AM
In the last 11+ years, I've been working with several CADs API's: PE / CT4 / CT5 / IDEAS and NX.
In the last 3 month I've started to work on SE ST3 API. I'm using .NET(C#).
The following is based on my experience from SE and other CAD API's.
Here is a list of things I would consider adding to SE API:
1. Add a journaling capability similar to the one NX has. It's a long process (NX started with it in 2005, and they still do not cover 100% of the commands). It gives a new level of productivity to Programmers, instead of searching for API sample, or reading the API reference manual, you just create what you need, and the journal system records it for you.
In NX the journaling system records in your preferred main stream programming language (C++, VB.NET, C#, Java).
2. My main API reference is sesdk.chm, most of the code samples there are in VB6. It would be beneficial to replace them with a modern Programming language.
3. It might be my inexperience with SE, but here are some tasks I found hard to implement:
a. I'm unable to find the connection between the curves in Extrude and the curves in the sketch, the curves ids are different in the section and in the sketch.
b. I'm unable to find connection between the sketch placement e.g. plane xy and plane xy. The only way to figure it out is through comparing geometric properties of the plane, and "guessing" that the sketch is placed on the plane with same geometric properties.
c. There is no common unique ID for all SE entities, e.g. for b-rep entities it's the parasolid ID (Edge, Face, Loop etc..) for curves it's "key", it would be very beneficial if all entities would have one common "SEID" property, so the programmer would be able to treat them commonly.
I know implementing the above suggestions is a big task that will probably take years to complete. But it would be great to see improvements in this area over the next several years.
Anyway this is my opinion.I Hope this helps.
Posted by: Tomer Laor
Post date: 8/26/2011 4:09:26 AM
in my now 12+ years career on developing professional solutions for Solid Edge i'm glad to see that some more focus is (and will be) given on enhancing the Solid Edge API environment by giving better documentation, examples, tools etc. I appreciated very much the recent work of Jason done in the area of programming Solid Edge under .NET by providing usefull examples and documentation, starting with Solid Edge ST. And not to forget Jason's tool Solid Edge Spy which helps a lot to investigate the Solid Edge API where the documentation of the Solid Edge API lacks.
Since the VB6 IDE is no longer supported with Windows Vista and Windows 7, i would recommend to provide future examples for .NET written in C# and VB only. Where C++/ATL would ease things, examples in C++ should be provided too.
Important seems to me to provide examples that not only show how to get a reference or an instance of a specific Solid Edge object but also how to work with that object by showing how to use some of its most common properties and methods. The latter i see very important if the return type is Object instead of a specific Solid Edge type.
Also important is that all examples should be usable with the free Microsoft Visual Studio Express Editions. It's possible to provide solutions also for Solid Edge Add-ins etc. as long as no Visual Studio templates are used available with Visual Studio Professional or even higher versions only.
So far my input in respect to the subject of this thread.
Additionally i would appreciate to get the Solid Edge API more and more completed to fill gaps between what is possible by interactively using Solid Edge and what if you need to automate Solid Edge via its API. Currently it's still a quite risky adventure to start a Solid Edge automation project, because you can't be sure it can be done at all. As Tomer already mentioned above, unification is also desired.
Posted by: Wolfgang Kunert
Post date: 8/27/2011 12:56:21 AM
Thanks for the input. It is all good information.
Posted by: Mark Burhop
Post date: 8/29/2011 3:30:43 AM