-
Notifications
You must be signed in to change notification settings - Fork 30
Path module workplan
The robot workbench is thought by Jürgen as unsuited for CNC, basically because the data structure is too heavy for typical CNC paths, that can contains thousands of points. Therefore, we will build a new module, called Path module, that contains tools similar to the Robot module, namely:
A command object, that define a CNC command, such as G1 (move), and its parameters (such as X, Y). That object should be able to represent the whole range of CNC commands, and have a variable number of parameters. The possible parameters for each command are well defined ( http://www.linuxcnc.org/docs/html/gcode.html ) so it is possible to build a validation table that would prevent the creation of a command with wrong or insufficient parameters. The command object can be created and manipulated from python, for example:
import Path
myop = Path.Command("G1",{"x"=1,"y"=5})
myop = Path.Command("G1X1Y5")
myop = Path.Command("G1 X1 Y5")
myop = Path.Command("G1,X1,Y5")
myop = Path.Command("G1",App.Placement(App.Vector(1,5),App.Rotation()))
print myop
print myop.Name
print myop.x
myop.x = 4
Problem: some commands might have an infinite number of parameters (for ex. splines). A solution could be to store placements,3d vectors and floats in vectors.
But since there can easily be thousands of commands, we need to pack the data in the smallest structure as possible. Since all arguments are floats, I propose to use a map of floats (similar to a python dictionary). This way, the map will contain only the minimum amount of data. It will also make the command very easy to translate to/from actual gcode.
We could also have a couple of handy python attributes that create higher-level data from that data, on-the-fly, for ex:
myop.x (gets the x value directly from the map)
myop.r (gets the r value directly from the map)
myop.Placement (a placement is calculated from x,y,z and a,b,c)
myop.Point (a 3d vector is calculated from x,y,z)
examples of gcode commands and parameters:
| Command | What it does | Arguments |
|---|---|---|
| G0 | rapid move | placement (X,Y,Z,A,B,C): endpoint |
| G1 | normal move | placement (X,Y,Z,A,B,C): endpoint |
| G2 | clockwise arc | placement (X,Y,Z,A,B,C): endpoint |
| vector (I,J,K): centerpoint | ||
| float (R): radius (alternative) | ||
| float (P): number of full circles | ||
| G3 | counterclockwise arc | placement (X,Y,Z,A,B,C): endpoint |
| vector (I,J,K): center | ||
| float (R): radius (alternative) | ||
| float (P): number of full circles | ||
| G4 | wait | float (P): number of seconds |
| G5 | spline | different methods, with many |
| different possible parameters. there | ||
| can be more than one endpoint (G5.2) | ||
| or more than one vector(G5.1) | ||
| G81,G82 | drill | placement (X,Y,Z,A,B,C): endpoint |
| float (R): rapid move in Z | ||
| float (P): dwell time | ||
| G90, G91, etc.. | commands with no args, | no parameters |
| like change mode | ||
| M3,M4 | set rotation speed | float (S): speed |
A tool object, that stores tool properties. This object can be added to a list, that will become a property of a cnc project. There should be a series of presets that should be stored in text files. Also creatable from python, for example:
mytool = Path.Tool(preset="mypreset")
print mytool.Diameter
tool properties
- Name (utf8), ex: 12.7mm Drill Bit
- Type (enum), ex: Drill Bit
- Number (integer), ex: 4
- Material (enum), ex: Carbide
- Diameter (float), ex: 12.7
- Length Offset (float), ex: 127
- Flat radius (?)
- Corner radius (?)
- Cutting edge angle (?)
- Cutting edge height (?)
Problem: Tools should be stored into text files, similar to Material cards, so they can easily be reused. Some of these cards can be shipped with FreeCAD, others can be added by the user. Alternatively, we could use something like the LinuxCNC tool table, but that is hard to modify/append by the user…
A path object, that is an ordered sequence of operations, and also holds a tool object. That path object can be created and manipulated from python. The path object could also hold additional parameters if needed. For example:
mypath = Path.Path([myop1,myop2])
print mypath
print mypath.Commands
mypath.Commands = mypath.Commands.pop()
mypath.toGCode()
Since the data stored into a path object can be huge (thousands or even millions of commands), we need to be able to store large amount of data on disk. Therefore, the data should be saved not in xml format but in agnostic gcode format (independent from specific machines), since that format is already optimized for compactness, it is the best format we have. FreeCAD already provides all the necessary tools to do that.
A path property, that can be added to a FreeCAD document object, that stores a path. That property will not be directly editable in the FreeCAD GUI at the moment (too complicated)
A path FreeCAD document feature, that holds a path. That's all it does. It also provides a python version, that's where the fun will happen (see below). The path feature populates and maintains its path property with the needed sequence of operations.
A view provider for that path object, that can represent the path in the FreeCAD 3D view. Each segment representing an operation should get a different color. These colors should be settable in the FreeCAD preferences.
Some operations can probably not (or hardly) be represented in 3D (coolant ops, etc). I propose to concentrate on the basic ones (straight move, rapid move, arc, etc), and just leave space for extension later.
A CNC job (or path compound) FreeCAD document feature, derived from the path feature above, that allows to store an ordered series of other path features. I thought first of a group, but groups don't allow to change the order of their children, which is important here. The aim of this object is to be exported as gcode. The resulting path of that object would be the simple addition of the paths of its children.
A gcode exporter, that would simply take a given list of path features, and translate their operations to gcode. The very simple translation from Path operations to gcode could avoid passing by the Heeks post scripts, but we might try to fit them in somehow.
A gcode importer, that creates a path feature and fills it with the gcode data. The importer will also handle the opening of files containing gcode.
Additional python-based path features, based on the path feature. These objects will be fully programmed in python, and will be able to define any kind of path operation on any given type of geometry. I'm thinking of creating these basic types:
Profile: creates a profile contour from a face, with an offset given from the tool Pocket: creates a series of pocketing profiles (using something similar to DraftGeomUtils pocket2d() or libArea) Drilling: Creates a drilling operation Dressup: Creates a modification of another path, such as add a holding tag Hop: Creates a rapid move from one point to another, raising the tool of a given distance
These would be the basic types, and would also be useful as examples to encourage the community to create more types. They would be made easy to modify and extend (same structure as the Arch workbench, one file for each, that contains the feature, and the FreeCAD command to create them
A Path workbench, that contains commands to create all the features above, and to import and export gcode.
Simulation: simulation is a difficult matter, but we might try to set up a system similar to the Robot workbench. I would consider this point as "not guaranteed" though, since it can take more time to build than expected and we might run into hard-to-solve issues.