voneiden/cq-cam

CQ-CAM aims to become a free, parametric CAM solution for 3-axis CNC mills closely integrating with CadQuery.

Za-boom!

Shoutbox (Add)

The need to be observed and understood was once satisfied by God. Now we can implement the same functionality with data-mining algorithms.

-- Raekkeri @ 2022-09-12T07:07:30Z

---

I imagine this can break in so many ways.

-- voneiden @ 2022-07-07T19:32:28Z

---

cq-cam's Issues

Drill and Surface 3D Refactoring

• Drill and Surface3D are classes but profile and pocket are method. Should we be consistent?
• There is an Operation class in base_operation and an Operation in fluent.
• Remove dataclass

Helical plunging

#25 enables implementing automatic helical plunging

Pip release v.0.2.0

[BUG] Toolpath generation

I just checked the state of the code for the changes that I did so far and I noticed a couple of bugs.
Toolpath generation introduces:

• an additional G1 command that produces a diagonal movement that shouldn't be there

G1 X90.05 Y42.55 Z-0.25 F300
G1 X32.78 Y33.526 Z-0.25 F300
G0 X82.85 Y42.55 Z75

• an extra movement before moving between adjacent wires adding unnecessary work

G1 X85.25 Y37.75 Z-0.25 F300
G1 X82.85 Y37.75 Z-0.25 F300
G0 X82.85 Y37.75 Z75
G0 X86.45 Y38.95 Z75
G0 X86.45 Y38.95 Z5

• tiny movements (probably to due to rounding errors)

G1 X62 Y35.3 Z-0.25 F300
G1 X62 Y33.8 Z-0.25 F300
G1 X61.999 Y33.75 Z-0.25 F300
G1 X82.85 Y33.75 Z-0.25 F300

Invalid G3 command in unstable branch

jmwright reported following gcode was generated

G0X35.8Y0Z3
F3G1Z0
G3I-35.8
G0Z3

I'll hazard a guess that the current implementation incorrectly optimizes away X & Y coordinates for a full circle G2/G3 command. However as far as I remember it is handled correctly in in fluent-experiments branch.

References?

I saw https://cq-cam.readthedocs.io/en/latest/algorithms.html wasn't written yet, but I was wondering if maybe your readme could list some reading materials for folks who want to get up to speed in this space and possibly help. CAM toolpath generation seems to mostly be proprietary research and code and it's remarkably hard to find any documentation on techniques, so I'm curious if you've been figuring it out on your own or if there are books or other resources you could recommend.

Gcode Overhaul

• Remove print_modal and update tests
• Simplify print_feed and update tests
• Simplify xyz_gcode and update tests
• Simplify ijk_gcode and update tests
• Remove command.start from code. Initialize start parameter in router.py
• Replace xyz_gcode() and ijk_gcode() with XYZ() and IJK() from address.py
• Remove to_gcode from Commands
• Cleanup class signatures in command.py

Fluent interface

Implement a cadquery style fluent interface and possibly get rid of dataclasses.

Auto-avoid

Suppose it should be possible to utilize the workplane geometry to just determine the avoid areas for pocketing without the need to manually define them.

Improve edge based visualization

ocp-vscode works only with edge based rendering, but unlike cq-editor it supports colours. Improve edge based rending in such a way that we can output coloured edges and possibly some kind of arrow shape too to indicate direction.

Is the project still active?

Hello there,

I have recently started using cq_cam and I am quite enjoying and I would love to help it develop further.
I have already fixed a bug that I found locally but documentation is lacking so I am not sure if the way I do it is the best. If you are willing to walk me through the code I am happy to update the documentation and fix any bugs that I find

Best wishes,
John

Visualize job plane information

Contour pocketing horizontal routing aka "keep tool down"

Currently the naive approach is to do a rapid retract, reposition and plunge onto the next contour.

Implementing some logic that would allow safely cutting from one contour to the next would save significant machine time.

Post-processor and optimizer (Command Refactor - Part 3)

• Modify __str__() of commands to print all the parameter that they hold instead of printing valid gcode and update tests
• Move CommandVector to address.py and rename to AddressVector
• Introduce post_processor and optimizer classes
• Optimizer methods:
  • remove_any_axis()
  • remove_optional_axis()
  • remove_modal()
  • remove_feed()
  • add_space()
• Optimizer tests
• Post-processor methods:
  • rapid()
  • line()
  • arc()
  • home_position()
  • safety_block()
  • start_sequence()
  • stop_sequence()
  • program_pause()
  • tool_change()
  • header()
  • footer()
• Post-processor tests:
• Implement to_gcode() in post_processor and update tests

Logging system

logging module should be standardized

• configurable log level to job?
• errors: fatal problems
• warnings: when things don't add up, like empty output from operation
• info: stats like processing duration
• debug: noise that regular user is not interested in

Implement Drill

Experiment with using OCCT in toolpath generation

As per #1 clipping works out great using OCCT. To fully utilize the advantage of using wires and edges (to preserve arcs), one needs to be able to get segments of wires/edges between two known points. Currently there's a limitation with OCP to achieve this using GeomLib_Tool.Parameter (see CadQuery/OCP#89).

BRep_Tool.Parameter does not appear to work for the purpose, as it does not seem to consider tolerance.

Support bsplines

Encountered finally bsplines when trying to pocket engraved text. This can result in interesting GeomTypes like OffsetCurve (with basis curve of TrimmedCurve with basis curve of BSplineCurve). The current pyclipper implementation would need to interpolate these bsplines in a similar manner to arcs.

Also the gcode needs interpolation in either case.

Spindle settings

On job and operation level, such as spindle speed. See #18 (reply in thread)

Note: I don't have the hardware to test this out.

[BUG] Duplicate commands produced by routers.py

As I am simplifying the to_gcode() to always print the modal, feed rate, XYZ, and IJK commands I noticed that there are new duplicate G0 and G1 commands being produced that were previously being hidden by the logic of print_modal().

Here is an examples of failing test outputs:

E           (Job - Feedrate: 200 - Unit: Unit.METRIC)
E           G90 G54 G64 G50 G17 G94
E           G49 G40 G80
E           G21
E           G30
E           M3
E           (Job - Surface 3D)
E           G0 Z10
E           G0 X-1.5Y1
E           G0 Z1
E           G1 Z0
E         + G1 
E           G1 X-1
E           G1 X-0.5
E           G1 X0
E           G1 X0.5
E           G1 X1
E           G1 X1.5
E         + G1 
E           G1 Y0.5
E           G1 Y0.2
E         + G1 
E           G1 X1
E           G1 X0.5
E           G1 X0
E           G1 X-0.5
E           G1 X-1
E           G1 X-1.5
E         + G1 
E           G1 Y-0.3
E           G1 Y-0.6
E         + G1 
E           G1 X-1
E           G1 X-0.5
E           G1 X0
E           G1 X0.5
E           G1 X1
E           G1 X1.5
E         + G1 
E           G1 Y-1.1
E           G1 Y-1.4
E         + G1 
E           G1 X1
E           G1 X0.5
E           G1 X0
E           G1 X-0.5
E           G1 X-1
E           G1 X-1.5
E           G90 G54 G64 G50 G17 G94
E           G49 G40 G80
E           G21
E           G30
E           M5

E           (Job - Feedrate: 200 - Unit: Unit.METRIC)
E           G90 G54 G64 G50 G17 G94
E           G49 G40 G80
E           G21
E           G30
E           M3
E           (Job - Profile)
E           G0 Z10
E           G0 X2.5Y-2.5
E           G0 Z1
E           G1 Z-1 F200
E           G1 X-2.5 F200
E           G1 Y2.5 F200
E           G1 X2.5 F200
E           G1 Y-2.5 F200
E           G0 Z10
E         + G0 
E           G0 Z1
E           G1 Z-2 F200
E           G1 X-2.5 F200
E           G1 Y2.5 F200
E           G1 X2.5 F200
E           G1 Y-2.5 F200
E           G90 G54 G64 G50 G17 G94
E           G49 G40 G80
E           G21
E           G30
E           M5

Refactorings

• There are a couple of NumPy deprecation warning when running pytestdue to typing. Should we do anything about them?
• Are there any other class attributes to be converted to class properties (like you did for tool_radius)?
• Should i change update_tool to use shallow copies for self = self._add_operation("Tool Change", commands)?
• Remove unitest usages and refactor to pytest

Engraving algorithms - Voronois and medials

One way to approach engraving with a v-bit is to generate voronoi diagrams and medials to determine the path one should take in order to engrave a shape.

One option: https://trimsh.org/trimesh.path.polygons.html#trimesh.path.polygons.medial_axis

FreeCAD uses a custom version of OpenVoronoi AFAIK. The original OpenVoronoi is a no go as it is windows only AFAIK. Backporting FreeCADs implementation would probably be too much work.

Read more @ http://www.anderswallin.net/category/cnc/cam/openvoronoi/

Profile Operation Dressups

• Overcut
  • Dogbone
  • T-bone Long
  • T-bone Short
  • T-bone Vertical
  • T-bone Horizontal
• Dragknife

Suggestion: clipping faces with OCCT

You could consider clipping faces using OCCT instead of clipper (and thus operate on a more accurate representation). Clipping wires does not work, but planar faces do work (see cq.Sketch for inspiration). You'll be likely only dealing with closed wire so there is a 1-1 correspondence between faces and wires.

Offsetting Bugs

Here is the original problem as I encountered it:

• You start with a workplane and you create a shape.
• You translate and rotate that shape.
• You then create a subsequent shape from the previous workplane
• If you execute offset2D on both of these solids you will get a correct offset for the first shape but the second will be offset and rotated by the original offset and rotation (see below)

If I apply my fix then everything goes back into the correct place:

The fundamental problem with my solution is that it depend on the centers not changing, which is not always the case. Some designs (see below) can create intersections when you create and an offset and those intersections need to be trimmed (hence changing the center of the wire).

When my fix is applied in the context of cq_cam then offsets that cause intersection and change the original shape will be moved into the previous center (see below).

There are however design that can still cause the issue with cq-cam:

So we need a robust way to detect when intersections happen and take that into account when correcting the offset.

Introduce Spline commands

routers.py should use SplineCommand(G5) for splines and offsets
The post-processor should convert the spline command into G0/G1 commands for controllers that don't support them

Align types with gcode spec

• Missing module-level documentation (see comments below)
• spindle -> speed
• common.py -> groups.py
• Create address.py with XYZ and IJK classes move print_xyz() and print_ijk()
• GCodeEnum -> GCodeAddress
• GCodeEnum.to_gcode() -> GCodeEnum.__repr__() and GCodeEnum._str_()
• Remove precision parameter and choose precision based on selected Unit address
• Introduce class FeedRate(GCodeEnum) and create print_feed()

[BUG] Pocket clipper does not generate correct paths for circles

Implement final pass contours

Precision default based on job unit

Possibly 3 for imperial (0.001" / 0.0254 mm) and 2 for metric (0.01 mm / 0.0003").

Add pyclipper as Dependency

I'm sure you're already aware, but setup.py and the conda environment files seem to be missing pyclipper, and so the import of cq_cam throws a missing module error.

visualize_job does not work unless you use cq_editor

I have recently switched from cq_editor to ocp_cad_viewer extension for vs code. Running visualize_job does not work but visualize_job_as_edges does

Write docs for first release

Precision in edge interpolation and offsetting

Currently hardcoded, should respect Job.precision

Operation feedrate overrides

See #18 (reply in thread)

Precision in gcode output

Currently hardcoded, should respect Job.precision. Relates to #44 and depends on #40

Refactor type hints

• Optional[T] and Union[T, None] ->T | None
• Tuple[] -> tuple[]
• List[] -> list[]
• Dict[] -> dict[]
• Add type hints to other places as well

Introduce canned cycles to drill operation

The drill operation should use canned cycles and not G0/G1 command.
The post-processor should convert the canned cycle into G0/G1 commands for gcode controller that don't support them

Implement avoid

`routers.py` refactoring and simplification

• #56
• Add spline() to post-processor along with G0/G1 conversion logic
• #55
• Add drill() to post-processor along with G0/G1 conversion logic
• Add documentation
• Investigate effect of shift_edges()

Experiment with optimizer to detect arcs from linear segments

Been there done that before but now that it looks like pyclipper is the defacto way to go, it could be interesting to have an optimizer which attempts to detect arcs (within a certain tolerance) from linear segments so that we can actually have G2 and G3 commands.

Performance is a concern, especially for large programs, so this should be fast and some perf testing should also be done to see if it's viable.