Conversion to Path.Area
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
- sliptonic
- Veteran
- Posts: 3459
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Conversion to Path.Area
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
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
Re: Conversion to Path.Area
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?
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?Re: Conversion to Path.Area
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.
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.
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.
Somewhere a missing /2 after reading the tool diameter?The tool I have selected is 6mm and the two holes are also 6mm in diameter. The contour path seems to be 6mm offset.
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.
- Attachments
-
- Traeger_mittelteil.fcstd
- (253.09 KiB) Downloaded 32 times
Gruß Herbert
- sliptonic
- Veteran
- Posts: 3459
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Re: Conversion to Path.Area
The offset problem still has stumped this morning. It's not the simple case of a doubled radius. I'll find it yet.herbk wrote:Somewhere a missing /2 after reading the tool diameter?The tool I have selected is 6mm and the two holes are also 6mm in diameter. The contour path seems to be 6mm offset.
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.
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
- Veteran
- Posts: 3459
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Re: Conversion to Path.Area
My branch has been updated with the latest PathArea which has the offset fix.
Re: Conversion to Path.Area
Hi sliptonic,sliptonic wrote:My branch has been updated with the latest PathArea which has the offset fix.
do you know: is it merget to master (daily) also? I don't think so...
Gruß Herbert
- sliptonic
- Veteran
- Posts: 3459
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Re: Conversion to Path.Area
herbk wrote:Hi sliptonic,sliptonic wrote:My branch has been updated with the latest PathArea which has the offset fix.
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.
Re: Conversion to Path.Area
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:
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??
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
I suppose this is sort of a bug??
Re: Conversion to Path.Area
@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).)
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
- Veteran
- Posts: 3459
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Re: Conversion to Path.Area
looks like a bug to me. Please try this:
Add this at line 265 in PathContour.py
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}))