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.