Vertical Feed rates in partially-vertical cuts

Here's the place for discussion related to CAM/CNC and the development of the Path module.
herbk
Posts: 1871
Joined: Mon Nov 03, 2014 3:45 pm
Location: Windsbach, Bavarya (Germany)

Re: Vertical Feed rates in partially-vertical cuts

Postby herbk » Sun Nov 26, 2017 11:00 am

What is difficult is the determining the best strategy. I experimented with ramp rates some time back, and I decided that I did not want the full horizontal feed rate. Others clearly have different needs.
yep... in my mind it's not possible to find ONE best strategy for that. So, if you want to calkulate the feedrate of an rampenty by an algorithm, please make it adjustable... :D

But this is one of the minor problems that "Ramp entry" has in that moment... For me a much bigger foult is the behavior, that the path after each round goes back to "Clearance hight" and starts every ramp at "safe hight".
rampentry01.jpg
rampentry01.jpg (66.73 KiB) Viewed 518 times
Gruß Herbert
chrisb
Posts: 27082
Joined: Tue Mar 17, 2015 9:14 am

Re: Vertical Feed rates in partially-vertical cuts

Postby chrisb » Sun Nov 26, 2017 12:24 pm

I just experimented with the ramp for a circular hole and it worked perfectly, which version do you use?
OS: Mac OS X
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.12637 (Git)
Build type: Release
Branch: (HEAD detached at 399dca7)
Hash: 399dca7cb3fb0fe73eed19f1ad72a8986bbf1e5b
Python version: 2.7.14
Qt version: 5.6.2
Coin version: 4.0.0a
OCC version: 7.1.0
Locale: German/Germany (de_DE)
herbk
Posts: 1871
Joined: Mon Nov 03, 2014 3:45 pm
Location: Windsbach, Bavarya (Germany)

Re: Vertical Feed rates in partially-vertical cuts

Postby herbk » Sun Nov 26, 2017 2:01 pm

the Appimage (it's from today)

OS: "openSUSE Leap 42.3"
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.12624 (Git)
Build type: None
Branch: master
Hash: 8ea6b92ea98bced2fcef2d099dd3a6d50ec4290c
Python version: 2.7.6
Qt version: 4.8.6
Coin version: 4.0.0a
OCC version: 7.1.0
Locale: German/Germany (de_DE)

and the Version from OpenSuse science repo:

OS: "openSUSE Leap 42.3"
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.Unknown
Build type: Release
Python version: 2.7.13
Qt version: 4.8.6
Coin version: 3.1.3
OCC version: 7.2.0
Locale: German/Germany (de_DE)


With bouth i have the same behavior, also on circular pockets.
rampentry02.jpg
rampentry02.jpg (44.8 KiB) Viewed 510 times
But you are some commits up, maybe its already fixed.
Gruß Herbert
chrisb
Posts: 27082
Joined: Tue Mar 17, 2015 9:14 am

Re: Vertical Feed rates in partially-vertical cuts

Postby chrisb » Sun Nov 26, 2017 2:56 pm

The Appimage is sometmes not as actual as the PPA. I will get a new version there and report back.
chrisb
Posts: 27082
Joined: Tue Mar 17, 2015 9:14 am

Re: Vertical Feed rates in partially-vertical cuts

Postby chrisb » Sun Nov 26, 2017 3:55 pm

Ok here with Keep Tool down = true. version is 0.17.12643. I cannot post the FreeCAD info, copying between virtual machines makes the browser hang.
Attachments
Bildschirmfoto 2017-11-26 um 16.51.49.png
Bildschirmfoto 2017-11-26 um 16.51.49.png (19.03 KiB) Viewed 499 times
herbk
Posts: 1871
Joined: Mon Nov 03, 2014 3:45 pm
Location: Windsbach, Bavarya (Germany)

Re: Vertical Feed rates in partially-vertical cuts

Postby herbk » Sun Nov 26, 2017 7:43 pm

keep tool down makes no different, but i will see what the next update solves... :D
Gruß Herbert
roivai
Posts: 117
Joined: Thu Feb 02, 2017 5:29 pm
Location: Oulu, Finland

Re: Vertical Feed rates in partially-vertical cuts

Postby roivai » Sun Nov 26, 2017 7:46 pm

Wow, very good discussion going on here. When I wrote the ramp entries, I gave it quite a little thought.. Currently the feed rate is set very simply: if any segment of the path has different starting Z and finish Z, the vertical feed rate will be applied. Not very clever, so I am happy to implement it in better way when some sort of conclusion is reached how it should be done. :D I think my favorite is that the feed rate is set so that the speed of the Z movement is set to the desired vertical feed rate, so basically the resulting speed along the ramp is 1/sin(angle)*vertical_feed, right? Of course that must be limited if it exceeds the set horizontal feed rate. If I understood right, that is what chrisb said in the pdf with a bit different perspective?
herbk wrote:
Sun Nov 26, 2017 11:00 am
But this is one of the minor problems that "Ramp entry" has in that moment... For me a much bigger foult is the behavior, that the path after each round goes back to "Clearance hight" and starts every ramp at "safe hight".
Yes - this is something that is inherent to the the current algorithm. What it does is that it searches for any non-rapid paths which go straight down on Z axis and turns that into the ramp. And it seems that some (all?) Path operations generate a path where the full travel from clearance/safe height (I get confused with these) to the current operating depth is issued with G1. At the current implementation of the Path operation & dressup functionality, the dressup does not know pretty much anything from the PathOp, except for the actual generated Path. So for the dressup it is difficult/impossible to guess which of the Z moves are supposed to be not ramped - the only way to check is that if the move is rapid or not.. Something could be guessed from the stock object for example, but probability of guessing wrong is quite large. So the best way would be that the operations would be implemented so that the rapid would be stopped just before the tool touches the stock and not before. Good luck doing that in practice. ;)

All ideas on making this better are very welcome.
herbk wrote:keep tool down makes no different, but i will see what the next update solves... :D
I think nothing has been done for ramp dressup for the last three months, so I'm afraid it solves nothing..

Pekka
herbk
Posts: 1871
Joined: Mon Nov 03, 2014 3:45 pm
Location: Windsbach, Bavarya (Germany)

Re: Vertical Feed rates in partially-vertical cuts

Postby herbk » Sun Nov 26, 2017 9:09 pm

Hi Pekka,

keep tool down eliminates (did it sometimes before for me to...) the not needed up and down. If the tool is not going up, ramp entry calculates the angle from the right level and it works correct.
so I am happy to implement it in better way when some sort of conclusion is reached how it should be done.
In my mind a lot of "softly" materials (like wood, plastics or foam) don't need a reduced horizontal feedrate on a ramped path.
And also Gene is right, that on stronger matrials there is a need for reducing the horizontal feedrate for not getting the tool to hot.

We will never be able to respect all situations which could be, because we don't know each... So i think the best would be a option to set the feedrate on a ramp for the user. Standard could be a save setting (like it's now), but changable up to the full feedrate.
I dont't work with steel, espacialy not stainless, so i ask Gene: How much you goes down with the horizontal feedrate on a ramp entry, comparing with the feedrate of a non ramped horizontal cut? And do you know materials which are needing a more reduced speedrate as stainless steel?
Gruß Herbert
berka
Posts: 43
Joined: Sat Aug 22, 2015 9:08 pm

Re: Vertical Feed rates in partially-vertical cuts

Postby berka » Sun Nov 26, 2017 10:18 pm

chrisb wrote:
Sun Nov 26, 2017 10:40 am
It looks intriguing, however, it leads to speeds which are too high:
I was suspicious I forgot a ^2 or sqrt somewhere...
Unfortunately, I'm having a total trigonometric blackout moment right now, and I can't see it!!!
I will think about it some more...
GeneFC
Posts: 1456
Joined: Sat Mar 19, 2016 3:36 pm
Location: Punta Gorda, FL

Re: Vertical Feed rates in partially-vertical cuts

Postby GeneFC » Mon Nov 27, 2017 12:34 am

roivai wrote:
Sun Nov 26, 2017 7:46 pm
When I wrote the ramp entries, I gave it quite a little thought.
I have not analyzed the helix function, but I use it a lot, and it works very well for me as it currently exists.

Gene