The week's been a busy one with Group Project work at University - having way too many meetings, that haven't resulted in a great outcome.
This post is in reference to recent commit history in the CAM developer branch
Nevertheless there are has been a few more opportunities to work on the CAM module. The Cam Objects have been tweaked so that the Tool Path Generators are automatically updated when there is change to the Part Geometry and the Stock Geometry material. This is useful for obvious reasons so that the whole Cam Feature will automatically update itself and along with this the resultant GCode rather than having to manually calculate all the features again.
The next step was attempted to integrate a Cam Library - libarea-clipper into the source tree and make the python bindings available for other python modules within FreeCAD. This was only really good practice learning how to play with CMake configuration files, that's all, but the end result is that our TPG's can now use this library if they are c++ or python!
Work also began on working on the TPGFactory methods for essentially loading all the TPG's if they are c++ based or Python based.
C++ was pretty straight forward going where we can interact with the TPG and TPGFeature very easily.
Python requires making an extension using boost::python. This has its set of many difficulties and still has alot of work to get done but in practice it does work.
One stumbling point was that for TPGPython our c++ python extension to be loaded into Python, we have to put this in a seperate dynamic library. Frustratingly this took some time to realise and required numerous changes to the CMakeLists.txt file - the build configuration script we use.
Another painful learning experience was figuring out why the virtual method run() was not being called. This virtual method is defined inside python and are later called. The first thing I forgot was define the callback - see here and I had implemented the run method in TPGPython which created a conflict. Finally atleast we have an interesting message when we call the run method()
I've also implemented the file search function that looks for .tpg files within a directory and is recursive too.
There's still a lot more work to do, but things are coming together fairly nicely. My apologies if this post hasn't made much sense.
Work on the CAM Module (no pretty pictures):
This post is in reference to recent commit history in the CAM developer branch
Nevertheless there are has been a few more opportunities to work on the CAM module. The Cam Objects have been tweaked so that the Tool Path Generators are automatically updated when there is change to the Part Geometry and the Stock Geometry material. This is useful for obvious reasons so that the whole Cam Feature will automatically update itself and along with this the resultant GCode rather than having to manually calculate all the features again.
The next step was attempted to integrate a Cam Library - libarea-clipper into the source tree and make the python bindings available for other python modules within FreeCAD. This was only really good practice learning how to play with CMake configuration files, that's all, but the end result is that our TPG's can now use this library if they are c++ or python!
Work also began on working on the TPGFactory methods for essentially loading all the TPG's if they are c++ based or Python based.
C++ was pretty straight forward going where we can interact with the TPG and TPGFeature very easily.
Python requires making an extension using boost::python. This has its set of many difficulties and still has alot of work to get done but in practice it does work.
One stumbling point was that for TPGPython our c++ python extension to be loaded into Python, we have to put this in a seperate dynamic library. Frustratingly this took some time to realise and required numerous changes to the CMakeLists.txt file - the build configuration script we use.
Another painful learning experience was figuring out why the virtual method run() was not being called. This virtual method is defined inside python and are later called. The first thing I forgot was define the callback - see here and I had implemented the run method in TPGPython which created a conflict. Finally atleast we have an interesting message when we call the run method()
I've also implemented the file search function that looks for .tpg files within a directory and is recursive too.
There's still a lot more work to do, but things are coming together fairly nicely. My apologies if this post hasn't made much sense.
Hi,
ReplyDeleteIm running the http://planet.arcol.hu website, which is mainly 3D printing related blog aggregator site. So I think your Freecad blog would fit into this topic, so I would like to add your site to the aggregator.
Please reply to here or to my email (planetATarcol(dot)hu) address, if you wish this inclusion.
Best,
Laszlo
http://arcol.hu
Sent to early my reply earlier.
ReplyDeleteJust two notes, first and foremost, your work is awesome, and I really enjoy reading your blog.
Second, maybe I should go to freecad forum with this, but its mainly a paradigm, not a bugreport or whining.
Seems like in Freecad everything is modelled from the corner (like cube), while many other 3D application models it from the center (Maya, Rhino, etc).
So if somebody has modelled years in other programs, he should adapt the way he thinks in 3D to the new modelling, which is really difficult. (its like you decide you writes from tomorrow with left hand).
So I think it should be a checkbox somewhere to switch between "model from corner" or "model from center".
Best,
Laszlo
http://arcol.hu
Hi Laszlo,
ReplyDeleteYeah that sounds great, feel free to add me to your planet.
With the Coordinate origins, this is slightly different depending on what is used. Within Part Design, yes the coordinate system is based at the corner - I am not certain if this was FreeCAD's decision or the underlying OpenCascade.
Part Design uses sketches. These sketches are XY planes with a coordinate system based around (0,0). When you create a Pad or Revolve for example, it uses the sketch for its base profile so it's relative to this. This makes more sense. You cannot change the placement for any part created using Part Design.
Our eventual aim for FreeCAD is to make this the central approach for modelling (atleast for mechanical design). Engineering design is nearly exclusivly parametric, to allow for quick design changes,
The Part Module is low level and is used within Part Design and Draft. It's not indended to be used for modelling but a way to fill gaps where features are missing. There could be an option to automatically change the placement location to the center, but I don't think it's worth it in context.
Hopefully that clears it up a bit.