Conversion to Path.Area

[sliptonic]

I've submitted Pull Request 755 for review. This reworks the Contour and PathMillFace operations to use Path.Area instead of the older libarea wrapper and heekscnc python code.

From my use, contour is much more stable and I haven't found a shape that gives it problems yet. MillFace has several new fill patterns available as well

Path.Area is definitely the future of Path and it will take some time to finish converting the other operations but I wanted to get our power users reviewing this as soon as possible.

Please let me know if you see any silly mistakes or obvious bugs.
It might not pass the unit tests yet but should build o.k and run. I'll be checking that next

[roivai]

I tried your branch. I tried to contour this simple shape and I think the path got offset by the tool diameter and not the radius?

2017-05-13-230947_3840x1200_scrot.png (119.8 KiB) Viewed 1719 times

The tool I have selected is 6mm and the two holes are also 6mm in diameter. The contour path seems to be 6mm offset. For comparison, the bore in the middle hole is done with PathHelix and there it clearly shows that it cuts closer to the solid. ToolController is the same for both ops. Did I do something wrong?

[herbk]

Good morning sliptonic, realthunder,
thx for the work and the info. Seams i have to pull out my old laptop (with the mint on it) to try the new things.

The tool I have selected is 6mm and the two holes are also 6mm in diameter. The contour path seems to be 6mm offset.

Somewhere a missing /2 after reading the tool diameter?
Or getting already the radius and take it *2 (like in PathSurface.py) ?

Edit: Did you try it with one of my "problematc shapes" (based on b-splines) to? - or is that a problem which is caused by another component of FC?

Edit edit: a other thing i see on Roivai's pic: one of the rapid pathes seams to be critical. there is a diagonal xz (or yz) movement which will damage the workpeace.

[sliptonic]

The tool I have selected is 6mm and the two holes are also 6mm in diameter. The contour path seems to be 6mm offset.

Somewhere a missing /2 after reading the tool diameter?
Or getting already the radius and take it *2 (like in PathSurface.py) ?

Edit: Did you try it with one of my "problematc shapes" (based on b-splines) to? - or is that a problem which is caused by another component of FC?

Edit edit: a other thing i see on Roivai's pic: one of the rapid pathes seams to be critical. there is a diagonal xz (or yz) movement which will damage the workpeace.

The offset problem still has stumped this morning. It's not the simple case of a doubled radius. I'll find it yet.

Yes, I tested it with your b spline shapes and it worked with all. I'm sure you'll do your best to "raise the bar" though

I'll take a look at the rapid move.

[sliptonic]

My branch has been updated with the latest PathArea which has the offset fix.

[herbk]

My branch has been updated with the latest PathArea which has the offset fix.

Hi sliptonic,
do you know: is it merget to master (daily) also? I don't think so...

[sliptonic]

My branch has been updated with the latest PathArea which has the offset fix.

Hi sliptonic,
do you know: is it merget to master (daily) also? I don't think so...

No. It's not ready yet. Still chasing bugs out.

[roivai]

I used PathContour with master from this morning and noticed that the contour path did not include a return to safe/clearance height after completing the finish depth. After running through linuxcnc post processor, the end of the code looks like this:

Code: Select all

...
G3 X12.7268 Y12.7268 Z1.0000 I-1.3908 J17.9446 F480.0000
G1 X12.7268 Y12.7268 Z0.0000 F120.0000
G3 X-1.3908 Y17.9446 Z0.0000 I-12.7268 J-12.7268 F480.0000
G3 X1.3908 Y-17.9446 Z0.0000 I1.3908 J-17.9446 F480.0000
G3 X12.7268 Y12.7268 Z0.0000 I-1.3908 J17.9446 F480.0000
(finish operation: Contour)
(begin postamble)
M05
G00 X-1.0 Y1.0
G17 G90
M2

This will crash to tool because that position (-1,1) is in the middle of the part.

I suppose this is sort of a bug??

[berka]

@roival,
I found the same issue (luckily) in simulation -- big cut slashing through the part.
G0 Z<safe> is missing.

In my case, I followed it back:
It isn't generated in the contour operation, so
it's missing from my holding tags dress-up, so
it's missing from the post-processed output.


Note: the final G0 to (-1,1) is added at the post processor. (I'm not sure why they didn't chose to return to (0,0).)

[sliptonic]

looks like a bug to me. Please try this:

Add this at line 265 in PathContour.py

Code: Select all

        # Let's finish by rapid to clearance...just for safety
        commandlist.append(Path.Command("G0", {"Z": obj.ClearanceHeight.Value}))