Path.Area: Welcome, to the new era!

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!
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: Path.Area: Welcome, to the new era!

Post by realthunder »

sliptonic wrote:Yes. That will work but vFeed and hFeed need to be separate.
What GCode controls the feedrate separately? All I found is one F in G1?

BTW, please checkout my PathArea branch. It's a new one, it'll be better if you do a fresh checkout. I've added step down handling. A new parameter 'orientation'' in Path.fromShapes controls the move direction. 0 no control, 1 CW, 2 CCW. CW/CCW refers to the outer loop direction. Inner loop (holes) direction is reversed. The same parameter is exposed to PathShapeFeature, so you can play around using GUI. I am in the process of adding the straight line pattern.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
chrisb
Veteran
Posts: 53945
Joined: Tue Mar 17, 2015 9:14 am

Re: Path.Area: Welcome, to the new era!

Post by chrisb »

realthunder wrote:
sliptonic wrote:Yes. That will work but vFeed and hFeed need to be separate.
What GCode controls the feedrate separately? All I found is one F in G1?
It's not the GCode that makes the difference, it's the use case. Most mills are designed to mill horizontal, some are designed to work vertical as well but usually with slower speed. If GCode is programmed by hand it is no problem, because you can simply write the speed in the vertical movememnt command and change it back later.
We could do the same in FreeCAD Path WB using two Tool Controllers. But: since the Tool Controller is a represantation of the tools capabilities it is not only a matter of convenience to have both speeds in the tool controller, but it is a clear concept too. It models the fact that a specific tool/material combination (usually) has specific speeds in vertical and horizontal movements.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: Path.Area: Welcome, to the new era!

Post by realthunder »

chrisb wrote:It's not the GCode that makes the difference, it's the use case.
Yes, I can see that. But you are talking about the end-user point of view. But Path.Area here is meant for developers. Will it be enough if I just expose one 'F' parameter in Path.fromShapes for feedrate control? I think the calling Path script, with the knowledge of tool configuration you just mentioned, should know when to use what feedrate, and generate a different Path if a different feedrate is required. Unless, the vertical feedrate sliptonic mentioned is specifically for the step down motion? Is that a thing?
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
User avatar
sliptonic
Veteran
Posts: 3457
Joined: Tue Oct 25, 2011 10:46 pm
Location: Columbia, Missouri
Contact:

Re: Path.Area: Welcome, to the new era!

Post by sliptonic »

realthunder wrote:
chrisb wrote:It's not the GCode that makes the difference, it's the use case.
Yes, I can see that. But you are talking about the end-user point of view. But Path.Area here is meant for developers. Will it be enough if I just expose one 'F' parameter in Path.fromShapes for feedrate control? I think the calling Path script, with the knowledge of tool configuration you just mentioned, should know when to use what feedrate, and generate a different Path if a different feedrate is required. Unless, the vertical feedrate sliptonic mentioned is specifically for the step down motion? Is that a thing?
Machine controllers like linuxcnc will cache the feed rate associated with vertical motion separately from horizontal motion. So in a gcode block like

Code: Select all

G1 X20 F100
G1 Z10 F80
G1 Y10 (this move will be performed at F100)
G1 Z5  (this move will be performed at F80) 
G1 X25 (this move will be performed at F100
I believe all blended moves are done at the horizontal feed rate.
So I think
G1 X10 Y50 Z2 would be done at F100. I'm sure someone will correct me if that's wrong.

Thus when I call PathArea, I either need to tell you what F-rate to use for the vertical and horizontal rates separately and you apply it to at least the first move (or all horizontal and vertical moves) or I have to parse the content, find the appropriate moves, and add the F parameters. In the old heeks python code, we passed the feed rates to the routines that called libarea and they were added to the returned gcode. I'm open to discussion but obviously, from my perspective it's easier if you do it. :-)
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: Path.Area: Welcome, to the new era!

Post by realthunder »

sliptonic wrote:Machine controllers like linuxcnc will cache the feed rate associated with vertical motion separately from horizontal motion.·
That assumption may not hold true for other controller. So here is what I am going to do. I'll expose hF, and vF parameters. If vF is non-zero, I'll explicitly set vF for each Z only move, and set back hF for other move. How is it?
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
User avatar
sliptonic
Veteran
Posts: 3457
Joined: Tue Oct 25, 2011 10:46 pm
Location: Columbia, Missouri
Contact:

Re: Path.Area: Welcome, to the new era!

Post by sliptonic »

realthunder wrote:
sliptonic wrote:Machine controllers like linuxcnc will cache the feed rate associated with vertical motion separately from horizontal motion.·
That assumption may not hold true for other controller. So here is what I am going to do. I'll expose hF, and vF parameters. If vF is non-zero, I'll explicitly set vF for each Z only move, and set back hF for other move. How is it?
Sounds right to me.
GeneFC
Veteran
Posts: 5373
Joined: Sat Mar 19, 2016 3:36 pm
Location: Punta Gorda, FL

Re: Path.Area: Welcome, to the new era!

Post by GeneFC »

sliptonic wrote:
Machine controllers like linuxcnc will cache the feed rate associated with vertical motion separately from horizontal motion. So in a gcode block like

G1 X20 F100
G1 Z10 F80
G1 Y10 (this move will be performed at F100)
G1 Z5 (this move will be performed at F80)
G1 X25 (this move will be performed at F100


I believe all blended moves are done at the horizontal feed rate.
So I think
G1 X10 Y50 Z2 would be done at F100. I'm sure someone will correct me if that's wrong.
Yep, I am pretty sure that is incorrect. I believe there is only a single modal variable for feed rate in the standard version of LinuxCNC. I just tried an experiment based on your code, and it did not work as proposed. Any movement always took the most recent feed rate, regardless of previous or current axis of motion.

There is all sorts of magic in blended rates for simultaneous 3D motion, but there is still a single feed rate scale factor.

Gene
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: Path.Area: Welcome, to the new era!

Post by realthunder »

sliptonic wrote:Sounds right to me.
I've added 'feedrate' and 'feedrate_v' parameter to Path.fromShapes. Please sync with my branch. 'feedrate_v', if non-zero, is for vertical only movement by default. For a cone shape thing like the picture below, you can get the same thing by setting 'tolerance' >= stepdown.
Screenshot from 2017-04-05 14-14-10.png
Screenshot from 2017-04-05 14-14-10.png (25.73 KiB) Viewed 1979 times
I also added 'verbose' parameter to fromShapes, which defaults to 'true'. This will cause each motion GCode to include complete coordinate and feed rate information regardless of the current state, so you can easily get the full information from the GCode shown in the status bar when preselecting any Path in 3D view.

BTW, could you please send me some sample lathe GCode from Heeks or other CAM. From the lathe milling videos I saw, it seems that those pattern are not just simple straight lines.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
mlampert
Veteran
Posts: 1772
Joined: Fri Sep 16, 2016 9:28 pm

Re: Path.Area: Welcome, to the new era!

Post by mlampert »

I'm not sure if the picture represents an actual path - but I would highly recommend NOT to send that to your CNC machine .... ;)
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: Path.Area: Welcome, to the new era!

Post by realthunder »

mlampert wrote:I'm not sure if the picture represents an actual path - but I would highly recommend NOT to send that to your CNC machine .... ;)
Just an illustration obviously :D . Basically, it is when slopes are involved, so the contour or pocket path of two consecutive layers do not coincide, which means the step down path may not be straight down. Actually, I am not sure whether this is a thing or not, with my limited experience in CNC.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
Post Reply