awallin55 wrote:I already wrote this as a comment on sliptonic's blog, but here it is again.
I think the workbench needs about three APIs. By "cam-plugin" below I mean either a python-script (that may use the c++ libraries developed for heekscnc), or perhaps c++ code compiled and linked against parts of freecad.
How is geometry pushed from FreeCAD into a CAM-plugin. I suggest simple primitives: point, line, circular-arc, triangle (for surfaces). Not much more, if anything should be required. I suggest keeping this interface minimal and free from references to OpenCascade. Smooth curves are approximated by many short line-segments and may need a tolerance parameter set somewhere. Smooth surfaces also need a tolerance parameter to set the number of triangles generated.
How are toolpaths communicated back from the plugin to FreeCAD. This is some high-level version of g-code, i.e. rapids, and g1/2/3 moves. Once the toolpath is a freecad geometry object it can be viewed, shown/hidden etc. and eventually run through the post-processor to produce machine-specific g-code.
How does the plugin define its own GUI and let FreeCAD know about its existence. Each plugin/operation could have its own toolbar-icon, requirements for input geometry, tool (from a tool library, that can come later), settings (i.e. step-over, cutting-depth etc). Dialogs or wizards for setting parameters,, example screenshots, etc. are defined here. We need a user-interaction pattern for how geometry in freecad is selected. Some cam-plugins will want multiple types of input geometry (e.g. a pocket with starting point/direction for pocketing path, or drive/keepout surfaces, fixtures or "no-go" areas, etc).
An object-tree with operations, tools, input-geometry, parameters would be nice.
awallin55 wrote:Is anything else required?
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.
wmayer wrote:So, you should avoid using again a GPL-licensed library. If you awallin55 are the author of the above libraries but don't want to move to LGPL or BSD then the easiest is to add an exception for OpenCascade.
See also: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617613
What license is freecad distributed under? The website says GPLv2 and LGPL.
Does that mean the OpenCascade license is LGPL compatible?
opencamlib and openvoronoi are currently GPLv3. I may consider adding an exception for FreeCAD, if that is absolutely necessary.
I think plugins should potentially be able to run concurrently with FreeCAD. For example you could open a specialist / proprietary cam program, feed it data, use their GUI, let it do the calculations, process the output and import it back into FreeCAD but have the infrastructure to make this seamless.
mrlukeparry wrote:Okay Guys,
I've put together the first skeleton for the structure of the CAM module. There is no functionality obviously, but it hopefully gives a better indication of how this may come together.
If you are interested in helping develop, please fork my git repo and then when you want push changes through using github. Also it might be best to work on a particular area (TPG classes is good) or atleast say what you would to work on as to prevent duplication of efforts.
https://github.com/mrlukeparry/FreeCAD_ ... r/tree/cam
I don't think there will be heavy changes in terms of the classes, but the methods will change.
If there's anything that you think isn't a good idea, please say. Best to fix things early!
awallin55 wrote:have forked, and got it to build. I see the "cam design" workbench, but obviously it does not do much. CAM is such a standard term so I suggest naming the workbench simply "CAM" (just like "FEM").
awallin55 wrote:What do you mean by "containment". Is that the input geometry that a tool-path-generator (TPG) will work on? I suggest either "InputGeometry" or something similar. This is not necessarily the same as "stock", since the stock material is usually larger and of a different shape than the part we want to machine. It's also not the same as a "containment-boundary" (a term some CAM-programs use) which is additional input-geometry to the TPG which restricts the tool movement.
Users browsing this forum: No registered users and 0 guests