## Vertical Feed rates in partially-vertical cuts

Here's the place for discussion related to CAM/CNC and the development of the Path module.
bill
Posts: 376
Joined: Fri Jan 09, 2015 9:25 pm

### Re: Vertical Feed rates in partially-vertical cuts

Here is a thought

Therefore perpendicular plunging is out in a lot of cases.
Assume all tags are 90 degree. (Worst Case)

Maybe the solution for tags is to:
1) Mill upstream path as normal ramping-UP as desired
2) At MaxTabHeight, continue past the tab + calculated variable downstream of the tab on Path
3) Stop, Reverse feed direction
4) Ramp-DOWN to necessary Z-height and continue upstream until ramp approach
5) Apply ramp-UP as needed to mill chosen tag
6) Stop at Top, change feed direction
7) Return to appropriate location downstream of TAG to continue milling op
chrisb
Posts: 30592
Joined: Tue Mar 17, 2015 9:14 am

### Re: Vertical Feed rates in partially-vertical cuts

That's how it would have been done by hand.
You need at least FreeCAD 0.19.23300 to edit my current sketches.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
berka
Posts: 65
Joined: Sat Aug 22, 2015 9:08 pm

### Re: Vertical Feed rates in partially-vertical cuts

I'm back now; it's been a rough couple of weeks...
chrisb wrote:
Mon Nov 27, 2017 1:18 pm
I am not sure about the objective of your approach. If it is maximizing speed - as OP's issue was all about - or is it kind of smoothness or something else.
My attempt was at consistency. Think about the X-Y plane. On that plane, you're cutting with the "elliptical" solution every day and you don't give it a second thought. In the X-Y case, the ellipse simplifies to a circle so you're always using the same feed rate regardless of angle from X-axis.
chrisb wrote:
Mon Nov 27, 2017 1:18 pm
If it is about smooth start and stop we should think separately about it, because to pin down the acceleration in GCodes would heavily overload the GCode files.
Agreed. I'm not trying to manage acceleration; that's the machine's job.
chrisb wrote:
Mon Nov 27, 2017 1:18 pm
If it is about speed, please have a look at your Excel sheet, e.g. Xcut=20, Zcut=5. The contribs in X and Z directions are only half of their possible max values.
I agree the "linear" solution turns out very conservative -- i.e. always slower. I wouldn't use it, but it sounded to me like other's may. What the linear solution means is that the farther the tool is from horizontal or vertical motion, the more conservative it gets in feed rate. The notion of 'conservative' is probably too general; it would suck to slow down for a material like plastic -- it'll melt. Again, multiple people have pointed out, this needs to be configurable so the user can pick the best for their situation.
chrisb wrote:
Mon Nov 27, 2017 1:18 pm
I think that the error lies in what you call the linear approach. My solution is in fact not following the (blue) linear solution. In your terms it might rather be called a quadratic or rectangular solution, because the speed stays at the maximum of at least one direction. I have added it in magenta to your picture.
You are correct. I'm sorry I glossed over that part too quickly.
I didn't think of the magenta/rectangular solution because it seemed like the general desire was slower rather than faster. It'll be great if the limit is machine-induced and it's OK to feed faster. Again, think of the X-Y plane. It would be a surprise to most people to have feed rates varying based on angle -- up to sqrt(2) faster at 45degrees. That's how a G0 rapid works on my GRBL controller. In any case, it should be an option for the user.

I'll also address the fixed feed rate. That's OK too, but it puts the user at a bind in cuts where the ramp angle is changing. E.g. a helix drill that goes through multiple diameters. There is no one fixed feed rate for that given everything else we've discussed.

My vote is for options:
- Slowest (Pick Vx or Vz)
- Fastest (Pick Vx or Vz)
- Linear solution
- Elliptical solution (My vote for default)
- Rectangular solution
- Custom/Fixed rate

This should apply for any move where both X-Y and Z direction motion is mixed.
berka
Posts: 65
Joined: Sat Aug 22, 2015 9:08 pm

### Re: Vertical Feed rates in partially-vertical cuts

roivai wrote:
Tue Nov 28, 2017 5:47 pm
It now has the dropdown menu and an input field for a custom rate:
@roivai, thanks.

I quickly tested (w/ 2-day old build) and found a couple of issues when trying to use it on an existing design:
- There was no way to enter the new field in an existing ramp entry.
- There was no way to recalculate existing ramp entry:

Code: Select all

``````Traceback (most recent call last):
obj.Path = self.createCommands(obj, self.outedges)
if obj.RampFeedRate == "Horizontal Feed Rate":
<type 'exceptions.AttributeError'>: 'FeaturePython' object has no attribute 'RampFeedRate'``````
You may ignore if already addressed. (Edit: won't fix is OK too since this is between dev versions.)
sliptonic
Posts: 2076
Joined: Tue Oct 25, 2011 10:46 pm
Location: Columbia, Missouri
Contact:

### Re: Vertical Feed rates in partially-vertical cuts

berka wrote:
Tue Dec 05, 2017 11:28 am
roivai wrote:
Tue Nov 28, 2017 5:47 pm
It now has the dropdown menu and an input field for a custom rate:
@roivai, thanks.

I quickly tested (w/ 2-day old build) and found a couple of issues when trying to use it on an existing design:
- There was no way to enter the new field in an existing ramp entry.
- There was no way to recalculate existing ramp entry:

Code: Select all

``````Traceback (most recent call last):
obj.Path = self.createCommands(obj, self.outedges)
if obj.RampFeedRate == "Horizontal Feed Rate":
<type 'exceptions.AttributeError'>: 'FeaturePython' object has no attribute 'RampFeedRate'``````
You may ignore if already addressed. (Edit: won't fix is OK too since this is between dev versions.)
We have not tried to maintain backward compatibility, especially while developing. Just delete the old ramp entry and create a new one.
roivai
Posts: 117
Joined: Thu Feb 02, 2017 5:29 pm
Location: Oulu, Finland

### Re: Vertical Feed rates in partially-vertical cuts

berka wrote:
Tue Dec 05, 2017 11:28 am

@roivai, thanks.

I quickly tested (w/ 2-day old build) and found a couple of issues when trying to use it on an existing design:
- There was no way to enter the new field in an existing ramp entry.
- There was no way to recalculate existing ramp entry:
You may ignore if already addressed. (Edit: won't fix is OK too since this is between dev versions.)
Yes - when new properties are added it tends to break the compatibility with older files. I think this has been the case for many many times during Path development and I don't think its easy to fix in this case.. I think you can quite easily fix this by removing only the rampentry op and recreating it, the original operation underneath should be able to stay as is..

EDIT - exactly what sliptonic just said