Feature Request - Canned Cycle Termination - G80

[luvtofish]

While developing a post processor for my CNC Control, I found an irksome detail in the way canned quill cycles (e.g, G81-G83) are terminated. I'm finding a "G80" is issued after each quill cycle event. If you have 4 identical holes to drill back to back, you will see 4 "G80's" issued. This has the undesirable effect of canceling any MODAL params that might be in play in the canned cycle. Further, it becomes problematic when you're configured to suppress duplicate commands and parameters. Subsequent canned cycles will suppress the retraction parameter "R" (which is no longer modal due to the "G80") since it's a duplicate of the previous motion line.

Why can't the G80 be delayed until the all of the hole features are finished? This would allow for duplicate suppression while maintaining modal functionality of parameters for the complete cycle -- n number of holes. Also, since these features are selected in the geometry during the operation setup, the number of "like" features to drill/bore etc. should be known and accessible.

Not sure if this clearly conveyed, I'm happy to discuss further if needed.

Thank you,

Dan

[chrisb]

This sounds like a postprocessor issue. Do you have a certain one in mind?

[luvtofish]

I'm developing one for the Dynapath Delta 40,50,60 controls and is based on the default LinuxCNC PP. I'm not certain how this could be done in the PP but if that is the expectation, I'll need to dig in to it much deeper. Currently I'm not doing anything with G80, it's being issued by freeCAD after every quill cycle line. So I suppose if this is to be handled in the PP than the PP would also need to figure out how many holes are in play and to capture and withhold the G80 until all the holes are completed.

[sliptonic]

Hm. You didn't include your FreeCAD info so I have no idea what version you're running but that's not how the current source is written. The drilling operation calls the generator for each target edge. It then inserts a single G80 after all the targets are processed.

So if you have multiple drilling operations, you'll get multiple G80's But if you have multiple targets in one operation, you should only get a single G80 at the end.

Source code here: https://github.com/FreeCAD/FreeCAD/blob ... ng.py#L247

[luvtofish]

Hm. You didn't include your FreeCAD info so I have no idea what version you're running but that's not how the current source is written. The drilling operation calls the generator for each target edge. It then inserts a single G80 after all the targets are processed.

So if you have multiple drilling operations, you'll get multiple G80's But if you have multiple targets in one operation, you should only get a single G80 at the end.

Source code here: https://github.com/FreeCAD/FreeCAD/blob ... ng.py#L247

sliptonic -- thanks for responding. This is not what I'm experiencing though it is exactly what I expect should occur. I have a single Drilling Operation with 4 holes defined. After each G83 line I get a G80 outputted. I have --axis-modal and --modal turned on so as you can expect, I'm losing parameters after the first G83 line. Here's what it looks like:

drill cycle.jpg (72.92 KiB) Viewed 1405 times

Here's my version info:

OS: Windows 10 Version 2009
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.24267 +148 (Git)
Build type: Release
Branch: Branch_0.19.4
Hash: 476ecf091941bead59b14e44afa6064d5a66afa3
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)

[sliptonic]

Looks like you're running 19 and the problem has since been resolved. Try a daily build of .20

[luvtofish]

Okay -- I'll give that a go. Thanks!

[luvtofish]

Much better with v20 latest weekly build. I'm inserting a second reference plane ("O") and removing the "G98/G99" in this version but the G80 repeat is gone! I still need to go through this output and ensure I'm not doing anything wonky. Thanks for helping my sanity level

update:
There's definitely some wonkyness going on with this output. I'm not convinced it isn't something I did previously attempting to fix the issue in v19. I need to back track and check some things to be sure.

Dan

drillingv20.jpg (87.19 KiB) Viewed 1367 times

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)

[freman]

It's probably best to recreate your example file from scratch using v0.20 to ensure no legacy object values or parameters are causing oddities. There is not a backwards compatibility policy on FreeCAD between major version changes.

[luvtofish]

I have completely uninstalled v19.4 and am working from v20. I'm getting some odd Drilling paths as listed below. I've attempted to remove and reselect the 4 holes in different order but am getting this same weird path? I did not recreate the test file from scratch, I merely removed everything down to the initial part (all job info and tools deleted) and re-added Job, tools and operations.

The drill moves back and forth to different holes between G83 cycles instead of following a single linear path around the perimeter hole to hole? Also, not sure why it jumps up to the safe height (Z0.118) only to drop back to start height (0.0) and then does a G0 rapid to a different hole. Very weird.

drill path.jpg (90.88 KiB) Viewed 1244 times

code.jpg (63.95 KiB) Viewed 1244 times

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)