Feature Request - Canned Cycle Termination - G80

Here's the place for discussion related to CAM/CNC and the development of the Path module.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
luvtofish
Posts: 83
Joined: Thu Mar 31, 2022 8:45 pm

Re: Feature Request - Canned Cycle Termination - G80

Post by luvtofish »

I just installed freecad on Linux and all of the back & forth motion is gone. I had already ruled out the PP as being a concern. I only mentioned it above because you were using one that is not on my system so it caused errors.

Again, working perfectly on Linux using the following version:

Code: Select all

OS: Ubuntu Core 20 (GNOME/gnome)
Word size of FreeCAD: 64-bit
Version: 0.20.28751 (Git)
Build type: Release
Branch: master
Hash: d36cbb522ae91574b8ff41257653a514c1cb4beb
Python 3.8.10, Qt 5.15.3, Coin 4.0.0, OCC 7.6.1
Locale: English/United States (en_US)
User avatar
freman
Veteran
Posts: 2214
Joined: Tue Nov 27, 2018 10:30 pm

Re: Feature Request - Canned Cycle Termination - G80

Post by freman »

Cool, I'm glad you got that stabilised.

Now perhaps we can focus on the original point of your thread. - Canned Cycle Termination - G80
User avatar
luvtofish
Posts: 83
Joined: Thu Mar 31, 2022 8:45 pm

Re: Feature Request - Canned Cycle Termination - G80

Post by luvtofish »

Yes, back to the need for "canned cycles" that remain modal until the G80 is issued. TBF, the current situation (so long as I'm using an un-bugged version)
is workable. Much of my consternation had to do with the issue I was originally experiencing which was multiple "G80" being issued. sliptonic pointed out that problem was fixed in v20 and so it is!

So I think we can safely call this effort closed with the adoption of v20 on Linux vs windows. In my ignorance, I didn't realized the fix was to just upgrade to v20. Despite the long path I took to get to this point, there remains an issue with v20 on Windows 11. I'll continue working with FreeCAD on my Centos 8 desktop going forward. I prefer Linux over Win-dose anyway :)

Thank you for hanging with me Freman.

Dan
User avatar
freman
Veteran
Posts: 2214
Joined: Tue Nov 27, 2018 10:30 pm

Re: Feature Request - Canned Cycle Termination - G80

Post by freman »

Sorry if I'm getting a bit off track or confused at this point.
I have test.FCStd lined up which I think is the latest version you offered with one drilling operation on two holes .

When I look at the straight Gcode ( without post-procs ) I see two single drilling moves , each fully specified, with G0 to reposition in between.

This is NOT using canned cycles in anything but name. Two G83's with one hole each , with the G83 cancelled by G0 in between, is not in any way making use of canned cycles.

What I would expect from canned cycles is the first G83 ( which sets Z and R ) and then a following G83 with just new X,Y and no G0. We could discuss whether R should be 30 or 27.

Code: Select all


(Drilling)
(Begin Drilling)
G0 F0.000000 Z39.700200
G90
G98
G0 F0.000000 X5.080000 Y5.080000
G0 F0.000000 Z30.000200
G83 F0.846667 Q4.762500 R27.000200 X5.080000 Y5.080000 Z-1.870218
G0 F0.000000 X71.120000 Y5.080000
G0 F0.000000 Z30.000200
G83 F0.846667 Q4.762500 R27.000200 X71.120000 Y5.080000 Z-1.870218
G80
G0 F0.000000 Z30.000200
G0 Z39.700200

Please correct me if, after all the diversions, I've lost track of what is going on here.
User avatar
luvtofish
Posts: 83
Joined: Thu Mar 31, 2022 8:45 pm

Re: Feature Request - Canned Cycle Termination - G80

Post by luvtofish »

This is true but that wasn't the reason I opened this thread. The reason had to do with a G80 being output after every hole. If I had four holes I would get 4 G80's.
I agree with you, I'm just saying that is a different concern than the original reason indicated in this thread.
User avatar
freman
Veteran
Posts: 2214
Joined: Tue Nov 27, 2018 10:30 pm

Re: Feature Request - Canned Cycle Termination - G80

Post by freman »

Thanks, re-reading your original I realise you were questioning G80 not G0. That does seem to have been fixed as sliptonic pointed out.

The lack of proper use of canned cycles does not seem that important since it just means somewhat more voluminous GCODE output rather than any disfunction at the machine level. Plus many simple GCODE interpreters like GRBL and derivatives do not support canned cycles anyway.
User avatar
luvtofish
Posts: 83
Joined: Thu Mar 31, 2022 8:45 pm

Re: Feature Request - Canned Cycle Termination - G80

Post by luvtofish »

freman wrote: Mon Apr 25, 2022 4:11 am Thanks, re-reading your original I realise you were questioning G80 not G0. That does seem to have been fixed as sliptonic pointed out.

The lack of proper use of canned cycles does not seem that important since it just means somewhat more voluminous GCODE output rather than any disfunction at the machine level. Plus many simple GCODE interpreters like GRBL and derivatives do not support canned cycles anyway.
I completely agree and thanks!

Dan
lylejabe
Posts: 4
Joined: Fri Sep 30, 2022 4:35 pm

Re: Feature Request - Canned Cycle Termination - G80

Post by lylejabe »

This is my first post here on the forum so please excuse me if I'm out of line here, but I would respectfully have to disagree with:

"The lack of proper use of canned cycles does not seem that important since it just means somewhat more voluminous GCODE output rather than any disfunction at the machine level."

The whole purpose of canned cycles is to eliminate 'voluminous G-code'. It may not be an issue if you've only got three or for holes in your part, but I've got parts with 20 or more holes that get spot drilled, drilled, and reamed. The resulting 'voluminous' code is extremely difficult to read and verify. Not to mention that with older controls the available memory can be quite limited. The interpreters that don't support canned cycles can ignore them, but that's a function of the post-processor, isn't it? I'm using the Fanuc 15m post that was linked in another forum post (the fanuc post that comes with version 0.20 is broken...it works fine until a drilling operation is added at which point it errors out - tooltype == tap not found...but that's another thread). So, my question is: How would one modify the post to recognize canned cycles and output the correct g-code?
User avatar
freman
Veteran
Posts: 2214
Joined: Tue Nov 27, 2018 10:30 pm

Re: Feature Request - Canned Cycle Termination - G80

Post by freman »

The resulting 'voluminous' code is extremely difficult to read and verify.
Maybe you don't need to verify every line by reading. Use the simulator to see whether the placements seem to look about right and and check the gcode for the first two holes to see whether the depths and retract heights between holes are doing what you expect. Give close attention to retract heights, that is a problematic area at the moment.

I had a four hole pattern recently and that is the way I checked the code.

If FreeCAD is producing explicit gcode for each hole, it could technically be possible to recognise this in a post-processor and reduce it but I think that would be a pretty complicated task.
lylejabe
Posts: 4
Joined: Fri Sep 30, 2022 4:35 pm

Re: Feature Request - Canned Cycle Termination - G80

Post by lylejabe »

Watching the simulation doesn't tell me where the machine is going. I'm not a programmer, so I can't speak to how daunting the task would be. What threw me was the fact that there is a modal argument that can be passed to the post. Reading the description for that argument sounds as though it's possible to output clean g-code. But the code posts the same, regardless of passing the --modal argument to the post.
Post Reply