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
Vertical Feed rates in partially-vertical cuts
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: Vertical Feed rates in partially-vertical cuts
That's how it would have been done by hand.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: Vertical Feed rates in partially-vertical cuts
I'm back now; it's been a rough couple of weeks...
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.
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.
Agreed. I'm not trying to manage acceleration; that's the machine's job.
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.
You are correct. I'm sorry I glossed over that part too quickly.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.
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.
Re: Vertical Feed rates in partially-vertical cuts
@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'
- sliptonic
- Veteran
- Posts: 3457
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Re: Vertical Feed rates in partially-vertical cuts
We have not tried to maintain backward compatibility, especially while developing. Just delete the old ramp entry and create a new one.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.)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'
Re: Vertical Feed rates in partially-vertical cuts
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..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.)
EDIT - exactly what sliptonic just said