Feature Request - Canned Cycle Termination - G80
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: Feature Request - Canned Cycle Termination - G80
The order of paths is currently pretty uncontrollable from the user point of view, sadly.
You could try breaking it down into two, two hole ops to get the order, but of course it would pull out at the end of the first one.
This was discussed in the last week in a similar thread on Path/CAM.
Hopefully at some stage there will be a means for users to alter the automatic order of holes within a group.
You could try breaking it down into two, two hole ops to get the order, but of course it would pull out at the end of the first one.
This was discussed in the last week in a similar thread on Path/CAM.
Hopefully at some stage there will be a means for users to alter the automatic order of holes within a group.
Re: Feature Request - Canned Cycle Termination - G80
Many thanks, that's too recent to me to able to remember
Re: Feature Request - Canned Cycle Termination - G80
I just created a simple square with 6 holes. I wanted to eliminate any vestiges of the old version 19.4 that I had installed previously. I selected just two of the 6 holes for drilling using "G83" peck. As you will see in the youtube animation below, the tool starts above hole 1, raises to safe height, rapids to hole 2, lowers as if to drill hole 2, rapids back to hole 1, drills the hole 1, raises and rapids back to hole 2, drills hole 2.
It seems the pathing worked in v19.4 but there was the issue with a G80 being issued after every hole. Now, with v20, the G80 issue is resolved but the pathing seems to be messed up.
Here's a link to a short video demonstrating the issue:
https://youtu.be/PvM1gbCQt9w
OS: Windows 10 Version 2009
Word size of FreeCAD: 64-bit
Version: 0.20.27428 (Git)
Build type: Release
Branch: master
Hash: 27460358508a2057e0ec57a418641435f12628dd
Python version: 3.8.6+
Qt version: 5.15.2
Coin version: 4.0.1
OCC version: 7.5.3
Locale: English/United States (en_US)
It seems the pathing worked in v19.4 but there was the issue with a G80 being issued after every hole. Now, with v20, the G80 issue is resolved but the pathing seems to be messed up.
Here's a link to a short video demonstrating the issue:
https://youtu.be/PvM1gbCQt9w
OS: Windows 10 Version 2009
Word size of FreeCAD: 64-bit
Version: 0.20.27428 (Git)
Build type: Release
Branch: master
Hash: 27460358508a2057e0ec57a418641435f12628dd
Python version: 3.8.6+
Qt version: 5.15.2
Coin version: 4.0.1
OCC version: 7.5.3
Locale: English/United States (en_US)
Re: Feature Request - Canned Cycle Termination - G80
Thanks. I would be wary about putting too much confidence in the sim., not that I'm saying it is misleading you here.
Could you post the FCStd which you created using v0.20 which corresponds to this video, so it can be confirmed and investigated in detail. Thanks for the time spent so far.
Could you post the FCStd which you created using v0.20 which corresponds to this video, so it can be confirmed and investigated in detail. Thanks for the time spent so far.
Re: Feature Request - Canned Cycle Termination - G80
Sure can, see attached. The gcode also confirms the erratic behavior. Thanks
- Attachments
-
- test.FCStd
- (25.33 KiB) Downloaded 28 times
Re: Feature Request - Canned Cycle Termination - G80
Actually -- the last file I uploaded had the wrong two holes selected. Here's the updated file that matches the video:
- Attachments
-
- test.FCStd
- (25.41 KiB) Downloaded 26 times
-
- Posts: 255
- Joined: Sat Nov 14, 2020 9:16 pm
- Location: Bargara, Queensland, Australia UTC+10
Re: Feature Request - Canned Cycle Termination - G80
There is something odd going on with this model.
The Z values output by the post processor are too small for the setup. It does not matter where Z0.0 is set to, the output is always the same?
Using my own post processor produces the same results.
A newly created model produces correct output.
.
Code: Select all
OS: Ubuntu 20.04.4 LTS (ubuntu:GNOME/ubuntu)
Word size of FreeCAD: 64-bit
Version: 0.20.28717 (Git) AppImage
Build type: Release
Branch: (HEAD detached at fee4046)
Hash: fee404602bee4e1d576cb6f979a8623c63c6815a
Python 3.9.12, Qt 5.12.9, Coin 4.0.0, OCC 7.5.3
Locale: English/Australia (en_AU)
Installed mods:
* Curves 0.3.0
* CurvedShapes
Re: Feature Request - Canned Cycle Termination - G80
Maybe I am missing something about canned cycles but aren't the G0 and G1 moves inbetween the G83s canceling the canned cycle anyway (as if by inserting a G80 after every G83). See the LinuxCNC documentation for G80: "[...] programming any other G code from modal group 1 will also cancel the canned cycle". Modal group 1 is the Motion group including G0 and G1.
So the way I see it we should just ditch all G0 and G1s inbetween G83s and let the canned cycles take care of the inbetween moves (???)
Best wishes and thank you all,
jffmichi
So the way I see it we should just ditch all G0 and G1s inbetween G83s and let the canned cycles take care of the inbetween moves (???)
Best wishes and thank you all,
jffmichi
Re: Feature Request - Canned Cycle Termination - G80
Can you share the model you created so I can test it? Thanksbmsaus4ax wrote: ↑Sat Apr 23, 2022 11:43 pmThere is something odd going on with this model.
The Z values output by the post processor are too small for the setup. It does not matter where Z0.0 is set to, the output is always the same?
Using my own post processor produces the same results.
A newly created model produces correct output.
.Code: Select all
OS: Ubuntu 20.04.4 LTS (ubuntu:GNOME/ubuntu) Word size of FreeCAD: 64-bit Version: 0.20.28717 (Git) AppImage Build type: Release Branch: (HEAD detached at fee4046) Hash: fee404602bee4e1d576cb6f979a8623c63c6815a Python 3.9.12, Qt 5.12.9, Coin 4.0.0, OCC 7.5.3 Locale: English/Australia (en_AU) Installed mods: * Curves 0.3.0 * CurvedShapes