Path.Area: Welcome, to the new era!

[sliptonic]

Sounds right to me.

I've added 'feedrate' and 'feedrate_v' parameter to Path.fromShapes. Please sync with my branch. 'feedrate_v', if non-zero, is for vertical only movement by default. For a cone shape thing like the picture below, you can get the same thing by setting 'tolerance' >= stepdown.
Screenshot from 2017-04-05 14-14-10.png
I also added 'verbose' parameter to fromShapes, which defaults to 'true'. This will cause each motion GCode to include complete coordinate and feed rate information regardless of the current state, so you can easily get the full information from the GCode shown in the status bar when preselecting any Path in 3D view.

BTW, could you please send me some sample lathe GCode from Heeks or other CAM. From the lathe milling videos I saw, it seems that those pattern are not just simple straight lines.

Great! I'll play with it as soon as I can.

re:lathe paths. I can't help. HeeksCNC didn't do any lathe operations at all. In fact, there's virtually no open source software that does. GCodeTools for inkscape can do a simple path and the linuxcnc has its own conversational system that can do basic things. Hopefully users can provide some examples.

[realthunder]

re:lathe paths. I can't help. HeeksCNC didn't do any lathe operations at all. In fact, there's virtually no open source software that does. GCodeTools for inkscape can do a simple path and the linuxcnc has its own conversational system that can do basic things. Hopefully users can provide some examples.

For some videos I watched, e.g. https://youtu.be/lcGHtI9Lql4. It seems to be a unidirectional contour operation, something like the following. Again, the rapid move is tricky.

Screenshot from 2017-04-06 17-32-28.png (69.59 KiB) Viewed 2294 times

[chrisb]

It seems to be a unidirectional contour operation

Unidirectional paths are common on a lathe because most turning steels have only one cutting side.

[realthunder]

New commits to my PathArea branch. Added a parameter 'direction' in Path.fromShapes to control the open path direction. 0=None, 1=XPositive, 2=XNegative, 3=YPositive, 4=YNegative, 5=ZPositive, 6=ZNegative. XPositive means the starting vertex X coordinate is less than ending vertex, i.e. towards the X positive direction. With this control, the chess piece tool path now has the correct rapid move,

Screenshot from 2017-04-08 12-38-37.png (63.05 KiB) Viewed 2205 times

And also, proudly presents the newly added projection capability of Path.Area. You can set 'Project' = true (capitalized 'P') in Path.Area.setParams, or 'project'=true (small case 'p') in Path.Area.makeSections to project the outline of the added shapes onto each section plane. Unlike normal section, which does a full section operation for each slice because Area can't know in advance if there is slop involved, projection is done only once and copied into each section slices, so it is fast to use. I am using a similar but different algorithm than TechDraw. It should be much more efficient for complex shapes because of the powerful boost.geometry and ClipperLib I used. Let's hope it works well, too.

Screenshot from 2017-04-08 15-35-01.png (20.13 KiB) Viewed 2205 times

[bill]

Now that is one "Proper Projection" that should finally alleviate problems like this!

PartialContour.png (23.47 KiB) Viewed 2181 times

Note, you can see from the (white) Machining Box, that only about one quarter of the path is generated from the CONTOUR Operation. It chokes probably on the non-planar top surface. Whereas, the PROFILE Operation projected off the bottom surface completes sucessfully (indicated by the complete circular paths).

Switching gears ...

The contour lathe pass is pretty cool! But should not start so early. Attacking those small radii so early is a bit premature. Small radii (in general) are the arch-nemesis of a lathe's single point cutting tool due to the complex geometries of lathe machining; much more so than milling or grinding as noted a few posts back.
Not sure, but I think it is more preferable to start the rough cut as below...

lathepass.png (261.05 KiB) Viewed 2181 times

... then, finish pass with contour pass(es).

And another subject...

On another note:

For the time being limit our tool shape= "a line", width= "0", workangle-orientation="90", workheight-orientation="center"
I would like to suggest a "selectable" Feed-Direction: +Z --> -Z or -Z --> +Z.
This would facilitate left and right under-cuts of shoulders, etc.; more discussion is needed here; this recorded as note for future dev.

New commits to my PathArea branch. Added a parameter 'direction' in Path.fromShapes to control the open path direction. 0=None, 1=XPositive, 2=XNegative, 3=YPositive, 4=YNegative, 5=ZPositive, 6=ZNegative. XPositive means the starting vertex X coordinate is less than ending vertex, i.e. towards the X positive direction. With this control, the chess piece tool path now has the correct rapid move,

Even though the Y-axes is not accounted for here...

Lathe coordinate system.JPG (45.87 KiB) Viewed 2181 times

...I would like accounting and control in order to set tool height via Y.

I was taught to cut below the 90/270degree tangent to mitigate harmonics and chatter and those awful-squealling-noises often associated with lathe operations, etc.. (you will tend to get better chips as a bonus)

Thank You!

One last note: Would it be possible that everyone could agree to setting all the "DEFAULT" step-overs to 50 percent; it might be a safer starting point.

[chrisb]

One last note: Would it be possible that everyone could agree to setting all the "DEFAULT" step-overs to 50 percent; it might be a safer starting point.

+1

[realthunder]

Here are the things that I'm still struggling with or confused about. Any help is appreciated

Okay, final commit to complete all your requests. I've added 'Line' pocket mode. Please try it. To get unidirectional line pattern, you need to pass sort_mode=0 to Path.fromShapes, and use 'direction' to control the line direction. Please let me the overall results of these batch of commits before I submit them as PR.

Adding straight line pattern is very easy actually. However, I've made this an ambitious first step towards FC's very own 3D printing slicer (Path.Slicer maybe?). The following additional parameters are not that relevant to CNC, but for 3D printing. I've added 'Grid' and 'Triangle' pattern, which are just variations of the line pattern. Also 'angle_shift' and 'shift' parameter to get 3D infill pattern, inspired by CuraEngine. I can't verify the current generated pattern is good or not because the lack of proper visualization for 3D printing path. The current 'ZigZag' pattern from libarea is not suitable for 3D printing, because it has a few overlaps. The next big step is to invent my own ZigZag without overlap, which is no easy task.

All these being said, the follow-ups will have to wait till I get back to 3D printing. I currently got all my parts printed, and my printer has been collecting dust for months already.

[ian.rees]

parameter 'direction' in Path.fromShapes to control the open path direction. 0=None, 1=XPositive, 2=XNegative, 3=YPositive, 4=YNegative, 5=ZPositive, 6=ZNegative.

FreeCAD has 3D vector type, PropertyVector, wouldn't it be better to use for this vs a magic enumeration? There is also an enumeration property, but it's obviously less general. (disclaimer, I haven't actually looked at the code, just the thread so far)

[realthunder]

FreeCAD has 3D vector type, PropertyVector, wouldn't it be better to use for this vs a magic enumeration? There is also an enumeration property, but it's obviously less general. (disclaimer, I haven't actually looked at the code, just the thread so far)

By looking at those path in the picture I included, with those arcs and all, I don't think one can use a vector to specify the desired the direction. As for the enumeration, the numerical I specified is for python script object. No property involved. It is possible to support string input for enumeration, but that requires more effort than I think is worth it. When the same parameter is exposed as property in FeatureArea, yes, I am using PropertyEnum.

[ian.rees]

Sorry, I don't mean to nit pick. I'm just not understanding a situation where a vector wouldn't specify a unique direction, but a map from magic numbers to directions would (and I don't like C style enums creating meaning ).

A more Pythonic solution to the algorithm only handling vectors that are "on axis" is to accept a vector (perhaps of 3 ints), but throw if it's not in a direction that the algorithm can handle. That way, if someone extends the algorithm later to accept a wider range of directions, the interface doesn't need to change.

Where would it be more work to use the "XPositive" strings directly as you mentioned? In other words, there's nothing "positve Y"-ish about 3, so the code must be branching depending on literal values somewhere. IIRC, the data storage behind PropertyEnum can take care of the translation back-and-forth between ints and strings if it's a C++ domain issue.