3D Surface - Face Selection (New feature) [Merged]

[Russ4262]

Morning Gauthier,

... I found little bugs in the new PathSurface.py code. ...
In addition, the G0 GCode does not have to have feedrate parameter, like I can see in lines 8,9 and 11 of PathSurface output...
Perhaps will it be fine to correct this. ...

Great work! I have added the gcode syntax fix to my BugList. We have the 3D Surface/Waterline split PR awaiting review and merger, as well as some great performance improvements in the works by @ETrombly. So, 3D Surface is getting a lot of love at the moment! We are working to determine the order in which to submit PRs and where certain fixes should be placed.

As an aside, I'm excited to see 3D Surface helping out so many and getting so many involved in the forum.

As for the G0 issue you mentioned, It think that will be handled on the post-processor side. I know in the operation code, I do add the rapid feed rate argument to the G0 commands to be created, most of the time, just in case it is needed by a post processor.

You might need to search for a historical topic related to removing feed rates from G0 commands and see if there was any discussion and resolution. If not, it might be worth bringing up in the forum as a separate topic.

Have a great day!

Russ

[RatonLaveur]

most of the time, just in case it is needed by a post processor.

I can speak for myself having worked with FANUC, DeltaTau, Siemens, Bosch, Mitsubishi and Heindenhein CNC, that G0 generally does not require a feed argument, and sometimes doing so will even result in an error. The rapid feedrate i generally setup in the CNC and is not a dynamic variable.
The reason is that some programs will be run on several different machines, with different capabilities. Depending on the size of the machine, the program overriding the CNC set rapid rate could result in loss of precision at best and catastrophic damage at worse.

[Gauthier]

As for the G0 issue you mentioned, It think that will be handled on the post-processor side. I know in the operation code, I do add the rapid feed rate argument to the G0 commands to be created, most of the time, just in case it is needed by a post processor.

You might need to search for a historical topic related to removing feed rates from G0 commands and see if there was any discussion and resolution. If not, it might be worth bringing up in the forum as a separate topic.

I searched historical topic with "+G0 +rapid +feedrate" keyword, and from the 71 results I found with this keywords, only one result discuss about this same question: https://forum.freecadweb.org/viewtopic. ... rapid+feed
This subject is about the writing of a post processor for Marlin, but Marlin acts G0 and G1 as the same! So, I think it's out of this perimeter.

The reason is that some programs will be run on several different machines, with different capabilities. Depending on the size of the machine, the program overriding the CNC set rapid rate could result in loss of precision at best and catastrophic damage at worse.

I agree with this.

From the linuxcnc documentation : http://linuxcnc.org/docs/html/gcode/g-c ... l#gcode:g0, the G0 does'nt have feedrate parameter.
The MAX_VELOCITY setting is defined in the setting parameters of the machin.

In addition, the other G0 code generated by FreeCAD are generated without the feedrate parameter.

So, I think it's not a good idea to add G0 F*.

@++;
Gauthier.

[Wsk8]

Feedrate for G0 isn't outputted by the post processor. So it doesn't matter if it has a actual value or zero.

br

[Russ4262]

Afternoon, Sir.
Thanks for the great feedback.

... Issue found with the tool tips:...

I fixed the grammatical error, and will add the fix to the current split PR if still awaiting review.

Now for the other issues:
I seem to have trouble with the Circular (and CIrcular ZigZag) patterns. See file attached. Test_half_spheres.FCStd
They compute fine on the flat surface in-between the half spheres but they crash on the half spheres themselves.

EDIT: I deleted my `Default Tool` rant.
I opened your file and added a 2mm endmill with tool controller to the Job. I selected for the Surface operation and the operation then produces a correct path, sans erreur. Toggling the tool controller back to `Default Tool` re-produces the error you report.

I guess I need to track down the specific erroneous or missing object value within `Default Tool` that is causing an error in some operations.
EDIT: I'll just throw a check in the error code you reported to check for the math error produced. Guess I should be smarter, not FreeCAD!

EDIT: I started playing with the center used for the circular calculation just in case i was accidentally asking for something impossible to the algo, only XminYmin really worked. The result is shall I say interesting: Circular_Xmin_Ymin.png
...

The `XminYmin` setting for `CenterCircleAt` uses the (X minimum, Y minimum) coordinate value of the bound box for the selected face(s). It is an unnecessary choice since the `Custom` entry is available, and the user can enter that point if so desired. Nonetheless, it makes for a nice quick use of circular patterns for some use cases.

Thanks!

Russell

[Russ4262]

... Replacing lines 390 to 398 in PathSurface.py with those ones can correct the problem:

Code: Select all

        if obj.Comment != '':
            self.commandlist.append(Path.Command('N ({})'.format(str(obj.Comment)), {}))
        ...

...

Done. I copied your code and pasted into the current batch of fixes I'm working on. You'll be an official contributor to the code base!

Thanks,
Russell

[giedrius9999]

Firstly, I would like to thank you for this inmense work!!!...and for support too!!!...the feature what you are implementing is very necessary...in my case too.
...for waterjet milling I have the z fixed, meanwhile the F - feedrate of the moving jet controls the deepth of cut...I have no collisions..if I have zigzag ups and downs its makes complicated to generate necessary g code for my application

[Russ4262]

Me again,

...
I seem to have trouble with the Circular (and CIrcular ZigZag) patterns. See file attached. Test_half_spheres.FCStd
They compute fine on the flat surface in-between the half spheres but they crash on the half spheres themselves.

The issue seems to be a math error. Here the associated report:
...

Okay. I added a check for the `math.asin()` function there. If the input is greater than 1.0, it will adjust accordingly. Consequently, the `Default Tool` now produces a correct path. Yay!

Thanks for helping us make FreeCAD better!

Russell

[Russ4262]

It's just me,

Hello Guys,

Maybe any ideas why I still have Zigzag with ups and downs?
...how to set it up without?

Okay, this issue is fixed in my BugFix list, as per testing with your file. I adjusted the tolerance on the offset face generation. So, now all you need to do is toggle the `Optimize Step Over Transitions` to `True`, as seen in the last image, and you will be good to go! No need to change the `BoundBox` property.

I'll get these things presented here today committed to the PR branch so they should be active when the 3D Surface/Waterline split is merged.

Another observation on your project, after switching to Front View:
I see using the `Default Tool`, leaves some gaps between the path and the surface. The `Default Tool` diameter is 5.0 mm. See the second image. Be sure to load the appropriate tool diameter to get a more accurate, face-following path for your water jet machine. I loaded a 1.0mm diameter tool and recomputed the operation to yield results seen in the first image. You will likely want a smaller tool diameter and a small SampleInterval as well.

Thanks for providing feedback.

Russ

[RatonLaveur]

Be sure to load the appropriate tool diameter to get a more accurate, face-following path for your water jet machine. I loaded a 1.0mm diameter tool and recomputed the operation to yield results seen in the first image.

It seems in your pictures that switching to a smaller tool didn't get you all the way there.
In my experience choosing the right Angular and Linear Deviations on the mesh is super important. What's more, making sure these parameters are accurate enough also in the Edit/Preferences/ PartDesign/ShapeView is key for you to actually see whether your issue is calculation or display related.