[Merged] Ticket #6367 - Drilling not generating proper toolpaths

[mkment]

Hi,

recently there seemed to be quite some development activity related to the path workbench. As there's always some potenzial to make things better, that's great. However, I noticed drilling stopped working, at least for me. The generated toolpaths consist of going to OpStartDepth with a feed move at a single point, rapid moves to the drilling locations at OpStartDepth, drilling the hole and then always travelling back to that single point before the next hole. As a result, they are really unuseable.

Is it only me facing that problem?

OS: Linux 5.4.44-rt27 (KDE//usr/share/xsessions/plasma)
Word size of FreeCAD: 64-bit
Version: 0.20.26633 (Git)
Build type: Release
Branch: master
Hash: da0ac62ccaf55e09cd077489070fb6e2c86333a1
Python version: 3.9.9
Qt version: 5.15.2
Coin version: 4.0.0a
OCC version: 7.6.0
Locale: German/Germany (de_DE)


Edit: GH ticket [issue]#6367[/issue]

[gauna]

I can confirm this. Drilling is not working anymore.

[charleyann]

I'm seeing the same thing here.

OS: Linux Mint 20.3 (X-Cinnamon/cinnamon)
Word size of FreeCAD: 64-bit
Version: 0.20.
Build type: Release
Branch: unknown
Hash: 2b8336157bf8eb134c31f00bf20680dad1722cd7
Python version: 3.8.10
Qt version: 5.12.8
Coin version: 4.0.0
OCC version: 7.5.2
Locale: English/United States (en_US)

[gauna]

In my opinion this is introduced by git commit 5b23af3d4b229544ef3b84db28c57aba57fc0bb2


In

Code: Select all

def circularHoleExecute(self, obj, holes):

variable hole is used also it should be already outdated as it is out of focus?

Code: Select all

 for hole in holes:
+            v1 = FreeCAD.Vector(hole["x"], hole["y"], obj.StartDepth.Value)
+            v2 = FreeCAD.Vector(hole["x"], hole["y"], obj.FinalDepth.Value - endoffset)
+            edgelist.append(Part.makeLine(v1, v2))
+
+        # iterate the edgelist and generate gcode
+        for edge in edgelist:
+
+            PathLog.debug(edge)
 
             # move to hole location
-            self.commandlist.append(Path.Command('G0', {'X': p['x'], 'Y': p['y'], 'F': self.horizRapid}))
-            self.commandlist.append(Path.Command('G0', {'Z': startHeight, 'F': self.vertRapid}))
-            self.commandlist.append(Path.Command('G1', {'Z': obj.StartDepth.Value, 'F': self.vertFeed}))
 
-            # Update changes to parameters
-            params.update(cmdParams)
+            command = Path.Command(
+                "G0", {"X": hole["x"], "Y": hole["y"], "F": self.horizRapid}
+            )

[gauna]

https://github.com/FreeCAD/FreeCAD/issues/6367

[Kunda1]

Added ticket number to thread title

[sliptonic]

Thanks for the ticket. I will investigate.

The generated toolpaths consist of going to OpStartDepth with a feed move at a single point, rapid moves to the drilling locations at OpStartDepth, drilling the hole and then always travelling back to that single point before the next hole. As a result, they are really unuseable.

Looking at this, I see an issue related to the depth. Don't rely on the visual representation of the Path, however. For drilling, you really need to scrutinize the gcode because the individual holes are drilled in a canned cycle. The visualization doesn't get canned cycles very well so it's painting a move back to the original hole that doesn't exist.

The goal with this development is two-fold:

First, each target (hole) is handled independently. It's gcode is generated by a drilling 'generator'. This is the first step in removing the assumption built deep into the drill operation that all holes have the same start and end-depth. When done, we should be able to handle holes at different starting and ending planes within a single operation.

Second, we're removing the assumptions about orientation. This is a longer-term goal but is aimed at making it possible to handle drilling targets an a 3+2 rotary so we rotate the part to orient it for drilling.

Both drilling and helix share a lot so please pay attention to both operations over the next few weeks/months. I'm apologizing in advance for any breakage but remember this is a development branch!

[gauna]

Hi sliptonic,

thanks for the fix. I compiled it and it is working as expected so far.

[sliptonic]

Great. Thanks for replying back. The PR is merged

[Joneb]

Just to let you know the drilling operation isn't working the G81,g73 or G83 seems to be missing, I dont think I did anything wrong have been using the drilling op regularly for some time, also didn't pick up the posible holes from the drawing i had to add them manually..
Regards
John

Code: Select all

(Drilling001) 
(Begin Drilling) 

G0 Z5.000 
G90 
G99 
G0 X3.971 Y20.971 
G0 Z3.000 
G0 X12.971 Y20.971 
G0 Z3.000 
G0 X20.971 Y11.471 
G0 Z3.000 
G0 X20.971 Y3.971 
G0 Z3.000 
G0 X28.971 Y20.971 
G0 Z3.000 
G0 X37.971 Y20.971 
G0 Z3.000 
G0 X20.971 Y30.471 
G0 Z3.000 
G0 X20.971 Y37.971 
G0 Z3.000 
G80 
G0 Z3.000 
G0 Z5.000 
(finish operation: Drilling001)
(begin operation: Profile002)
(machine units: mm/min)

Code: Select all

OS: Windows 10 (10.0)
Word size of FreeCAD: 64-bit
Version: 0.21.29485 (Git)
Build type: Release
Branch: master
Hash: a236ca843fdd6674afb6d7ed1454fbd3b547f5ea
Python 3.8.13, Qt 5.12.9, Coin 4.0.0, Vtk 9.1.0, OCC 7.5.3
Locale: English/United Kingdom (en_GB)
Installed mods: 
  * FeedsAndSpeeds-master 0.4.0

Code: Select all

OS: Windows 10 Version 2009
Word size of FreeCAD: 64-bit
Version: 0.21.30058 (Git)
Build type: Release
Branch: master
Hash: cb96332a64db8ae855ca700212eebb0f5151230a
Python 3.8.13, Qt 5.15.4, Coin 4.0.0, Vtk 9.1.0, OCC 7.6.2
Locale: English/United Kingdom (en_GB)
Installed mods: 
  * FeedsAndSpeeds-master 0.4.0