Vertical Feed rates in partially-vertical cuts

[bill]

Here is a thought

Many end-mills typically have dead-centers
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]

That's how it would have been done by hand.

[berka]

I'm back now; it's been a rough couple of weeks...

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.

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.

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.

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]

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):
File "/Applications/3D CAD/FreeCAD unstable 20171202.app/Contents/Mod/Path/PathScripts/PathDressupRampEntry.py", line 107, in execute
obj.Path = self.createCommands(obj, self.outedges)
File "/Applications/3D CAD/FreeCAD unstable 20171202.app/Contents/Mod/Path/PathScripts/PathDressupRampEntry.py", line 524, in createCommands
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]

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):
File "/Applications/3D CAD/FreeCAD unstable 20171202.app/Contents/Mod/Path/PathScripts/PathDressupRampEntry.py", line 107, in execute
obj.Path = self.createCommands(obj, self.outedges)
File "/Applications/3D CAD/FreeCAD unstable 20171202.app/Contents/Mod/Path/PathScripts/PathDressupRampEntry.py", line 524, in createCommands
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]

@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