Minimal CAM workbench/API

Here's the place for discussion related to CAM/CNC and the development of the Path module.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
mrlukeparry
Posts: 655
Joined: Fri Jul 22, 2011 8:37 pm
Contact:

Re: Minimal CAM workbench/API

Post by mrlukeparry »

hi evilmalus,

The more user cases the better I think so user's experiences are always valuable :)
evilmalus wrote:stock geometry: the material shape before it is cut even once. usually used for verification purposes in a virtual simulation of machining. i usually dont need any stock geometry for machining, just the finished dimensions.
We hope to eventually simulate the playback of Toolpath and ensure there are no conflicts. I am not sure on if it is necessary but it might also allow us to check the coordinate system and ensure the part lies actually within the material to be removed. Apologies if I sound naive but I have never used CNC machines so I'm going on what people tell me to make this work within FreeCAD :)
awallin55
Posts: 16
Joined: Tue Oct 09, 2012 5:45 pm

Re: Minimal CAM workbench/API

Post by awallin55 »

evilmalus wrote:stock geometry: the material shape before it is cut even once. usually used for verification purposes in a virtual simulation of machining. i usually dont need any stock geometry for machining, just the finished dimensions.
Right. A lot (most?) operations do not need to define a stock geometry. For 3D milling however it will be required, as the final shape of the part is not enough to calculate roughing-paths. Also the stock-material may not always be a 3D bounding-box around the part (but that may be a good approximation/default).
Post Processing: some cam packages have a configuration file (simple programming script) with the generic standard g-codes implimented. That file is usually edited by the user to fit the machines specific needs. So a library, would have to be extensive if you took that approach, is unnecessary as all cnc machines follow basic universal standards (with some tweeks that do not interfere with your basic gcode lines, arcs, drills, rpms, feeds, work coordinates, etc. the tweeks are for manufacturer specific 'extras')
Tool-path generators should produce toolpaths in some machine-independent form which we store in the object-tree, and display in the 3D view.
IMO the post-processor can be a python class with genericly named methods that get called as we step through the program. Each method produces the appropriate text output to the g-code file.
You are correct in that most post-processors are just minor variations on a basic theme.
in my software packages...
Campat (ancient DOS based software i still run on a 486 pc) NO geometry is needed to create a tool path, and 2d drawings only, no solid geometry.
Mastercam 9, solid geometry/ basic surfaces are not needed to create a tool path. only a point, line, or arc is needed. mastercam also internally creates what it calls NCI code before sending to the post processor to be compiled to the g-code text file. NCI seems to be mastercam specific.
chaining of features (lines and arcs) are used in both programs to smooth the tool motion. you dont want the tool to move away from the part for every feature.
We should make it easy to do 2D work, since a large portion of what people use CNC-machines for is 2D or 2.5D work.
I don't know enough about freecad to say how easy this is, but it seems backward to first do a sketch, then extrude the sketch to create a solid, and then extract the edges from one face of the solid. Should there be a more direct way of defining 2D geometry that we can take as input to CAM?
Both come with an editable materials file (with SFM, IPT variables)
mastercam comes with a basic tools file, and both allow you to create a custom tool in one way or another. for example 45 degree, 4 flute chamfer tool with a .04 tip diameter, 1inch length of cut and .375 overall cutter width. Mastercam, you would tell it "chamfer tool" and set all variables. Campat you would set the .04 dia, number of flutes, and when programming toolpaths is where you would set your depth. feed and speed calculations in both programs are derived from the SFM, IPT, and diameter factors.
A materials-file that essentially is used for suggesting speeds/feeds for operations is useful but can come later after we have the basics in place.
An editable tool-library is a good idea also. The tool-library and materials definitions could be stored in separate files, not part-files.
sorry if i sound arrogant or covered things already figured out. i am a machinist and i have three leadwell 3 axis cnc machines with fanuc controls, one hurco cnc 3 axis mill, and a hurco tm6 lathe. and there is finally something here i may be able to help with so i'm a little excited.
This is good, we need people with experience. CAM is hard because it involves so many skills (geometry, math, programming, cnc-control, machining) and people who are good at everything are very very rare.

AW
evilmalus
Posts: 8
Joined: Thu Oct 18, 2012 1:51 pm
Location: Dallas, Tx
Contact:

Re: Minimal CAM workbench/API

Post by evilmalus »

Right. A lot (most?) operations do not need to define a stock geometry. For 3D milling however it will be required, as the final shape of the part is not enough to calculate roughing-paths. Also the stock-material may not always be a 3D bounding-box around the part (but that may be a good approximation/default).
when i am milling a 3d object, the roughing toolpath is based on how high above the finished product i start. for example i tell it to rough mill complex 3d shape, and i draw a square around it telling my tool not to leave the square, or containment boundary. the toolpath will rough that material from my Z height start point down to the highest point of the 3d model, then calculate tool paths going around the part at incrimental depths. so the first many cuts will all be the same toolpath just at different depths. though this way can be inefficient at times.
We should make it easy to do 2D work, since a large portion of what people use CNC-machines for is 2D or 2.5D work.
I don't know enough about freecad to say how easy this is, but it seems backward to first do a sketch, then extrude the sketch to create a solid, and then extract the edges from one face of the solid. Should there be a more direct way of defining 2D geometry that we can take as input to CAM?
yes, skip the the extrude and skip the solid creation part. as g-code is a point to point system it should be fairly simple to tell a tool to cut left, right, or directly on a line/arc. i will usually break down a 3d object into a 2d object so i can do a simple cut. there should be no need to model an entire part to just cut one feature.
My Company's website http://www.MonroeMachineInc.com
mrlukeparry
Posts: 655
Joined: Fri Jul 22, 2011 8:37 pm
Contact:

Re: Minimal CAM workbench/API

Post by mrlukeparry »

evilmalus wrote:
Right. A lot (most?) operations do not need to define a stock geometry. For 3D milling however it will be required, as the final shape of the part is not enough to calculate roughing-paths. Also the stock-material may not always be a 3D bounding-box around the part (but that may be a good approximation/default).
when i am milling a 3d object, the roughing toolpath is based on how high above the finished product i start. for example i tell it to rough mill complex 3d shape, and i draw a square around it telling my tool not to leave the square, or containment boundary. the toolpath will rough that material from my Z height start point down to the highest point of the 3d model, then calculate tool paths going around the part at incrimental depths. so the first many cuts will all be the same toolpath just at different depths. though this way can be inefficient at times.
We should make it easy to do 2D work, since a large portion of what people use CNC-machines for is 2D or 2.5D work.
I don't know enough about freecad to say how easy this is, but it seems backward to first do a sketch, then extrude the sketch to create a solid, and then extract the edges from one face of the solid. Should there be a more direct way of defining 2D geometry that we can take as input to CAM?
yes, skip the the extrude and skip the solid creation part. as g-code is a point to point system it should be fairly simple to tell a tool to cut left, right, or directly on a line/arc. i will usually break down a 3d object into a 2d object so i can do a simple cut. there should be no need to model an entire part to just cut one feature.
One idea we could have is simply using a sketch objects directly. These would actually be easier to convert to Arcs/Lines because they are nearly exclusively of this type - Opencascade introduces bsplines and ellipses.
For 2D or 2.5D work the user could model a stock piece and simply draw a sketch on top and use this for the CAM reference.
danielfalck
Posts: 395
Joined: Fri Oct 07, 2011 8:58 pm
Location: Beaverton,Oregon, USA
Contact:

Re: Minimal CAM workbench/API

Post by danielfalck »

I have been able to pull edges from solids and also from projections of the solid onto a plane (using the 2D projection tool in Draft Workbench)- which has been very slick. I can select the face of a solid and get the coordinates in Z and the arcs and lines that make up the edges of the solid from this.
User avatar
sliptonic
Veteran
Posts: 3457
Joined: Tue Oct 25, 2011 10:46 pm
Location: Columbia, Missouri
Contact:

Re: Minimal CAM workbench/API

Post by sliptonic »

I'm all for making it easy to to do typical 2/2.5D operations and avoiding unnecessary steps but I think we should be careful here. Encouraging the user to pad a 2D sketch into a 3D object has some downstream benefit. Specifically it becomes possible to automatically determine start/end and safety height for operations. Visualizing the toolpath to catch errors is also a lot easier.

There are true 2D operations like engraving that seem silly to try to model in 3D but otherwise I think the application should strongly encourage the user to fully model the part they're trying to manufacture. I won't go so far as to say it should *force* the user to do so. There are plenty of experienced users that work in 2D just fine. However, I wonder if that's just because of what they're used to or if it is truly more efficient.

Just my two cents.
evilmalus
Posts: 8
Joined: Thu Oct 18, 2012 1:51 pm
Location: Dallas, Tx
Contact:

Re: Minimal CAM workbench/API

Post by evilmalus »

sliptonic wrote:I'm all for making it easy to to do typical 2/2.5D operations and avoiding unnecessary steps but I think we should be careful here. Encouraging the user to pad a 2D sketch into a 3D object has some downstream benefit. Specifically it becomes possible to automatically determine start/end and safety height for operations. Visualizing the toolpath to catch errors is also a lot easier.
visualization and machine simulation i agree with. and i caution on too much automation, it could be frustrating if you cant chain only the entities you want if the program selects everything you dont want.
There are true 2D operations like engraving that seem silly to try to model in 3D but otherwise I think the application should strongly encourage the user to fully model the part they're trying to manufacture. I won't go so far as to say it should *force* the user to do so. There are plenty of experienced users that work in 2D just fine. However, I wonder if that's just because of what they're used to or if it is truly more efficient.

Just my two cents.

While valid that 3d modelling does have advantages. if all i needed to do is program a 1/4 inch keyway, i'm just going to draw a line, not model a shaft and keyway. i can draw a line in 5 seconds, rather a model in 5 minutes. and i would still have to find my cutting location with and edge finder and set my tool's height offset at the machine anyway. Sometimes, i have customers who bring me a 2d drawing of an acrylic helicopter panel that has about 40 through holes, 30 counterbores, odd angled chamfers and thin tall walls. i wouldnt want to model that, but rather program the lines given to me.

I'd say its more about efficiency. besides, a machinist who cant learn a better way to do something, is a machinist without a job.
My Company's website http://www.MonroeMachineInc.com
mrlukeparry
Posts: 655
Joined: Fri Jul 22, 2011 8:37 pm
Contact:

Re: Minimal CAM workbench/API

Post by mrlukeparry »

Pushed some further changes with regards to the inclusion of lib-area-clipper - had to change the CMakeLists.txt and the boost python namespace to something more meaningful.

Also worked on integrating the TPGPython using boost::python. I had to separate the TPG into another linked library so that python would recognise this new module.

You can override the run method for example doing the following:

Code: Select all

from TPG import TPGPython
class myTPG(TPGPython):
...     def run(self):
...         return "I am a myTPG - I am a TPGPython class"

tpg = myTPG()
tpg.run()
mrlukeparry
Posts: 655
Joined: Fri Jul 22, 2011 8:37 pm
Contact:

Re: Minimal CAM workbench/API

Post by mrlukeparry »

Okay I've push a few more changes guys. Getting something basic infrastructure working nearly. I've updated the object features, so that if you update the Parts or Stock Geometry it will recompute the TPGFeatureList.

I've also worked more to do with the plugin (TPG) loading:

We can now load and create c++ plugins using the TPGFactory. In c++ it would load like this.

Code: Select all

        Cam::TPGFeature *tpgFeat = dynamic_cast<Cam::TPGFeature *>(tpgDocObj);
        tpgFeat->loadTPG("MyPlugin");
Python is getting there slowly. I am having difficulties importing a persistent python object that we can reference.
So in theory now we can call the run() method defined in python within c++ which is pretty useful.

One thing I need your help with is how we may registering python TPGs with the TPGFactory. The problem is we cannot initialize objects when we load the TPGfiles unless we dereferece them but this would make loading very slow if you had many plugins.

We need some mechanism to register to the TPGFactory what the plugin is and does etc.

One idea is having a commented section that is parsed inside the TPG file using regex? Another option is making a lightweight python function that is called to register the class.
But all of this must be contained within the .tpg file.

Another thing I'm not sure is if we try to import other py files from inside a .tpg it will work (python only likes to import .py files) does anyone know much more about this?

Check it out guys!

Cheers
Luke
zultron
Posts: 17
Joined: Sat Oct 20, 2012 8:42 pm

Re: Minimal CAM workbench/API

Post by zultron »

danielfalck wrote:Another thing to add- all the libraries that the workbench depends on should ship with the application. In the past, with HeeksCNC, we had libraries that weren't included with the package and had to be sought out by the user and compiled separately. That is a nightmare that we should not have to revisit.
I'm a bit late on this conversation, but for this subject, not too late, hopefully.

I package FreeCAD for RPMFusion (OpenCASCADE licensing prevents packages' inclusion into Fedora) and some of its dependencies for Fedora. One of the big headaches in packaging FreeCAD was unbundling libraries shipped with FreeCAD. By Fedora packaging guidelines, packages may not include libraries that are otherwise distributed separately. The FreeCAD source distribution bundles Salome's Mesh, PyCXX and Zipios++, all of which had to be unbundled and separately packaged.

I'm not very familiar with Debian/Ubuntu, but I assume they must have a similar policy, hence the separate FreeCAD dfsg distribution in the files section of the SF project page.

Now that FreeCAD has (at least semi-)official packages for Fedora and Debian, I hope that we can avoid the practice of shipping 3rd-party software with FreeCAD. At least with Fedora, it's not a very difficult thing to package a piece of software and put it through the review process, and takes just a few weeks. Once this small hassle is taken care of, there will be no problems with FreeCAD being accepted into Fedora and Debian, and there will also be no nightmares where users must seek out and compile separate packages.

John
Post Reply