Path.Area: Welcome, to the new era!

Here's the place for discussion related to CAM/CNC and the development of the Path module.
realthunder
Posts: 104
Joined: Tue Jan 03, 2017 10:55 am

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

Postby realthunder » Wed Mar 08, 2017 8:04 pm

sliptonic wrote:A little closer working manually I get this from a boolean cut:
And this looks promising with the Feature area zigzag pocket...

And then apply the PathArea.....Nope.

The trouble you are experiencing is due to the fact that the work plane you use is not on xy plane. I haven't really tested my code with planes other than xy. I'll fix it soon.

BTW, do you know how to get notified by email when someone posted on my own thread? I seem to be only receiving notification if someone quotes my post. I have checked every notification option in settings, but doesn't seem to work. How does everyone else track their own posts?
sliptonic
Posts: 594
Joined: Tue Oct 25, 2011 10:46 pm

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

Postby sliptonic » Wed Mar 08, 2017 9:09 pm

I don't know about the notification question. The old prosilver theme had a 'subscribe' button but I'm not sure if it does what you want. You can switch to that skin in your profile.

I've entered a bug into Mantis for the fact that the Path viewprovider doesn't handle arcs in planes other than XY. see issue #2903
realthunder
Posts: 104
Joined: Tue Jan 03, 2017 10:55 am

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

Postby realthunder » Fri Mar 10, 2017 10:50 am

sliptonic wrote:I don't know about the notification question. The old prosilver theme had a 'subscribe' button but I'm not sure if it does what you want. You can switch to that skin in your profile.

I've entered a bug into Mantis for the fact that the Path viewprovider doesn't handle arcs in planes other than XY. see issue #2903

I've made some fix of Path.Area. The file is in the attachment. You can try it with my latest PathArea branch.

A few notes.

* libarea (Clipper) only works with 2D shape. So in order to get the boolean cut on solid, you have to use section. For your model, one section is enough. However, I am not quit clear what you want to achieve here. A rough maybe? If so, won't you need more sections? Or rather, using offset instead, as shown below? The final path can be clipped (i.e. a common operation) with the workpiece (which Area can't do at the moment yet). See attached offset.FCstd file.
Screenshot from 2017-03-10 18-35-43.png
Screenshot from 2017-03-10 18-35-43.png (350.07 KiB) Viewed 230 times

* In case the section plane is not the default XY plane, you need a few manual steps to get it working. By default, the work plane is determined by the highest planar XY face of all added shapes if there is one. If not, it will pick the first encountered planar face as work plane. The work plane determines how the 3D coordinates are mapped to 2D for libarea to process. There is a setting called Section Mode that controls the section plane. The default mode is to use the current work plane as starting section plane. Before starting, Area will transform the shape so that it aligns the section plane with the XY0 plane. The signess of Stepdown controls the section direction. Positive means downward in transformed Z direction.

* Internally, Area uses OCC cut to implement section (same as Part's section), so you may experience the usual cut failure on tangent planes, i.e. section plane coincides with some face of the added shape. This is why I added Section Tolerance parameter, which introduce a small offset value to the section cut Z height. However, this offset value is directional dependent. Say, you select a work plane of bottom Z face, and has the default positive stepdown. The added tolerance offset will be in the wrong direction. You can experiment this with the model file in the attachment. PS. I discovered this issue because in your originally attached model, your Y axis is pointed downward, suggesting you are selecting the bottom Y face as the workplane, causing reversed section direction. To visualize the current work plane, you can

Code: Select all

Part.show(App.ActiveDocument.FeatureArea.WorkPlane).

* If you want more control on sections, e.g. variable stepdown, you can use Area.makeSections, where you can pass in a list of section heights.

The result,
Screenshot from 2017-03-10 18-20-26.png
Screenshot from 2017-03-10 18-20-26.png (274.9 KiB) Viewed 230 times

The generated Path still won't be showing correctly because of the bug you are firing. Now, can you please send me a simple lathe gcode file? I'll see if I can patch the Path ViewProvider.
Attachments
offset.fcstd
(60.07 KiB) Downloaded 4 times
lathepart1.fcstd
(34.21 KiB) Downloaded 4 times
sliptonic
Posts: 594
Joined: Tue Oct 25, 2011 10:46 pm

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

Postby sliptonic » Fri Mar 10, 2017 3:28 pm

realthunder wrote:However, I am not quit clear what you want to achieve here. A rough maybe? If so, won't you need more sections? Or rather, using offset instead, as shown below?


This is the start of a new type of Path job for lathe operations. This would be a rough turning operation. In a lathe, the work is oriented differently then in a 3 axis milling machine. The coordinate system looks like this:

Image

The work is held in the chuck and spins around the Z axis which runs through the center of the chuck and the tailstock. The tool moves in the XZ plane to remove material from the spinning part. The Y axis is not used.

* In case the section plane is not the default XY plane, you need a few manual steps to get it working. By default, the work plane is determined by the highest planar XY face of all added shapes if there is one. If not, it will pick the first encountered planar face as work plane. The work plane determines how the 3D coordinates are mapped to 2D for libarea to process. There is a setting called Section Mode that controls the section plane. The default mode is to use the current work plane as starting section plane. Before starting, Area will transform the shape so that it aligns the section plane with the XY0 plane. The signess of Stepdown controls the section direction. Positive means downward in transformed Z direction.


If the transform is happening for internal calculation, I guess that's fine, but I don't want to translate the resulting moves into XY0. In the case of the pawn, the part is already oriented correctly for a lathe operation.

* Internally, Area uses OCC cut to implement section (same as Part's section), so you may experience the usual cut failure on tangent planes, i.e. section plane coincides with some face of the added shape. This is why I added Section Tolerance parameter, which introduce a small offset value to the section cut Z height. However, this offset value is directional dependent. Say, you select a work plane of bottom Z face, and has the default positive stepdown. The added tolerance offset will be in the wrong direction. You can experiment this with the model file in the attachment. PS. I discovered this issue because in your originally attached model, your Y axis is pointed downward, suggesting you are selecting the bottom Y face as the workplane, causing reversed section direction. To visualize the current work plane, you can

Code: Select all

Part.show(App.ActiveDocument.FeatureArea.WorkPlane).

* If you want more control on sections, e.g. variable stepdown, you can use Area.makeSections, where you can pass in a list of section heights.

Good to know.

The result,
Screenshot from 2017-03-10 18-20-26.png
The generated Path still won't be showing correctly because of the bug you are firing. Now, can you please send me a simple lathe gcode file? I'll see if I can patch the Path ViewProvider.


This looks better although the clearing pattern should run parallel to the Z axis not at a 45 degree angle.
I'm attaching a gcode lathe file from another program. It's a similar pawn but is NOT our pawn. I'll verify this gcode through linuxcnc later today and upload a picture of the backplot to show how it should render in the view provider. This is a tiny file but I had to tar/gzip it because nc file extensions are invalid here.
Attachments
PAWN.NC.tar.gz
(878 Bytes) Downloaded 3 times
sliptonic
Posts: 594
Joined: Tue Oct 25, 2011 10:46 pm

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

Postby sliptonic » Fri Mar 10, 2017 6:09 pm

LinuxCNC doesn't like that sample file but has its own lathe-pawn.ngc file (attached). In linuxcnc, it looks like this:
screenshot.png
screenshot.png (89.38 KiB) Viewed 199 times


And an oddly satisfying gif...

http://i.imgur.com/qzRUpWc.gif
Attachments
lathe_pawn.ngc.tar.gz
(923 Bytes) Downloaded 4 times
realthunder
Posts: 104
Joined: Tue Jan 03, 2017 10:55 am

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

Postby realthunder » Sun Mar 12, 2017 3:31 am

More fix to Path.Area, and I've patched Path ViewProvider to support plane select. See the attachment. you will need to sync with my PathArea branch to try it. Is the path generated suitable for lathe? The order of path may be wrong, because the sorting algorithm still assumes a 3 axis machine. Any software recommended for GCode animation that supports plane select? I'll see if I can add some visual cue for path order.

I tried to render the last file you attached, it seems a bit different from what LinuxCNC is showing. Please verify.

It seems that lathe doesn't use zigzag pattern, does it? Is it necessary to add a new pattern for lathe? And also, with the addition of plane select, and all kinds of different type of machines, rapid move path generation becomes somewhat complicated. How is it done in other software?
Screenshot from 2017-03-12 11-21-39.png
Screenshot from 2017-03-12 11-21-39.png (275.39 KiB) Viewed 149 times
Attachments
lathepart1.fcstd
(28.09 KiB) Downloaded 4 times
mlampert
Posts: 279
Joined: Fri Sep 16, 2016 9:28 pm

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

Postby mlampert » Sun Mar 12, 2017 3:50 am

realthunder wrote:... and I've patched Path ViewProvider to support plane select....

Can you move those changes into a separate branch and create a PR for it?
realthunder
Posts: 104
Joined: Tue Jan 03, 2017 10:55 am

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

Postby realthunder » Sun Mar 12, 2017 8:50 am

mlampert wrote:Can you move those changes into a separate branch and create a PR for it?

Yes, sure. I intended to.
sliptonic
Posts: 594
Joined: Tue Oct 25, 2011 10:46 pm

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

Postby sliptonic » Sun Mar 12, 2017 2:22 pm

realthunder wrote:More fix to Path.Area, and I've patched Path ViewProvider to support plane select. See the attachment. you will need to sync with my PathArea branch to try it. Is the path generated suitable for lathe? The order of path may be wrong, because the sorting algorithm still assumes a 3 axis machine. Any software recommended for GCode animation that supports plane select? I'll see if I can add some visual cue for path order.

I tried to render the last file you attached, it seems a bit different from what LinuxCNC is showing. Please verify.

It seems that lathe doesn't use zigzag pattern, does it? Is it necessary to add a new pattern for lathe? And also, with the addition of plane select, and all kinds of different type of machines, rapid move path generation becomes somewhat complicated. How is it done in other software?
Screenshot from 2017-03-12 11-21-39.png


This looks really good! I'll build and test with your branch as soon as I can. I don't have much experience at programming a lathe but I think it needs to have a 'unidirectional' pattern. So it feeds in only one direction to cut, then rapids out to a safe point, rapids back to the beginning, and repeats.
User avatar
bill
Posts: 155
Joined: Fri Jan 09, 2015 9:25 pm

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

Postby bill » Sun Mar 12, 2017 6:15 pm

realthunder wrote:It seems that lathe doesn't use zigzag pattern, does it?

The intent is to maintain a relatively-constant feed rate for optimum cutting/chip generation. Plunging on the X-axis would defeat this. Cutting parallel to Z is typical; however there are always exceptions (e.g., cut-off, facing, etc.). But at this stage, I think we need to address general/predominat circumstances like slip* mentions below!

sliptonic wrote:This looks really good! I'll build and test with your branch as soon as I can. I don't have much experience at programming a lathe but I think it needs to have a 'unidirectional' pattern. So it feeds in only one direction to cut, then rapids out to a safe point, rapids back to the beginning, and repeats.

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.