-
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:
See also the Path module documentation
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.
The interperter in the Path Module is purposely designed to only take in a small subset of the gcode machine language. The 'Gcode' commands that it does accept are meant to be generic and not any particular dialect of industry gcode. They are inspired by functions from Heekscnc such as 'feed', 'rapid', 'arc_cw', 'arc_ccw'. The reason that we chose to use two character gcode commands was to hedge our bets regarding speed issues and the possibility of sending large volumes of motion commands over a network.
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.Placement.Base (a 3d vector is calculated from x,y,z)
examples of motion commands and parameters that will be supported:
| 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) | ||
| G90, G91 | absolute,relative move | no parameters |
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 (?)
Comparison between systems ( http://wiki.linuxcnc.org/cgi-bin/wiki.pl?ToolTable )
| FreeCAD | HeeksCNC | LinuxCNC |
|---|---|---|
| Name | Name | Remark |
| (managed by tooltable) | Tool number | Tool number |
| Type | Type | |
| Material | Material | |
| Diameter | Diameter | Diameter |
| Length Offset | Length Offset | Z offset |
| Flat radius | Flat radius | |
| Corner radius | Corner radius | |
| Cutting edge angle | Cutting edge angle | |
| Cutting edge height | Cutting edge height | |
| X offset | ||
| Y offset | ||
| X offset | ||
| A offset | ||
| B offset | ||
| C offset | ||
| U offset | ||
| V offset | ||
| W offset | ||
| Front angle | ||
| Back angle | ||
| Orientation |
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 Path feature that also has a Shape property. When that property is given a Wire, the path is automatically calculated from it. This allows to easily build a path object using the wide array of FreeCAD's shape-based tools, such as the Sketcher or Draft tools.
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 [Done]
- Pocket: creates a series of pocketing profiles (using something similar to DraftGeomUtils pocket2d() or libArea) [Done]
- Drilling: Creates a drilling operation [Done]
- Dressup: Creates a modification of another path, such as add a holding tag [Done]
- Hop: Creates a rapid move from one point to another, raising the tool of a given distance [Done]
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.
Note: "simulation" is one of those words that means different things to different people. Some possible refinements:
run-time estimation. Given the described paths and feed rates, approximately how long will the job take to complete? This will always be an estimate because the control software does all kinds of things to affect acceleration/deceleration and tool changes take time. An estimate of run time is still useful. Also useful to break this down to see how much time is spent in feed moves that are removing material and how much is spent in rapid moves getting the tool where it needs to be.
Simulated part. move a tool of defined shape along the path. Perform a boolean on a solid representing the initial stock. What does the finished part look like? Really useful for detecting bad moves and crashes.
Rendered part. What will the finished part really look like? This is just an improvement to the simulated part. I've seen software that applies fake woodgrain and species. Not much different than rendering a designed part.
Simulated tool. If a tool has a complex geometry, especially a tool designed to 'undercut' material, it can be useful to overlay the tool on the part to visualize the interaction. Also useful for catching stupid errors like incorrect scale values or misplaced decimals.
Animated cutting. A visualization of the cutting process. Useful but not necessary. Eyecandy.
http://www.mmsonline.com/articles/what39s-wrong-with-postprocessors