Our ability to provide PY3 builds is recent, so, until now only those that could compile w/PY3 themselves have had the ability to test.
I would suggest to fix it in a separate pull request from your main work.
Our ability to provide PY3 builds is recent, so, until now only those that could compile w/PY3 themselves have had the ability to test.
Hi Dan,dubstar-04 wrote: ↑Mon Aug 27, 2018 7:26 pm
Is there anything that can be done about the 'linking moves' where the tool rises between sections?
Peek 2018-08-27 20-25.gif
Thats good news. Thank you for taking the time to check.kreso-t wrote: ↑Tue Aug 28, 2018 3:42 pmHi Dan,dubstar-04 wrote: ↑Mon Aug 27, 2018 7:26 pm
Is there anything that can be done about the 'linking moves' where the tool rises between sections?
Peek 2018-08-27 20-25.gif
I tried this with your model and I can't seem to actually reproduce the issue I thought you are having - in all cases I checked it actually raises the tool to avoid cutting into regions that are not yet cleared when re-positioning to another section - which is behavior by design. From this angle I can not tell for sure if this is also the case in your simulation. However this design has potential for improvement and I have an idea how to optimize the linking moves in such cases as shown in your simulation (i.e. when that region passed over by linking move should eventually be cleared so it could try to do straight cut through it if that cut is not violating optimal step-over and also not cutting out of the boundaries of the base geometry) but it is a bit more complex addition, will need some more time for this.
BR,
Kreso
Hi Dan,dubstar-04 wrote: ↑Tue Aug 28, 2018 7:46 pmThats good news. Thank you for taking the time to check.kreso-t wrote: ↑Tue Aug 28, 2018 3:42 pmHi Dan,dubstar-04 wrote: ↑Mon Aug 27, 2018 7:26 pm
Is there anything that can be done about the 'linking moves' where the tool rises between sections?
Peek 2018-08-27 20-25.gif
I tried this with your model and I can't seem to actually reproduce the issue I thought you are having - in all cases I checked it actually raises the tool to avoid cutting into regions that are not yet cleared when re-positioning to another section - which is behavior by design. From this angle I can not tell for sure if this is also the case in your simulation. However this design has potential for improvement and I have an idea how to optimize the linking moves in such cases as shown in your simulation (i.e. when that region passed over by linking move should eventually be cleared so it could try to do straight cut through it if that cut is not violating optimal step-over and also not cutting out of the boundaries of the base geometry) but it is a bit more complex addition, will need some more time for this.
BR,
Kreso
I was showing the adaptive tool path to someone today and they couldn't believe it was included in FreeCAD!!
Thank you for all your effort.
That's great news!!kreso-t wrote: ↑Tue Aug 28, 2018 8:50 pmHi Dan,dubstar-04 wrote: ↑Tue Aug 28, 2018 7:46 pmThats good news. Thank you for taking the time to check.kreso-t wrote: ↑Tue Aug 28, 2018 3:42 pmHi Dan,dubstar-04 wrote: ↑Mon Aug 27, 2018 7:26 pm
Is there anything that can be done about the 'linking moves' where the tool rises between sections?
Peek 2018-08-27 20-25.gif
I tried this with your model and I can't seem to actually reproduce the issue I thought you are having - in all cases I checked it actually raises the tool to avoid cutting into regions that are not yet cleared when re-positioning to another section - which is behavior by design. From this angle I can not tell for sure if this is also the case in your simulation. However this design has potential for improvement and I have an idea how to optimize the linking moves in such cases as shown in your simulation (i.e. when that region passed over by linking move should eventually be cleared so it could try to do straight cut through it if that cut is not violating optimal step-over and also not cutting out of the boundaries of the base geometry) but it is a bit more complex addition, will need some more time for this.
BR,
Kreso
I was showing the adaptive tool path to someone today and they couldn't believe it was included in FreeCAD!!
Thank you for all your effort.
I managed to add some optimizations safely (I think, based on initial tests seems OK) related to those unnecessary "linking moves" (based on that idea in my previous post, wasn't that complicated as I initially thought), now your test model has cca 20% less "linking moves". Also I added the "Stock to Leave" option:
Selection_023.png
BR,
Kreso
Code: Select all
Traceback (most recent call last):
File "/home/sandal/FreeCAD/build/Mod/Path/PathScripts/PathUtils.py", line 60, in new_function
res = function(*args, **kwargs)
File "/home/sandal/FreeCAD/build/Mod/Path/PathScripts/PathOp.py", line 449, in execute
result = self.opExecute(obj)
File "/home/sandal/FreeCAD/build/Mod/Path/PathScripts/PathAdaptive.py", line 409, in opExecute
Execute(self,obj)
File "/home/sandal/FreeCAD/build/Mod/Path/PathScripts/PathAdaptive.py", line 318, in Execute
a2d.stockToLeave = obj.StockToLeave
<class 'Boost.Python.ArgumentError'>: Python argument types in
None.None(Adaptive2d, Base.Quantity)
did not match C++ signature:
None(AdaptivePath::Adaptive2d {lvalue}, double)
Sorry, my bad, tested it only with PYBIND11 build (and PYBIND is much smarter with converting the types from python to c++ than boost-python).dubstar-04 wrote: ↑Tue Aug 28, 2018 9:09 pm That's great news!!
I just tried testing and I am getting the following error:
Code: Select all
Traceback (most recent call last): File "/home/sandal/FreeCAD/build/Mod/Path/PathScripts/PathUtils.py", line 60, in new_function res = function(*args, **kwargs) File "/home/sandal/FreeCAD/build/Mod/Path/PathScripts/PathOp.py", line 449, in execute result = self.opExecute(obj) File "/home/sandal/FreeCAD/build/Mod/Path/PathScripts/PathAdaptive.py", line 409, in opExecute Execute(self,obj) File "/home/sandal/FreeCAD/build/Mod/Path/PathScripts/PathAdaptive.py", line 318, in Execute a2d.stockToLeave = obj.StockToLeave <class 'Boost.Python.ArgumentError'>: Python argument types in None.None(Adaptive2d, Base.Quantity) did not match C++ signature: None(AdaptivePath::Adaptive2d {lvalue}, double)
kreso-t wrote: ↑Tue Aug 28, 2018 9:23 pmSorry, my bad, tested it only with PYBIND11 build (and PYBIND is much smarter with converting the types from python to c++ than boost-python).dubstar-04 wrote: ↑Tue Aug 28, 2018 9:09 pm That's great news!!
I just tried testing and I am getting the following error:
Code: Select all
Traceback (most recent call last): File "/home/sandal/FreeCAD/build/Mod/Path/PathScripts/PathUtils.py", line 60, in new_function res = function(*args, **kwargs) File "/home/sandal/FreeCAD/build/Mod/Path/PathScripts/PathOp.py", line 449, in execute result = self.opExecute(obj) File "/home/sandal/FreeCAD/build/Mod/Path/PathScripts/PathAdaptive.py", line 409, in opExecute Execute(self,obj) File "/home/sandal/FreeCAD/build/Mod/Path/PathScripts/PathAdaptive.py", line 318, in Execute a2d.stockToLeave = obj.StockToLeave <class 'Boost.Python.ArgumentError'>: Python argument types in None.None(Adaptive2d, Base.Quantity) did not match C++ signature: None(AdaptivePath::Adaptive2d {lvalue}, double)
It's fixed now.
Also not sure if you already did that, but you need to add new adaptive operation, on the existing it will not work as it does not have this StockToLeave parameter stored in the model.
K.
Thx Dan,
This would definitely be useful the test part for example:kreso-t wrote: ↑Wed Aug 29, 2018 6:59 pmThx Dan,
I am wondering how useful would it be to have the possibility to define in the adaptive operation (somehow, not sure exactly yet what would be the best way) to start cutting from the outside of the stock material, so that it does not necessarily have to plunge into material if not needed. I.e. if you would have model like the following:
FreeCAD 0.18_024.png
This current inside-out approach seem to have some advantages cause it's maybe less likely for tool to hit clamps/fixtures, but still wondering if there are situations where you would really need to start cutting from outside-in. What do you think? Which do you use more often?
Thx,
K.