Dear all,

A few years ago, I developed a software aimed at providing rigid body
simulation features to Catia V5 or SolidWorks. This project, known as
"Decade dynamics", is not active anymore although many users are frequently
asking for new features or bugfixes (for your information, a website
dedicated to the project is available at  http://www.decade-dynamics.org,
there also is a PDF document here:
http://download.gna.org/decade/decade_A4_recto_basse_def.pdf and
http://download.gna.org/decade/decade_A4_verso_basse_def.pdf - All this
material is in french, sorry).

The limitations I faced when working on that project are the root of my
motivation to start the pythonOCC project:
- the small 'free' API provided with Catia or SolidWorks (a VB API) is not
sufficient to access all internal classes/method,
- the complete API (known as CAA for Catia) is very expensive,
- there are licensing issues if you ever want to redistribute such a
program. I chose to distribute Decade under the GPL license, and never had
any problem with software vendors: I never made money with it, there's no
real business opportunity, so lawyers dont' care about my work.

However, I'm still interested in rigid body simulation, since it's much
important when working in the robotics/mechatronics field and, more
generally speaking, in engineering. I committed to the pythonOCC subversion
the first draft of a DYN package dedicated to rigid body simulation (you can
have a look at this video to see the first results:
http://www.youtube.com/watch?v=IW5VYbCGFYc).

This DYN package is at the same level as PAF(Parametric Application
Framework). The set of sub-packages PAF/DYN/MSH/FEM are what we called the
'Level2 API': it's an intermediate layer between the OCC kernel (LeveL1) and
the applications that can be built on top of them. The goal is also to make
them interoperable, I mean being able to exchange data in a consistent way:
I imagine a 3D complex model, made with PAF, simulated with DYN to get
forces in joints, checked with a FEM analysis, then optimized  according to
these results (the design/simulation loop), and finally exported to a STEP
file for manufacturing. All of these sub-packages would rely on
a semantically explicit knowledge (KBE). Well, this is not a roadmap, rather
a long term objective...

Please let me know if you have any comment or suggestion,

Best Regards,

Thomas
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users

Reply via email to