status

[danielfalck]

This is from a long thread that we have going on in email that needs to be copied over to the forum for the purposes of search and more discussion:
From Andrew:

Hi Marcus,

Thanks for your interest in the CAM module.

Yes, github.com/andrewjrobinson/FreeCAD_sf_master/blob/cam-py/src/Mod/Cam2 is the main source tree we use however there are others who work on this project who have slightly more up-to-date trees

David Nicholls: https://github.com/DavidNicholls/FreeCA ... ree/cam-py is the most active one.

The document we use for designing this module is located at: https://docs.google.com/document/d/1v5z ... Ti1I0/edit#

There are two other documents for TPG developers and Cam Users however these are not very complete but should help you understand how the module is intended to work.
TPG Developer: https://docs.google.com/document/d/1c5A ... zhal8hab46
Cam User: https://docs.google.com/document/d/14qY ... 9lhdg31bel

Each TPG has a "Geometry" setting provided to it by the TPGFeature super class. This will give you a list of input geometry names that the user wants. The TPG then uses this list of names to get the Geometry via various methods provided on the TPGFeature superclass; there are options to get it in various formats though STL and native freecad format are only implemented at this point on the C++ side. The Python implementation is not as complete as the C++ one.

Hope that helps you get your hands dirty with this project. Let me know if you need any more assistance (also I am arobinson on the IRC channel, though I am on Australian Eastern time so might be the middle of the night for you).


Cheers
Andrew


On 29 January 2014 23:52, wolschon wrote:


Hello Andrew,

I'm looking at the unfinished CAM API for FreeCAD to
see where I can help.
My intention it to port my "simplemultiaxiscam" Code
to use this API later to post-process an existing toolpath
and add the inverse kinematic and collision-handling for
4 and 5 axis milling trying to follow the surface normal
as close as possible.

Is
://github.com/andrewjrobinson/FreeCAD_sf_master/blob/cam-py/src/Mod/Cam2
the source repository to work against (clone and send pull-requests)?
Is there any documentation to keep up to date and complete?

Who else is working on this and where is the implementation
being discussed, issues tracked,...?
http://www.freecadweb.org/wiki/index.ph ... AM_project
is somewhat basic regarding the details to start practical work.


I'm currently looking through the sources and will set up a
development environment (on MacOS) soon.
My Python and C are a bit rusty but I guess I'll manage.
Currently' I'm trying to figure out how
ExampleTPG.py
or CppTPGFactoryInst/CppTPG get a reference to the geometry,
tool+collet-shapes and machine (axis) definitions as well as
methods to do collision tests. I understand that some of this
simply doesn't exist yet.

Marcus

[danielfalck]

From David Nicholls:

Hello Marcus,

as Andrew said, I am one of the developers contributing to this but my activity has been pretty lax over the last couple of months. I mostly use my 'nightly' branch for my current work and then merge it into Andrew's 'cam' branch when it's at a reasonable point for others to play with.

I'm very pleased to see another programmer contributing to the project. If you have any questions about my code, please don't hesitate to ask.

The current form of the code allows a 'Tool Path Generator' (TPG) to include a 'Geometry' setting. This 'Geometry' setting includes a list of object names from the current file. We also have a cam::Paths class that accepts these geometry names, looks for those that are based on the Part::Feature class (and hence have a TopoDS_Shape reference). The cam::Paths class recursively iterates through the TopoDS_Shape objects until it finds the TopoDS_Edge objects. Each TopoDS_Edge represents a single 'curve' (i.e. line, arc, or spline, bezier curve). The cam::Paths class assembles these edges into lists of contiguous edges based on their endpoints. These contiguous edges are stored in the Cam::ContiguousPath class. Generally speaking, the Cam::Path (and related) classes allow me to contain, arrange and sort (both spatially and for concentricity) linear segments that the tool could follow. This code was developed for my copy of the HeeksCNC project. The Cam::Path class does also allow Cam::Point objects to be contained so that point-based operations such as drilling, tapping, counterbore, boring etc. can be handled. The Cam::Path class is mostly aimed at 2.5D machining as it makes no attempt at containing surface features as one would find in an STL model.

I have code that will generate Python (and then GCode) from the Cam::Path class(es) but that code is not yet included in the FreeCAD project.

I'm currently working on re-arranging the Cam::Settings classes so that they can be used by more than just TPG-based classes. This will lead into using such settings in the definition of a Tool definition (which is also partly done).

As you will see, it's early days for us at this point but I'm hopeful that, once the tool definition is complete and we find a way to store both project-based configurations as well as machine-based configurations, the porting of some of the HeeksCNC machine operation classes will be quick.

Thanks

[danielfalck]

from Marcus:

Hello,



I have a git-checkout that compiles and shows the CNC UI elements when started.

I have also reat the design document.



What would be a simple task I could start with to get my feet wet?

(My C is a bit rusty and I obviously haven't worked on the FreeCAD codebase yet.)



Regards,

Marcus

[danielfalck]

from David:

Hello Marcus,

thanks for the offer. I got a version of the 'Settings' working and am part way through rearranging them so that they can be assigned to objects other than TPGs. Part of this work is to get the ToolFeature class working. That should leave us with the ability to define tools, define TPG objects (TestPlugin/CppExampleTPG), execute them to produce Python (ToolPath), execute the Python to produce GCode (MachineProgram), re-read the generated GCode back in for validation and rendering. We don't currently render the GCode data produced by GCode.cpp/LinuxCNC.cpp.

Another step that needs to be figured out is how/where we are going to store settings that relate to this model (eg: what is the clearance height we should use for all operations?) as well as settings that relate to the CNC machine it will run on (eg: what spindle speeds are available on the machine?). Brad Collet asked about a spreadsheet module that Yorik was writing and was wondering if it could be used to store such data. I wasn't aware that anyone was developing a spreadsheet module and I'm also unsure whether it could/should be used. If you have an opinion on that then I'd be pleased to hear it.

The other thing I have been incapable of is writing the Python interface to the C++ classes that we have already developed. If you have an interest in the C++/Python interface then you're welcome there too.

Please forgive my long list. I'm just throwing stuff around in the hope that something interests you. If you prefer you could just elect to get used to the code and decide if there is some aspect of it that you're interested in. Any help in any direction sounds good to me.

Thanks

[danielfalck]

from Marcus:

Hello,

I guess with the ToolFeature I'd collide with your work and slow you down
and for the persistent storage I'm not experience enough in what the codebase
offers and what other modules do.

So I'll see about python interfaces to the current C++ classes.
I guess that would mean adding properties from CppTPG to python TPG
and writing python classes for other C++ classes of that directory.
No idea how to integrate and test them yet but I some closer inspection
of the existing codebase should reveal that.

Regrads,
Marcus

[danielfalck]

from David:
Marcus,

honestly, feel free to contribute in any way that interests you. The beauty with open source software is that you can contribute when you feel like it and let it go when your attention is somewhere else.

I tried to produce some classes to wrap up the Settings classes in PyTPGSettings.cpp/h. At one point it started to look promising in that I was able to instantiate an instance of the C++ class, get/set member variables and even call a method within the class from Python. What I could never understand was how to use the Py::PythonExtension template to expose C++ classes that inherited from other C++ classes. I suspect Py::PythonExtension is simply the wrong tool for the job.

The one clue that I only figured out the hard way was that a method call is handled like reading a variable. i.e. the pointer to the method is returned by the same method that returns references to member variables. i.e. either getattr(char *) or getattro(PyObject *). You need to have the getattr_methods() call at the bottom of the getattr() (or getattro()) method. See PyDefinition::getattr() implementation in PyTPGSettings.cpp.

I gather there are many ways to expose a C++ class to a Python runtime. The first is to declare and populate structures like PyTypeObject. I never understood them but it seems that this method is most often used in the FreeCAD code. I tried using the Py::PythonExtension<> templates and, as I said, it got me part of the way but not all the way.

I'm afraid I never really understood it well enough to succeed.

Please don't work on a module because I ask you to. Make sure it's something that interests you. It doesn't have to be the next thing other people think we need. I would much prefer you to keep contributing than get frustrated with what someone else wants you to do and stop working on it.

Thanks

[danielfalck]

from Marcus:

Hi,

I found the understand the C++,Py and global TPGFactories and how the
Python TPGs get integrated now. Progressing to the actual plugin instances
and possibly missing or not exposed methods on the Python version compared
to the C++ version. I'll see if I can wrap my head around the Python to C++
integration in more detail. Your mail was most helpful.

Is there any way I can execute any of the code on a Python TPG?
e.g. the test() methods? Perhaps a unit-testing rig I haven't found yet.

If I can't find out how to do this, I'll try to write a most trivial
actual tpg operation into the Example C++ TPG. It's the most easy method
to find missing APIs and learn about handling the model and collisions
I'll need later when it's time to integrate my 4+5 axis inverse kinematic code.

Marcus

[danielfalck]

from David:

Marcus,

I'm particularly interested in the 4+5 axis stuff you've done. I only have a 3 axis mill right now but adding a fourth axis is definitely on the cards. Making a five axis mill is one of those 'when I grow up' things.

The other thing I need to do is change the Python interface to the libArea code. It currently uses the boost::python system but the FreeCAD people were eager to not include the boost::python library as they believe it produces 'bloated' code. I only mention this because I remember needing to manually move the libArea.dll (or libArea.so for Linux) file into one of the directories beneath the c:\Python26 area. When we load the CAM module (via its DLL) into the Python runtime, it requires the libArea module in turn. When it can't find it the failure seems silent.

I can't remember all the details right now but I'll try to find the steps I tried earlier. I suspect Dan Falck and/or Brad Collete will be better resources for this than I am (sorry guys) as they know Python better than I do. I only know enough to 'get my face slapped' (as it were).

I'll let you know when I dig my old test routines up.

By the way, are you developing on Linux, Mac or Windows? If it's Windows then I might be able to just send you a DLL or two to get you going. If it's the others then I'll have to try harder.

Thanks

[danielfalck]

from David:

Hello Marcus,

I've found a couple of the scripts I used when I played with the Python interface last time. The series of sys.path.insert() calls are just so that the Python runtime can find the DLLs after they've been compiled on the Windows machine. The alternative is for you to copy the various DLLs into the directory that the Python runtime expects.

As I mentioned earlier I'm pretty sure the libArea library requires the boost::python library which FreeCAD does not use. I think I had to compile that for the version of boost and Python that I used and then manually copy it into the c:\Python26\Lib (s) directory (something like that anyway). Without this the cam module would not load and the failure was silent.

Hopefully you can find some clues in these files that might help but I wouldn't pin too much on them. As I said, I never succeeded in this stuff and I really did try quite hard. I'm a C++ programmer by trade but I could never understand the Python interface. I think I got confused over the large number of mechanisms by which it could be achieved. I should have stuck with one system and learned it right through.

Just in case there is any confusion, I thought I should mention the distinction between this Python interface and the one that is executed by the FreeCAD module itself. The CAM module uses ToolPath Generators (TPGs) to generate Python source code. This Python source code is contained within the ToolPath class. The cam::PostProcessor class drives FreeCAD's internal Python runtime so that each of the lines in the ToolPath class are executed. It redirects stdout and stderr from the Python runtime environment back to its own methods for the execution of the ToolPath code. It expects that stdout will be GCode and that stderr will be any faults (including exception messages). The resultant GCode seen on stdout is stored in the MachineProgram class. The GCode contained within the MachineProgram class is parsed using the LinuxCNC classes. The result of this is a data structure stored within the GCode.cpp classes. This data structure indicates which lines of Python in the ToolPath object generated which lines of GCode in the MachineProgram object (and vice versa). It also indicates lines and arcs (TopoDS_Edge objects) that represent the tool's movement represented by the GCode. This graphical data is not yet rendered but it will be one day.

The TPGs generate Python source code that often makes use of Python classes found in the FreeCAD_sf_master/src/Mod/Cam2/App/PyPostProcessor/PostProcessor directory. These are NOT the Python routines we're talking about for the C++ interface.

The Python interface we're talking about is one that a Python programmer would use to either write their own TPG or to import the CAM module and drive the TPGs along with other C++ modules from their own Python runtime.

Sorry for the 'war and peace' response. I just wanted to make sure there was no confusion (although there may be now)

[marcuswolschon]

>By the way, are you developing on Linux, Mac or Windows?
> If it's Windows then I might be able to just send you a DLL or two to get you going. If it's the others then I'll have to try harder.

I'm using FreeCAD on MacOS but for the sake of simplicity I'm developing in a
Linux Virtual machine.

You can download it here:
http://marcuswolschon.blogspot.de/2014/ ... nt-vm.html
It contains all dependencies, a git checkout of TRUNK and KDevelop.
My personal one of cause works on the cam branch and has the proper remote repositories.