Path.Area: Welcome, to the new era!

Here's the place for discussion related to CAM/CNC and the development of the Path module.
User avatar
sliptonic
Posts: 1560
Joined: Tue Oct 25, 2011 10:46 pm

Re: Path.Area: Welcome, to the new era!

Postby sliptonic » Wed Apr 05, 2017 5:51 pm

realthunder wrote:
sliptonic wrote: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
Posts: 1172
Joined: Tue Jan 03, 2017 10:55 am

Re: Path.Area: Welcome, to the new era!

Postby realthunder » Thu Apr 06, 2017 9:37 am

sliptonic wrote: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
Screenshot from 2017-04-06 17-32-28.png (69.59 KiB) Viewed 1198 times
Try Assembly3 (latest version 0.10.2) along with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
chrisb
Posts: 18218
Joined: Tue Mar 17, 2015 9:14 am

Re: Path.Area: Welcome, to the new era!

Postby chrisb » Fri Apr 07, 2017 12:09 am

realthunder wrote: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
Posts: 1172
Joined: Tue Jan 03, 2017 10:55 am

Re: Path.Area: Welcome, to the new era!

Postby realthunder » Sat Apr 08, 2017 7:38 am

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
Screenshot from 2017-04-08 12-38-37.png (63.05 KiB) Viewed 1109 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
Screenshot from 2017-04-08 15-35-01.png (20.13 KiB) Viewed 1109 times
Try Assembly3 (latest version 0.10.2) along with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
User avatar
bill
Posts: 376
Joined: Fri Jan 09, 2015 9:25 pm

Re: Path.Area: Welcome, to the new era!

Postby bill » Sat Apr 08, 2017 3:40 pm

Now that is one "Proper Projection" that should finally alleviate problems like this!
PartialContour.png
PartialContour.png (23.47 KiB) Viewed 1085 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
lathepass.png (261.05 KiB) Viewed 1085 times
... then, finish pass with contour pass(es).

And another subject...

On another note:
bill wrote: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.
realthunder wrote: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
Lathe coordinate system.JPG (45.87 KiB) Viewed 1085 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
Posts: 18218
Joined: Tue Mar 17, 2015 9:14 am

Re: Path.Area: Welcome, to the new era!

Postby chrisb » Sat Apr 08, 2017 9:33 pm

bill wrote: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
Posts: 1172
Joined: Tue Jan 03, 2017 10:55 am

Re: Path.Area: Welcome, to the new era!

Postby realthunder » Sun Apr 09, 2017 7:05 pm

sliptonic wrote: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.
Try Assembly3 (latest version 0.10.2) along with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
ian.rees
Posts: 696
Joined: Sun Jun 15, 2014 3:28 am
Contact:

Re: Path.Area: Welcome, to the new era!

Postby ian.rees » Mon Apr 10, 2017 6:42 am

realthunder wrote: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
Posts: 1172
Joined: Tue Jan 03, 2017 10:55 am

Re: Path.Area: Welcome, to the new era!

Postby realthunder » Mon Apr 10, 2017 6:51 am

ian.rees wrote: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.
Try Assembly3 (latest version 0.10.2) along with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
ian.rees
Posts: 696
Joined: Sun Jun 15, 2014 3:28 am
Contact:

Re: Path.Area: Welcome, to the new era!

Postby ian.rees » Mon Apr 10, 2017 7:19 pm

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.