0% found this document useful (0 votes)
30 views5 pages

Pycam Algo

Uploaded by

rykennelly1
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
30 views5 pages

Pycam Algo

Uploaded by

rykennelly1
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

Push->Follow toolpath strategy implementation | sense.fab http://web.archive.org/web/20150509165403/http://fab....

The Wayback Machine - http://web.archive.org/web/20150509165403/http://fab.senselab.org/node/43

sense.fab
// produktionsmittel für alle. reprap, open hardware, open source cnc.

Blog PyCAM Notizen Imprint About us Bauanleitungen Impressum

Über uns

Raspberry Pi Gehäuse verfügbar


Auf arbofaktur.de bieten wir ein Raspberry Pi Gehäuse aus unserer Werkstatt an. Die Erstellung konnten wir komplett mit
freier Software umsetzen: Design in OpenSCAD (in Debian und den freien Radeon-Treibern), Werkzeupfad-Generierung in
PyCAM, verfahren wurde mit LinuxCNC.

Language
German

Tags:
Raspberry Pi
Raspberry Pi Gehäuse
Read more

Home » Blogs » lars's blog

Push->Follow toolpath strategy implementation


Submitted by lars on Sat, 09/25/2010 - 14:23

This article discusses the new Push->Follow toolpath strategy of PyCAM that is supposed to replace the ContourCutter
toolpath strategy. The reasons for this switch are discussed as well as the implementation details of the new code.

The new toolpath generation strategy will be available in the next release of PyCAM (v0.3.1) - probably in the beginning of
October 2010. Users of the bleeding edge subversion code can test it right now.

Table of contents

1. Current state of the ContourCutter


2. Overview of the Push->Fowllow strategy
3. Algorithm
1. Find the outer collision line of a triangle
2. Verify potential outer collision lines
4. Conclusions

Current state of the ContourCutter

1 of 5 6/22/24, 11:09
Push->Follow toolpath strategy implementation | sense.fab http://web.archive.org/web/20150509165403/http://fab....

The ContourCutter of PyCAM is supposed to be used for cutting around a solid 3D model in multiple slices. Its
implementation is based on a grid collision detection. The resulting collisions are assembled into polygons that surround all
pieces of a slice of the model.

This implementation has some weaknesses:

• inaccurate corner collisions due to a fixed grid


• problems with composing the polygons if the bounding box does not cover the complete solid model
• problems with separate parts of the solid model that are very close together

Some of these problems are illustrated in the screenshot below (using the ContourCutter with the example solid model
SampleScene.stl that is part of PyCAM). See also my previous blog post.
[inline:contour_problems.png]

Overview of the Push->Follow strategy


The new Push->Follow strategy is based on the assumption that the cutter follows the direction of the edges or the waterline
of a triangle when moving along. Basically it will calculate the potential lines of collision of the cutter with each single triangle.
These potential collision lines form a ring around the model.

The following picture illustrates this ring of collision lines (red color) for a simple model:
[inline:pushfollow_waterline.png]

The second step is the shifting of the collision lines towards the outside of the model. The distance is computed by finding
the closest non-colliding cutter location next to this triangle. The potential line of collision is shifted in parallel towards this
point. The following picture shows these shifted lines of collision for a cube. The distance to the surface of the model is equal
to the cutter radius (at least for the cylindrical cutter).

[inline:pushfollow_waterline_with_offset.png]

In the picture above you can see that the shifted lines are not connected at the corners. For these convex corners we need to
extend the shifted lines until the point of collision with the adjacent shifted line (and vice versa). This extension can also be
implemented as an arc connecting the two adjacent lines. But for the sake of simplicity we just extend the straight lines for
now. For concave corners the shifted lines need to be shortened. A connecting arc would not be useful here.
[inline:corners.png]

The following picture shows the above example with extended shifted lines:
[inline:pushfollow_waterline_with_offset_and_extension.png]

As the last step the resulting extended shifted lines are checked for collisions. Only non-colliding parts of these lines are
added as cutting paths to the resulting toolpath.

The following picture shows the resulting toolpath for a more complex example (again: SampleScene.stl).
[inline:pushfollow_multiple_slices.png]

Algorithm
The algorithm does the following:

1. calculate the z levels of the slices of the model


2. go through all triangles and check if they are part of the set of outer collision triangles; the result is a ring of collision lines
around the model at the given level
3. calculate the shifted lines for all collision lines
4. extend/shorten all shifted lines based on intersections with their neighbours
5. check all shifted lines for collisions and add all non-colliding parts to the toolpath

2 of 5 6/22/24, 11:09
Push->Follow toolpath strategy implementation | sense.fab http://web.archive.org/web/20150509165403/http://fab....

The above algorithm is basically quite simple. The only tricky part is step (2) - gathering the suitable collision lines of all
triangles. Thus the following description will focus on this part of the code.

Find the outer collision lines of a triangle


Every triangle will be processed. Based on its position and its orientation it will fall into one of the following categories:

• case 1a: the triangle is completely below the current cutter level
• case 1b: all vertices of the triangle are on the same xy plane (the triangle is horizontal)
• case 2a: the projection of the triangle onto the xy plane results in a line (the triangle is vertical)
• case 2b: one or two vertices of the triangle are above the cutter level; the triangle's normal points upwards
• case 3a: two vertices of the triangle are above the cutter level; the triangle's normal points downwards
• case 3b: one vertex of the triangle is above the cutter level; the triangle's normal points downwards
• case 4: the complete triangle is above the cutter level

Now I will discuss all of these cases and how they are handled.

Case 1a
[inline:case1a.png]
The triangle does not affect the toolpath since it is completely below the lowest point of the cutter.

Case 1b
[inline:case1b.png]
The triangle is parallel to the xy plane. We assume that the solid model contains only parts with a non-zero thickness thus
there will be other (non-parallel) triangles that share the edges of the flat triangle. These other triangles will be sufficient for
calculating the toolpath. Thus we ignore flat triangles.

Case 2a
[inline:case2a.png]
The triangle's orientation is orthogonal to the xy plane. We pick the longest line of projection down on the xy plane.

Case 2b
[inline:case2b.png]
The triangle's normal points upward. We can use the waterline of the triangle at the z level of the cutter.

Case 3a
[inline:case3a.png]
Take the two points of the waterline and the xy plane projection of the two vertices that are above the cutter level. Combine
all pairs of these four points and choose only the pairs that are to the left of the remaining two points. The distinction between
left (outside of the model) and right (inside the model) is done by vector operations involving the normal vector of the xy
plane.

The result can be one, two or three pairs of points. These resulting lines are potential outside collision lines.

Case 3b
[inline:case3b.png]
Take the two points of the waterline and the vertex above the cutter level. Combine pairs of these three points and pick the
combinations where the other point is on the right side (inside the model) of the line.
This can result in one or two potential outer collision lines.

Case 4
[inline:case4.png]
Combine pairs of the three vertices of the triangle and pick the combinations where the remaining vertex is on the right side

3 of 5 6/22/24, 11:09
Push->Follow toolpath strategy implementation | sense.fab http://web.archive.org/web/20150509165403/http://fab....

(inside the model) of the line.


This can result in one or two potential outer collision lines.

Verify the potential collision lines


Check for each potential collision line of the triangle, if the contact point of a collision test starting at the triangle surface is on
the potential collision line. Beware: this comparison uses the projection of this contact point onto the xy plane through the
current cutter level.

This process can result in multiple collision lines, if similar triangles are on top of each other. This is no problem, since the
later processing of these collision lines will filter these duplicates.

Conclusions
The new algorithm should be stable. But I am very sure that it still contains a handful of bugs. Especially situations that could
mess around with the "neighbour" detection of the collision lines are likely to cause problems. Thus some tests with models
that contain multiple layers of similar (but not identical) triangles would be useful to identify these potential issues.

Additionally the process of finding the next outer collision of a potential line of collision is not perfect for now. Only five points
on the line are currently used as potential starting points. That means that we can miss a potential line of collision for big
triangles (compared to the cutter radius). Improving this test will probably hurt performance, but it would obviously be quite
useful.

In general debugging of the new code should be quite straightforward. Enabling the visualization debug switches (e.g.
showing the triangle's id in the 3D view) or the three debug switches for disabling the collision line shifting, the line extension
and the final collision detection proved to be very useful.

Any comments or ideas regarding this new toolpath generation algorithm for PyCAM are welcome!

Language
English

Tags:
pycam
toolpath strategy
lars's blog Log in to post comments

Languages
• English
• Deutsch

PyCAM activities
• Geo posted a comment on discussion Help
• Kevin Murphy posted a comment on discussion Help
• Lars posted a comment on discussion Open Discussion
• AdrianS posted a comment on discussion Open Discussion
• AdrianS posted a comment on discussion Help

More

4 of 5 6/22/24, 11:09
Push->Follow toolpath strategy implementation | sense.fab http://web.archive.org/web/20150509165403/http://fab....

Tag cloud
pycam reprap mendel Bildschirmfotos lasercut howto tutorial
bauanleitung Objekte Werkstatt X-Achse emc More tags

Site License
This Work, sense.fab, by Sense.Lab e.V. is licensed under a Creative Commons Attribution-Share Alike license.

5 of 5 6/22/24, 11:09

You might also like