[Fixed] bug: start points

[spontarelliam]

When setting start points, rapid moves are omitted, and the tool move in a direct path from it's previous location, to the start point. The tool should lift to the safe height, rapid move to above the start point, then begin cutting toward the start point. You can try to avoid a crash by setting the start point to a very high Z position, but even then you're likely to crash your part at least a little bit.

In the attached file, there's something even more complicated happening and I'm not sure what's even going on. There are two paths toward the start point of the profile operation. One comes from the origin, and one from the previous adaptive operation. Both show the same problem of not incorporating safe rapid moves, but I don't know why there are two moves to the same position.

freecad_start_point_movement.png (220.26 KiB) Viewed 1570 times

Here's a photo of it happening on a real part, where the tool moved from an adaptive operation to a profile with a start point. You can see the tool made a cut from the top of the adaptive hole, down toward the start point of the sprocket perimeter.

20200417_113038.jpg (264.93 KiB) Viewed 1570 times

OS: Manjaro Linux (XFCE/xfce)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.20343 (Git)
Build type: Release
Branch: fcsprocket
Hash: 6819285148dfab2c1dba0febc78744b8efbe95c6
Python version: 3.8.2
Qt version: 5.14.1
Coin version: 4.0.0
OCC version: 7.4.0
Locale: English/United States (en_US)

[Russ4262]

Evening Sir,
Sorry for the trough in your part. I'm looking into the code to identify where this missed retraction is occurring.

The lack of retraction appears to be wrapped up in the set of gcode commands returned in the following call in the PathAreaOp module.

Code: Select all

Line 272        (pp, end_vector) = Path.fromShapes(**pathParams)

I'm working on looping through the first few commands returned (`pp.Commands`) to identify the first gcode command with a `Z` component. I hope to extract that command's corresponding `X Y` target and insert an additional `X Y` command as the first move, without the `Z` component.

I'll post back when I have a solution, or someone who does.

Russ

[Russ4262]

Evening Sir,

...You can see the tool made a cut from the top of the adaptive hole, down toward the start point of the sprocket perimeter.
...

We have a fix. I'll submit the fix and edit this post with the PR info.
Before and after photos attached.

Please keep in mind the Z height of the Start Point is respected. Perhaps we need to set the default Z height for the start point to clearance height, as a reminder for users to consider the Z height also when entering a start point.

@mlampert, @etrombly: If either of you would like to fix this on the C++ side, I think that would be the best place for it. The python side works, but it feels like it belongs in original Path.fromShapes() code. I looked in App/AppPathPy.cpp, but the mention of fromShapes() there pointed to another function elsewhere.

@mlampert, @etrombly: FYI, an additional issue exists(not fixed here) when the start point is (0, 0, zVal). Path.fromShapes() fails to issue a full `G0 X0.0 Y0.0` command. instead only a `G0` command is issued. The `G0 ZzVal` command is correctly issued regardless.

EDIT: PR #3360 is submitted.
EDIT: PR #3360 was superceded by PR# 3389 by @etrombly, and that merged.

Russ

OS: Windows 10 (10.0)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.20605 +1 (Git)
Build type: Release
Branch: All_Three
Hash: 733905010f59fd21124e16d03e5a7a250f8411e1
Python version: 3.6.8
Qt version: 5.12.1
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/United States (en_US)

[etrombly]

I think I have this fixed if people could test this branch https://github.com/etrombly/FreeCAD/tree/startPoint . I didn't check if it works correctly with rotation, and I changed one of the resume heights to a retraction height, which I'm not sure was correct. It looks like it generates the correct path now for both start point set or not.

[etrombly]

This should be fixed now in https://github.com/FreeCAD/FreeCAD/pull/3389

[RatonLaveur]

I would like to add that I checked the file offered in OP and while not exactly the same toolpath as that shown in the (by the way nice!) picture of the gear, it shows the same issue of digging directly towards the startpoint of the profile.

By this I'd like to remind the OP that there is an effective simulation tool in path. It is extremely important to check and double check your tool paths before the carbide meets the metal! If you take shortcuts, so will the machine.

[Russ4262]

Afternoon Sir,

ping

If you will, please verify this is fixed in the master - I don't know as of this posting if the weekly binary builds have caught up to it - and edit the title of the post to include a "[Fixed]" tag if it is so.

Thanks for reporting it.

Russell

[spontarelliam]

Looks great, thank you both for fixing this!