HeeksCNC Experiences

[david-nicholls]

I wanted to add a comment relating to the 'Input' to a toolpath generator. As the design document says, most toopath generators will use some form of graphical objects as input.

It would be good if we could cater for the following scenarios;
- point features
- these would feed into toolpath generators that only need to know 'where' to put themselves. eg: drilling, counterbore, tapping, positioning and boring operations.
- In HeeksCNC we allow both POINT objects as well as Sketches.
- If the Sketches intersect each other then their intersection points are used. This works well, for example, when drilling for a NEMA?? motor mount. i.e. draw a circle with some intersecting lines to define where the mounting holes are.
- If the sketches do not intersect each other then;
- if they represent an arc or a circle then use that object's centre point as the location
- if they do not represent an arc or a circle then use the centre of the sketch's bounding box as the location

- 2D elements (sketches - arcs, lines, splines, bezier curves etc.)
- these are used for contour, pocket etc.

- 3D elements (either OpenCascade solids (which are converted into STL) or straight STL surfaces
- these are used for the 3D machining operations such as waterline, zig-zag etc.

- Nested toolpath generation objects.
- we've used these in HeeksCNC by allowing one machining operation object (toolpath generator) to be a child of another. This allows a drilling operation to be defined by any of the 'point' locations described above and then to base another drilling operation on this first one. The scenario is to define the locations using graphics and then define a set of centre-drilling, drilling, tapping and/or chamfering operations to be based on the first drilling operation. eg: center-drill, drill, chamfer and tap. Each parent machining operation gets its location information from the next child down.
- the 'chamfering' operation also uses this concept. If the child of a chamfering operation is a drilling operation then the hole's location and diameter can be determined from the child drilling operation. This tells the chamfering operation whether its chamfering bit can just plunge directly into the hole or if it needs to generate a circular arc movement to chamfer the edges of the hole.
- similarly, if a chamfering operation has a contour, profile or pocket operation as a child then the cavity into which the chamfering bit may descend is determined by the child operation's tool definition as well as its depth of cut. The toolpath for the chamfer is also taken from the paths of the child operations.
- the last example is where we use a pocket operation as a child of another pocket operation. In this situation, the parent operation is normally defined with a smaller cutting tool and the child operation uses a larger cutting tool. The child operation has graphical elements as its input. The parent operation asks the child operation for the areas to remove. The child operation returns a set of generated graphics that indicates which areas of the original graphics the large tool could not reach. This is done by doing an offset inwards of the original sketches by the radius of the large tool. It then offsets the result back outwards by the same radius. This makes concave points from the original geometry into circular arcs around their tips. The resulting shape is subtracted from the original sketches leaving just those small areas where the large tool couldn't reach. I know it's a bit early to be worrying about such scenarios but these scenarios do work in HeeksCNC and it would be a pity if we didn't allow for such possibilities in the new CAM module. Even if we added some mechanism where one operation could 'ask' another operation for graphical information. I imagine it could return objects in the form of lists of TopoDS_Shape objects as well as lists of gp_Pnt objects. (Just thinking out loud here) Did Brad say that objects in FreeCAD have unique IDs associated with them? I assume, if this is correct, that the 'input' objects would really be a list of these IDs and that the toolpath generator would query each object by its ID to determine what questions it could ask of it.

[aj5robinson]

Hi David,

Thanks for the valuable input. In summary I think we can cover most if not all of these though some might be acheived slightly differently.

It would be good if we could cater for the following scenarios;
- point features
...
- 2D elements (sketches - arcs, lines, splines, bezier curves etc.)
...
- 3D elements (either OpenCascade solids (which are converted into STL) or straight STL surfaces

It is planed that the TPG can request the input geometry in any of these formats via the TPG API (i.e. methods on the TPG base classes). It is up to the TPG Dev to decide which format is best for their algorithm and call the relevant method.

- Nested toolpath generation objects.

The current plan for the Cam module is that every TPG is somewhat 'nested' within the next though it probably wont be implemented right away. e.g. in a 3D world the first TPG in the CamFeature has the raw stock, the second TPG has raw stock with first toolpath subtracted and so on. The user would control this 'nesting' by altering the sequence of TPG's within the CamFeature. The TPG implementation can choose to ignore the 'nesting' behavior by not calling the API method to get the stock geometry after the previous TPG; a drilling op might be an example where its not needed though a run-time speedup might be achieved if it knows it doesn't have to to a full height clearance between two holes. Obviously computing the stock geometry changes might be a fairly expensive task to compute so its only computed if requested by one of the TPG's that follow. One improvement might be restricting the current stock geometry within an area of interest (bounding box). e.g. where a hole is to be drilled.

Anyway, that's my bit.


Cheers
Andrew