On 12/12/2010 04:44 PM, Thomas Paviot wrote:
Dear Steve,
The OMG CAD Services (OCS) specs are still freely available from the OMG
website (the latest release is 1.2 : http://www.omg.org/spec/CAD/).
Thanks, I just removed the 1.1 doc from my site! (I had a local
copy and hadn't bothered to check whether OMG still had an
accessible version of the spec.)
I agree
with you about the fact that the OCS is a good starting point. I briefly
studied the OCS some months ago, and have a few notes I'd like to discuss with
you:
* from a technical viewpoint, the CORBA technology is perfectly suitable
for synchronous sharing of business objects through a network. In my
opinion, an asynchronous collaboration should be enough (regarding the
business needs related to usual CAD workflows) and Web Services (WSDL,
SOAP etc.) might just be perfect;
I find CORBA a bit "heavy" compared to some more recently
introduced technologies, and nowadays I don't think of OMG specs
as implying CORBA implementation, albeit they are still defined
using IDL (which I kind of like). I must also confess an
aversion to SOAP/WSDL -- yes, they work, but they are (IMO) also
rather clumsy to develop with. Apologies for being so judgmental
about those -- I'm sure they will work fine for any developer who
is more comfortable with them than I am. I am very interested in
building an architecture for communications between CAX tools and
services, but I currently plan to use lightweight message-based
technologies to implement a common "info bus" through which tools
and services would communicate using a set of pub/sub type APIs.
Of course, there may also be use cases for which remote object
protocols are appropriate, but a lot of tools and services will
require wrappers to participate and I suspect messsaging wrappers
may be easier to write than remote-object-style wrappers that
have to maintain a lot of state. That certainly doesn't preclude
defining objects as the things that are communicating, so perhaps
it's just a remote object architecture by another name. ;) The
particular technology that I'm planning to experiment with is
Twisted's "Asynchronous Messaging Protocol", AMP[1], which is
very lightweight and elegant (Twisted also has Perspective
Broker[2], an interesting remote object protocol).
* from a semantic viewpoint, whereas the computational model is explicit,
the informational model is mostly implicit. For instance, the
CadBrep::Face class definition could be whatever. In my opinion, it could
be a good thing to harmonize the semantics contained in the OCS and the
STEP parts 42, 55 etc.;
I wholeheartedly agree with that! In fact, speaking of
semantics, I'd actually like to have an ontology (OWL) from which
the informational model (schema) is generated -- of course, this
is a design principle I'm trying to implement in my
work-in-progress, PGEF[3] ... ;)
* some of the methods defined in OCS are strongly platform dependent: for
instance CAD User Interface, paths etc. A high level CAD API should
abstract these concepts and be platform/CAD system independent;
I certainly agree that all methods should be platform
independent. In a quick glance I didn't notice anything
platform-dependent -- can you give an example?
* at last, I have a few doubts about the persistent identification since I
know it's still considered as a major issue. And I wonder whether or not
the OCC topological naming could be mapped to these persistent_ids.
I agree there could be issues there also -- a big stumbling block
in trying to implement a product model in which important printed
circuit board features could have their identities survive a
round-trip (import/export) to/from an MCAD tool is the lack of
session-independent persistent identifiers in MCAD tools at the
"feature" level. Of course, you might have meant something else
;), but that is one persistence issue I'm aware of!
For me this is a very useful thread and I'd like to help in any
way I can with helping to define and test a high-level CAD API.
Cheers,
Steve
[1] http://twistedmatrix.com/documents/8.1.0/api/twisted.protocols.amp.html
[2] http://twistedmatrix.com/documents/current/core/howto/pb.html
[3] https://pangalactic.us/repo/pgef
P.S. Thomas, do you think someone from the pythonOCC team might
participate in PDE 2011? I hope so!
Best Regards,
Thomas
2010/12/12 Stephen Waterbury <water...@pangalactic.us
<mailto:water...@pangalactic.us>>
Thomas, Dan, Dave,
A precedent (or at least a closely related concept) was the "CAD
Services API" developed by the [now defunct] OMG Manufacturing
Technology & Industrial Systems Task Force (MANTIS). That
specification is no longer active. It basically fell prey to
the OMG rule that an active spec must be implemented by at least
2 vendors -- it was only implemented by one vendor (see below) --
but it represents some good work that is still potentially
useful.
The fact that only ITI had a product that implemented the CAD
Services API specification is more an indication of the hesitancy
of CAD vendors to provide a standardized API than of the quality
of the spec, IMO. ;) I've put a copy of its last version on my
web server for convenience (not publicized since I think OMG's
copyright might still be in force, not sure -- but since NASA
contributed to the spec, I feel somewhat justified in making it
available!):
http://pangalactic.us/cax/CAD_Service_V1.1_030363.pdf
It's interesting to note that both NASA *and* OpenCascade
contributed to the spec. It is based on the API of "CADScript",
a set of Python wrappers for CAD tools that was developed as a
commercial product by Doug Cheney of International Technegroup
Incorporated (ITI). CADScript is no longer offered by ITI as a
product, but Doug (who is a strong python advocate) has used a
Python API internally for another ITI product of which he is the
primary developer, called CADIQ, which analyses CAD models for
various types of modeling errors that could lead to data exchange
problems or manufacturing problems, for example. (The CADIQ url
is: http://www.transcendata.com/products/cadiq/) Doug presented
the CADScript product at the PDE 2001 Workshop at JPL. His
presentationslides are here:
http://step.nasa.gov/pde2001/STEP-and-Scriptable-CAx-Tool-Integration_Doug-Cheney.ppt
Doug also did an impressive live demo using CADScript for the
Multi-CAD Assembly use case shown in his next-to-last slide.
Also, from recent conversations with Doug, I know that users of
the current CADIQ product can be given access to the supported
Python API that it uses (not sure how much of CADScript might be
there).
I agree with what Thomas proposes below -- the concept of a
standardized high-level API that would have a standardized
framework or methods to specialize it for particular use cases.
I'd suggest considering the CAD Services API specification as a
starting point for a high-level API, since that spec incorporates
a substantial amount of harmonization work that was done to
develop a consensus high-level CAD API, and I think if pythonOCC
provided a high-level API that implements even something close to
the CAD Services API, it could provide a de facto industry
standard high-level CAD API, with the hope of getting it adopted
by other tools, and in the future possibly made a formal standard
(by OMG, ISO/IEC, or whomever).
Cheers,
Steve
On 12/11/2010 03:47 PM, Thomas Paviot wrote:
Dear Dan, Dave,
I didn't know about the openscad project, thanks for introducing me this
project. Dave, you write "it is a tool that allows programmatically
building
solids using python and a CSG kernel", but I don't see any python
scripting, I
have rather the feeling that the scripting language of openscad is a
kind of
specific language, am I wrong?
I agree with both of you regarding the high-level API that could be
built upon
pythonOCC. Abstracting the low-level OCC api/data model would be
something
really helpful. From a development viewpoint, there is not big issue :
we all
developed or our own classes/methods or function in pythonOCC in ordre
to
speed up development and make our programs modular. The big deal is
rather :
what classes/methods should be made available to the user? How could
this set
of functions be complete, i.e. how to ensure that *all* the needs from
any
user are covered by this API ?
In my opinion, there's no way to get it done (I've been thinking about
this
for a long time). We'll always find a user that is not satisfied with
the API
and who requests for another method/class etc. The risk is then that
this high
level API become as big and complex as the original one (OCC).
We could then imagine a different workflow than the usual one. I think
about
something that was used for the standardization of the AP239 of the STEP
standard (also known as PCLS) : a very generic data model were designed
(and
standardized), and the specialization of the data model was also
standardized.
As a consequence, users with very specific business just join their
efforts to
define a standardized specialization of the generic data model suitable
for
their needs (aviation maintenance, operational feedback etc.).
This development model could be moved to the pythonOCC high level API
development :
* a generic data model would be defined, with basic and fundamental
elements ;
* a framework for specializing this model is also defined. Both of
this
two points could be viewed at an ontological level ;
* we then set up a 'high level API' repository with a set of basic
classes/methods already defined ;
* from these 2 points, we just let the user contribute new
classes/functions/methods if what he is looking for is not already
available from the repository.
It could be a way for us (developpers of pythonocc) to share the
development
efforts of this needed high level API. And to have, as a consequence, a
huge
web-based repository of python classes/methods/functions, classified by
businesses (FEM, manufacturing etc.), level of granularity, functions
(gears,
bearings etc.) etc.
pythonOCC would then become a kind of distributed library : a core
component
(the python wrapper), required, and thousands of optional components
available
online, supported by a powerfull request engine. Setting up such an
architecture is more a scientific project than a simple python
development
activity.
What do you think about that idea?
Thomas
2010/12/11 Dave Cowden <dave.cow...@gmail.com <mailto:dave.cow...@gmail.com>
<mailto:dave.cow...@gmail.com <mailto:dave.cow...@gmail.com>>>
Yes, definitely a higher level of abstraction is needed than just
pure python.
I am thinking ( not surprisingly ) of an environment a lot like a
java
ide. You write code, but the ide provides syntax highlighting,
function completion, refactor support, code templates, a way to
include other libraries, etc.
On 12/10/10, Dan Falck <dfa...@frontier.com <mailto:dfa...@frontier.com>
<mailto:dfa...@frontier.com <mailto:dfa...@frontier.com>>> wrote:
> Yes, this technique does work- I've used it for commercial design
work
> with some proprietary modelers (Ashlar Cobalt and PunchCad Shark FX)
> that used a crude scripting language-called of all things 'Macro
> Parser'. I was able to make simple changes to the scripting that
would
> be major changes to the model. This allowed for very flexible
revisions.
> It also made it easy to recover from a crash if the application was
> acting finicky.
> I was able to do fork crowns for bicycles (classic Italian style-not
the
> modern stuff) by using techniques that emulated a cnc mill tool path
> through the solid block. The whole time I was working the model as a
> machinist would at a mill or lathe- subtracting shapes from the solid
> that I started with. Python code was necessary to keep me from
losing my
> mind during these projects :) I created some functions that made
dealing
> with the crude 'Macro Parser' scripting a lot easier.
> PythonOCC looks a whole lot more attractive to me than my old work
with
> this crude scripting. But, I would like to be able to abstract it a
> little more though to make it easier to remember how to use it,
without
> having to go to the OCC docs all the time. I would bet that Thomas
and
> Jelle are working on something like this.
> I think this project might be similar to what we are talking about:
>
> http://www.caddd.org/
>
> Dan
>
> On 12/10/10 2:27 PM, Dave Cowden wrote:
>> I assume that someone has seen this:
>>
>> http://openscad.org/
>>
>> it is a tool that allows programmatically building solids using
python
>> and a CSG kernel.
>>
>> If such a tool used pythonOCC instead, it would be _much_ more
powerful.
>>
>> This kind of tool is really interesting to me. Anyone who has done
>> much solid modelling for a living quickly realizes that a complex
>> solid model is much like a programming problem. You cannot just
>> 'start building' a complex model: you have to plan how the object is
>> built, which references are used, etc, so that the object is
>> extensible and easily changed to accommodate design iterations. It
>> becomes really important to plan reference planes and other
reference
>> geometries to reference each other in a way consistent with the rest
>> of the model.
>>
>> Using a programming language to capture the [currently always
>> proprietary] way that solid modelling packages capture the build
order
>> and dependency chains of a solid ( especially parametric solids ) is
>> brilliant. As programmers, we are very familiar with the ability to
>> use CVS merge and other utilities to track fine-grained changes to
>> software over time, even when under concurrent development. Imagine
>> the power of this capability applied to scripts that produce solid
>> objects! No more huge binary solid object files that are opaque
from
>> a change management viewpoint!
>>
>> Does anyone know if such a package is underway anywhere based on
>> pythonOCC?
>>
>>
>>
>> _______________________________________________
>> Pythonocc-users mailing list
>> Pythonocc-users@gna.org <mailto:Pythonocc-users@gna.org>
<mailto:Pythonocc-users@gna.org <mailto:Pythonocc-users@gna.org>>
>> https://mail.gna.org/listinfo/pythonocc-users
>
--
Sent from my mobile device
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org <mailto:Pythonocc-users@gna.org>
<mailto:Pythonocc-users@gna.org <mailto:Pythonocc-users@gna.org>>
https://mail.gna.org/listinfo/pythonocc-users
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org <mailto:Pythonocc-users@gna.org>
https://mail.gna.org/listinfo/pythonocc-users
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org <mailto:Pythonocc-users@gna.org>
https://mail.gna.org/listinfo/pythonocc-users
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
