PathShape is not member of Job Operations (bug?)

[Gauthier]

Hi all,

Thanks for the job of the great Path workshop !

In a Path milling project, I need to use some PathShape operations (Path along vertical lines) to make some drilling... My CNC can't use standard drilling cycle G81, G82, ...

But the PathShape operation created is not member of the Job Operations like the other (Pocket, Profiles, etc.)

Capture_2017-11-06_19-53-36.png (150.9 KiB) Viewed 1885 times

So, the generated gcode file of the job don't include the PathShapes operations

Do I made something wrong or is it a bug ?

Frecad 0.17 on Debian SID just updates today :
| OS: Debian GNU/Linux unstable (sid)
| Word size of OS: 64-bit
| Word size of FreeCAD: 64-bit
| Version: 0.17.12559 (Git)
| Build type: Release
| Branch: master
| Hash: 41deaf82dd52c9f5aa48302f2c4d30a481ba7292
| Python version: 2.7.14
| Qt version: 4.8.7
| Coin version: 4.0.0a
| OCC version: 6.9.1.oce-0.18
| Locale: French/France (fr_FR)

Thanks,
Gauthier.

[sliptonic]

In a Path milling project, I need to use some PathShape operations (Path along vertical lines) to make some drilling... My CNC can't use standard drilling cycle G81, G82, ...

The right way to do this is to write your own post-processor so it handles drilling cycles properly. I think the rml post does something like this. Look at
/Mod/Path/PathScripts/post/rml_post.py around line 196. Basically, you're looking to see if the command == 'G81' and then figuring out what should be output for your specific machine. That can be a regular G1 command.

If you get this working, post back here. Others might be interested in your postprocessor.

[Gauthier]

Thanks for reply,

The right way to do this is to write your own post-processor so it handles drilling cycles properly.

In fact, I plan to write G8* postprocessor function ASAP... I will post it, but later (time is not only money)...

G8* functions are simple examples in my precedent post and not the only need. We can also need to drive diferents movments along curves, for example to drive the tool beetwen a milling to an other, around obstacles...

So, the PathShape need to be member of Job Operations that is not the case today...

Do I have to make a bug report or a feature request ?

[sliptonic]

The PathShape isn't meant to be an operation type. It's very useful for debugging and testing but wasn't intended to be a user level tool.
Please create a feature request and we'll look into it.

[Gauthier]

Thanks Sliptonic,

Feature request added to the Open discussion Freecad forum :
[Path Feature Request] Create PathShape as member of Job Operations https://forum.freecadweb.org/viewtopic.php?f=8&t=25246

[mlampert]

related issue #2786

[berka]

I came across this because I was looking for a way to make a finishing pass for a helix drill. I hit the same dead-end as @Gauthier.
I'll attach a simplified part/path showing the type of finish pass I had envisioned.
Since it appears PathShape is not a usable thing, is there a better way to make such a finish pass on a helix drill? Is this worth a feature request?
A pocket or contour doesn't allow for a tangential entry as I had envisioned.

BTW, I'm also interested in @Gauthier's canned drill post-process for grbl.

Screen Shot 2017-11-18 at 13.20.34.png (49.54 KiB) Viewed 1713 times

Code: Select all

OS: Mac OS X
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.12613 (Git)
Build type: Release
Branch: (HEAD detached at c770ce7)
Hash: c770ce7a343072dd2df74bf5b95ac4a114ce9213
Python version: 2.7.14
Qt version: 5.6.2
Coin version: 4.0.0a
OCC version: 7.1.0
Locale: English/UnitedStates (en_US)

[mlampert]

BTW, I'm also interested in @Gauthier's canned drill post-process for grbl.

I use Drilling ops with the standard grbl post processor all the time - what's the problem you run into?

[berka]

I use Drilling ops with the standard grbl post processor all the time - what's the problem you run into?

The GRBL post processor lets drill cycles (Last was G83) go through. GRBL doesn't understand drill cycles.

[berka]

More details about GRBL limitations:
https://github.com/gnea/grbl/wiki#limitations-by-design

I use bCNC to feed GRBL. I see some evidence that bCNC supposedly translates G8x codes, but it doesn't seem to work for me. I'll try again with the latest and pose the question to bCNC developer.