Issue #8019 - Unwanted Rapid Z move before tool change

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
mcinquino
Posts: 10
Joined: Mon Mar 16, 2020 3:50 pm
Contact:

Issue #8019 - Unwanted Rapid Z move before tool change

Post by mcinquino »

Hello,

After installing FC version .20 (I believe this is when it started) I am seeing a change in my posted G-code. I now have a G0 move to my preset clearance height. Problem (at least for me) is that is happening prior to a tool selection so the TLO in the machine is possibly in an unknown state and this would be a wasted move in most cases prior to the first tool change. I went back and looked at the many g-code files I generated from path in the past and this line was never there? I had a modified linux-cnc post that I was using on a Haas Mini Mill. That post started generating errors (like described here: FREECAD 0.20.29177 AppImage Path Workbench "'_TempObject' object has no attribute 'InList'") when I attempted to post process a file after upgrading to .20. I had .18, .19 and .20 on my system all at the same time along with some development versions. So I uninstalled all versions and reinstalled v .20 (system details below) and started from scratch with the modification of the linuxcnc post processor for my needs. That seems to have resolved the "TempObject" errors. Looking at the post processor .py file I am roughly seeing where this is happening but I am not seeing how I can prevent it. It looks like the same code is used in all cases? It also looks like this rapid is being created redundantly at times. Possibly the same issue? I have tried multiple combinations of attribute settings in the Job with no luck there. Gcode snippet 1 below shows the move prior to the first tool change. Gcode snippet 2 below shows a redundant G0 call in the same program. The redundant is not as concerning but may help point to the problem. I should also add that I tried the Fanuc Post and had the same issue.

Gcode snippet 1

(Exported by FreeCAD)
(Post Processor: linuxcnc_post)
(Output Time:2022-07-14 09:20:31.746474)
(begin preamble)
G17 G54 G40 G49 G80 G90
G20
(begin operation: G54)
(machine units: in/min)
G54
G0 Z0.1969
(finish operation: G54)
(begin operation: T3: 1/4" End Mill)
(machine units: in/min)
(T3: 1/4" End Mill)
M5
M6 T3
G43 H3
M3 S5800
(finish operation: T3: 1/4" End Mill)
(begin operation: Pocket_Shape)
(machine units: in/min)
(Coolant On:Flood)
M8
(Pocket_Shape)
G0 Z0.1969
G0 X2.3495 Y-1.9543
G0 Z0.1181

Gcode snippet 2

G1 X1.0995 Y-1.2952 Z-0.3860 F30.0000
G2 X1.0998 Y-1.2707 Z-0.3860 I0.1557 J0.0100 F30.0000
G2 X1.1243 Y-1.2703 Z-0.3860 I0.0145 J-0.1554 F30.0000
G0 Z0.1969
G0 Z0.1969

(finish operation: Pocket_Shape)
(Coolant Off:Flood)
M9
(begin operation: Helix)
(machine units: in/min)
(Helix)
(helix cut operation)
G0 Z0.1969
G0 Z0.1969

G0 X2.3015 Y-2.5103 Z0.1969
G0 X2.3015 Y-2.5103 Z0.0000
G0 X2.4265 Y-2.5103
G1 Z0.0000 F5.0000





Code: Select all

OS: Windows 10 Version 2009
Word size of FreeCAD: 64-bit
Version: 0.20.29177 (Git)
Build type: Release
Branch: releases/FreeCAD-0-20
Hash: 68e337670e227889217652ddac593c93b5e8dc94
Python 3.8.10, Qt 5.15.2, Coin 4.0.1, Vtk 8.2.0, OCC 7.6.2
Locale: English/United States (en_US)
Installed mods: 
  * 3DfindIT 1.2.0
  * 3D_Printing_Tools
  * A2plus 0.4.54b
  * Assembly3 0.11.3
  * BIM 2021.12.0
  * BOLTSFC
  * CADExchanger
  * cmt_lcnc_post.py
  * cmt_lcnc_post.pyc
  * cmt_linuxcnc_post.pyc
  * Defeaturing
  * Design456 0.0.1
  * dodo
  * dxf-library
  * ExplodedAssembly
  * fasteners 0.3.38
  * FCGear 1.0.0
  * frame
  * FreeCAD_assembly3-master
  * Glass
  * Haas_Mini_Mill_post.py
  * Haas_Mini_Mill_post.pyc
  * IconThemes
  * job_Haas_mini.json
  * LCInterlocking
  * Manipulator 1.4.3
  * Mechatronic
  * NavigationIndicator
  * OpticsWorkbench 1.0.8
  * PieMenu
  * ProDarkThemePreferencePack 1.0.0
  * pyrate
  * Render 2022.2.0
  * sheetmetal 0.2.50
  * __pycache__
Last edited by Kunda1 on Tue Dec 20, 2022 12:54 pm, edited 1 time in total.
Reason: added github ticket to title
User avatar
mcinquino
Posts: 10
Joined: Mon Mar 16, 2020 3:50 pm
Contact:

Re: Unwanted Rapid Z move before tool change

Post by mcinquino »

I should add this info as well:

Linuxcnc post processor file for above code is not modified from what came with FC v.20.

This is what the Job Output settings are:

Processor linuxcnc
Arguments --inches

Work Coordinate System
G54 - Checked

Order by - Fixture

Split Output - Unchecked
Djhnsn
Posts: 1
Joined: Thu Nov 24, 2022 10:05 pm

Re: Unwanted Rapid Z move before tool change

Post by Djhnsn »

I am looking for a post for a haas minimill.

I exported the haas pre-ngc post from fusion 360, but there is seemingly no way to import it, and it requires me to learn two programming languages to port it for use here.

Can you upload your post somewhere for download?

Thanks in advance.
jurij
Posts: 22
Joined: Tue Oct 23, 2018 11:37 am

Re: Unwanted Rapid Z move before tool change

Post by jurij »

Hi,

I have noticed the same problem. In version 0.19 it didn't generate G0 to Clearance Height during Fixture operation for the first fixture. In 0.20 this is not the case any more and for all Fixture operations it generates G0 to Clearance Height. This is a good way to crash the machine, it has almost happened to me. Scenario is the following:

  • A tool with positive G43 offset is loaded in the machine.
  • G49 in the preamble cancels G43.
  • G0 to Clearance Height is executed during the first Fixture operation.
  • A crash of the machine if positive G43 offset of the loaded tool is larger than the Clearance Height

What is the reason for the change of the generated code? Why is G0 to Clearance Height needed at all during Fixture operations?
All the example files are attached using the latest 0.19 and 0.20 FreeCAD stable versions.

Jurij
Attachments
datum20.FCStd
(14.9 KiB) Downloaded 30 times
datum19.FCStd
(15.1 KiB) Downloaded 21 times
User avatar
luvtofish
Posts: 83
Joined: Thu Mar 31, 2022 8:45 pm

Re: Unwanted Rapid Z move before tool change

Post by luvtofish »

I’ve been getting this as well and pretty sure since v19. The rapid to R plane height seems to occur at the beginning and end of each operation. It throws it in there even after a canned cycle took me up to clearance height to finish. The control sends the tool back down to this safe height level (R) before ramping away to the start point. For now I’ve just been manually deleting them out of the program. Not sure if it’s a post problem or a path coding issue at this point.
Yvanr
Posts: 3
Joined: Sat Aug 20, 2022 8:03 am

Re: Unwanted Rapid Z move before tool change

Post by Yvanr »

Comment out Line 241 in \Mod\Path\PathScripts\PathPost.py

Code: Select all

#fobj.Path = Path.Path([c1, c2])
Add the following code just after

Code: Select all

fobj.Path = Path.Path([c1])
User avatar
luvtofish
Posts: 83
Joined: Thu Mar 31, 2022 8:45 pm

Re: Unwanted Rapid Z move before tool change

Post by luvtofish »

Yvanr wrote: Sat Dec 10, 2022 3:03 am Comment out Line 241 in \Mod\Path\PathScripts\PathPost.py

Code: Select all

#fobj.Path = Path.Path([c1, c2])
Add the following code just after

Code: Select all

fobj.Path = Path.Path([c1])
I recall finding this little nugget myself back on prior versions. However, that file no longer exists in v21. I believe that functionality was moved to /src/Mod/Path/Path/Post/Comand.py.

My issue is slightly different than this.

I'm getting a GO Z0.118 (clearanceHeight) after every G80 (cancel drill cycle). I believe my issue is specific to the Drilling.py file. I found where it's appending a "G0 Z + $clearanceHeight" after every G80. Why? I have no frigging idea particularly since a drilling canned cycle ends at either safeHeight or clearanceHeight already so why call it again?
GeneFC
Veteran
Posts: 5373
Joined: Sat Mar 19, 2016 3:36 pm
Location: Punta Gorda, FL

Re: Unwanted Rapid Z move before tool change

Post by GeneFC »

luvtofish wrote: Sat Dec 10, 2022 3:29 pm Why? I have no frigging idea particularly since a drilling canned cycle ends at either safeHeight or clearanceHeight already so why call it again?
This was added a couple of years ago by someone who was trying to drill a multilevel object and needed more clearance.

I strenuously objected, but the change was merged in any case.

I have customized my post-processor files to remove this unnecessary cancelation of the canned cycles.

Gene
User avatar
luvtofish
Posts: 83
Joined: Thu Mar 31, 2022 8:45 pm

Re: Unwanted Rapid Z move before tool change

Post by luvtofish »

GeneFC wrote: Sat Dec 10, 2022 3:47 pm
luvtofish wrote: Sat Dec 10, 2022 3:29 pm Why? I have no frigging idea particularly since a drilling canned cycle ends at either safeHeight or clearanceHeight already so why call it again?
This was added a couple of years ago by someone who was trying to drill a multilevel object and needed more clearance.

I strenuously objected, but the change was merged in any case.

I have customized my post-processor files to remove this unnecessary cancelation of the canned cycles.

Gene
Thanks for sharing the background info. Like you I'm still scratching my head over this? We have two planes to retract too...sounds like his post-processor was wrong or he didn't set a correct safe/clearance Height in the Op.

I think this issue should be revisited. That individual could be the one modifying his post to provide the odd ball functionality needed.
Just my 2 cents.

Dan
chrisb
Veteran
Posts: 53945
Joined: Tue Mar 17, 2015 9:14 am

Re: Unwanted Rapid Z move before tool change

Post by chrisb »

If both possibilities are sensible, an additional parameter for the postprocessor could be useful. From what I see here I would vote for the old behaviour to be the default.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Post Reply