Evening, J.
Thanks for the continued testing and feedback. I just took a look at the information you posted.
RatonLaveur wrote: ↑Wed Jun 12, 2019 10:07 pm
Thanks for updating the scripts, i've been taking them out for a spin, and it seems things are broken somewhere.
Indeed, it appears so. Good news though. It isn't what it seems. I loaded your file in my machine with setup pasted at the end of this message. I was able to click `Recompute` on two of the bad paths and they corrected straight away. I did find a line of code that needed adjustment to correct another two - it had to do with depth settings.
RatonLaveur wrote: ↑Wed Jun 12, 2019 10:07 pm
Beware that I'm using python 2.7 ... Version: 0.18.16093 (Git)
I have not located my binary archives. I think I have your version, or one very close to unzip and test with. I don't recall if I have the 2.7 version. Likely I have the 3.6 because I began to personally transition about that time from 2.7 to 3.6 once I was able to compile OCL for 3.6. Anyhow, I think the distant version differences probably have a role to play in the erroneous paths being generated.
RatonLaveur wrote: ↑Wed Jun 12, 2019 10:07 pm
Using the job, I started gentle with face-milling, then proceeded to ask for pocketing the counter bore surface. Profiling this surface works. Pocketing it doesn't. It also generates a funny weird face-milling type path around the body (see screenshot).
Not discouraged for a second, I proceeded to test the other holes and enabling rotations. Funnily enough, same problem occurs. I attach the file as I found it problematic.
The "weird face-milling" type paths usually appear when no face is entered in the Base Geometry tab. This can occur due to errors with the `extensions` feature included in the PocketShape tool. Otherwise, I only found Pocket_Shape002 to be set incorrectly; it was set to `EnableRotation = B(y)`, but needed `A(x)`.
RatonLaveur wrote: ↑Wed Jun 12, 2019 10:07 pm
Fiddling around with the profiling ops seems to work. Whenever the B(y) rotation axis is involved some serious Boolean gymnastic is required between B-Axis override, Attempt inverse angle, reverse direction and inverse angle...
If I recall, the B-Axis Override has been fixed permanently since 0.18.16093. B(y) rotations are rendering correctly since. For that reason, I have not made any adjustments to it within the code I have been working on. And, I have not been testing for compatibility with older versions. My apologies. If I get time, I will put a little more effort into testing and ensuring better backward compatibility with the 0.18 stable release.
RatonLaveur wrote: ↑Wed Jun 12, 2019 10:07 pm
Also, the behavior regarding profiling is unclear, most of the time, when I get the profile in the location that I want 2019-06-13_00h01_14.png(around the face I selected) it doesn't perform the adequate step-down and stays at the first layer around the face2019-06-12_23h58_13.png.
This looks and sounds familiar from testing. I have made some depth and orientation analysis improvements in the code. I can offer a few suggestions also:
- When working with rotation enabled operations, you may have to manually override the Start Depth or Final Depths to see if that corrects the issue.
- Yes, toggling the InverseAngle property will correct the issue in some instances. If the lead in drop-down of the cutter is cutting through the model, rather than starting on the perimeter of the model and moving toward it, then the InverseAngle or the ReverseDirection probably need adjusted.
- Keep in mind:
- ReverseDirection should always change the path 180 degrees. No more. No less.
- InverseAngle is used to correct a mistaken minus(-) sign. For example, you may notice the path points at the correct face, but is approaching from a slightly wrong direction. Say the face requires a 30 degree rotation to be normal at Z-axis. The code may offer a path at -30 degrees to the face. This is when you would try InverseAngle toggle. This would change the -30 to 30 degrees for the path.
RatonLaveur wrote: ↑Wed Jun 12, 2019 10:07 pm
I think overall the promising capabilities you've enabled look great and feel almost right. If the behaviour can be made more intuitive, you've got something that will be able to be machined soon.
I have improved the AttemptInverseAngle feature to be more intuitive. If set to True, it will automatically attempt the InverseAngle (if set to False) upon determining the initial rotation was not correct. Additionally, it will help when I get some documentation posted to the Wiki, rather than the scattered bits and pieces here on the forum. My goal has been to get some consistency with property names and functionality before drafting much documentation. Once we have some reliability, documentation will be easier to write.
RatonLaveur wrote: ↑Wed Jun 12, 2019 10:07 pm
Thanks so much for your efforts, I'm ready for your rebuttal and counter-experiments.
You are quite welcome, Sir. I really appreciate your patience, investment, participation and time in the matter. I have had a lot of fun.
I will again post the most recently updated version 2g-testing scripts for your benefit, and that of the greater FC community.
Gratefully,
Russ
Of late, I have been developing using this below, but have pulled some additional recent commits in from the FC master repo:
OS: Windows 10 (10.0)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.16886 (Git)
Build type: Release
Branch: master
Hash: ed47e962d2c821bf1792889f6d7bdf457dcf6c9e
Python version: 3.6.8
Qt version: 5.12.1
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/United States (en_US)