Evening Walter,
Thank you very much for the great explanation and set of visuals. I had no problem understanding the two issues you presented. With regard to those issues, the first is the easiest fix.
roerich_64 wrote: ↑Thu Mar 28, 2019 10:19 am
Now we can generate the gCode with 3D-Surface but with depth offset = 10mm:
The result is: the paths are to high
This issue involves a pre-existing bug with the 3D Surface Op. Basically, the op initializes the Final Depth with a best guess value. This value is usually a correct value, or at least useful and a great guess. However, once the user clicks OK to run the operation, that value would get reset to zero. This just frustrates the user. I know !! Up to this point I have had to manually override that value in the Heights section of the operation's settings window or properties list. This is what you would have needed to do (setting it to -10.5mm in your example provided) instead of changing the Depth Offset to 10mm.
But, thanks to your re-iteration of there being a problem, I tackled it today - at least it appears to be corrected with my tests. I am attaching the patched version of the script you downloaded. I will include this same fix in future releases. With the fixed script
As for the second issue,
roerich_64 wrote: ↑Thu Mar 28, 2019 10:19 am
The result is: the generated gCode is not linear
I have made some investigations and reached the conclusion that the problem may lie within OCL, not the operation python script we are using. I attempted diminishing the tessellation tolerance greatly, with no visible result. I also reworked the OCL scan function in the script, with no visible result. Therefore, I am thinking the NON-linear paths are not a result of the python script; I am thinking OCL. Perhaps the significant digits, the number of decimal places, the nature of the OCL scan process itself, or another issue all together like the mesh, created from the solid, that is used for the OCL scan.
I will say also, that I noticed the tool used in your test, T4: T3_0.5mm_Kugel, appears to be a very small diameter. Also, the Step Over is set to 20%. This yields a 0.1mm step for each pass. When I loaded the test file, the Sample Interval shows 1.0mm. I set it to 0.01mm to see if that removed the non-linear paths, but it did not. I DON'T think the high resolution cut you are testing is problematic. I like your test!
I used your same model, same tool, same step over, and 0.1mm sample interval. I set Drop Cutter Extra Offest to .25mm for X and Y to allow the cutter to slide further down the curve of the model. I clicked OK to run the operation. I set cut direction to Y in properties list. This yielded the expected result in the first picture - nice straight, square bottoms on the paths.
- Drop Cutter Extra Offset = 0.25 x&y, Y direct cut
- non-linear-0.25 extra (Y dir).png (268.47 KiB) Viewed 1848 times
I then set Drop Cutter Extra Offest to .20mm for X and Y to raise the cutter up on the curve of the model. I clicked OK to run the operation. This yielded the very interesting result in the second picture. It looks like a sine or cosine wave on the bottom of the paths !
- Drop Cutter Extra Offset = 0.20 x&y, Y direct cut
- non-linear-0.20 extra (Y dir).png (266.72 KiB) Viewed 1848 times
I only changed the cut direction to X in properties list with the same 0.20mm extra offset as above. This yielded the expected result in the third picture - VERY NON-linear paths at the edge of the curved surface, running parallel to it.
- Drop Cutter Extra Offset = 0.20 x&y, X direct cut
- non-linear-0.20 extra (X dir).png (216.45 KiB) Viewed 1848 times
I think the problem lies in OCL or beyond the 3D Surface Op python script. I notice that the non-linear quality of the paths is worse where deflection increases.
Thanks for your help and insights, Walter. We will continue to work on this non-linear path issue. I am attaching the patched version of the 3D Surface Op to fix the Final Depth issue.
Good night, Sir.
Russell