FADAL's Advanced Feed Forward - AFF

there is a lot about this here already:
http://www.cnczone.com/forums/fadal/...rking-dnc.html

I'm trying out AFF for the first time right now, and have it coded into my post processor to turn it on, and choose parameters, etc.

AFF is actually just making the motion jerky and the toolpaths slower. I'm not sure what to think. It is my understanding that AFF is FADAL's offering for high speed machining. Beyond that vague description, it seems that it really is giving you access to variables that allow you to 'tune' the machine to specific applications.

This being said, I think it may have been designed with simple toolpaths in mind. Trochoidal paths like trumill / volumill / imachining do a lot of fancy feed rate changes and so on - and the fadal just seems to get slower when running AFF with that kind of path. maybe it will be more beneficial for 3D contouring? I really don't know.

It seems though, that this is going to be a very long trial and error process, and the conclusion might just be that the machine runs better without AFF anyhow. Good thing I didn't pay a whole lot for the boards (compared to what I can imagine fadal charged for this option). I need to learn how to use it to my advantage. Right now it pretty much sucks.

Anybody using AFF out there?

in addition to M94.2 (AFF) I also coded my post to spit out M94.1 (feed rate modifications based on angular change) - this doesn't work at all with toolpaths that change feeds often., and I also set up my most to do M90 thru M93 gain changes based on feed rate. Setting the machine to higher gain just seems to make the motion really jerky and seems very hard on the machine.

Unfortunately I spent a solid 8 hour day programming these 'advanced' tool sets into my post, and at the end of the day I am shutting all of those features off. wtf.

I think I've got this AFF stuff figured out. It doesn't work with G2/G3 at all - you have to export the code HSM style with all small linear moves strung together. Then it works great - the machine can make crazy moves without 'booming' based on the ramp settings. I haven't had any trouble with it not keeping up either so far, and I'm running over DNC.

This seems to be an advantage vs. the arc moves because the control has to crunch the arc moves and will operate slower. So running the small linear pieces, accompanied by AFF to smooth over the motion seems to be pretty great.

I talked with David at i-t-s, who worked on AFF during it's development. He explained that AFF basically lets you to control the amount of following error that is allowed - so if you're roughing you can let it have like 0.012" of following error where the control is allowed to 'cut the corner' to that programmable extent. Then during a finishing pass you set the following error much lower, to like 0.0002", and if the control goes into a corner or other big angle change, it will actually make the toolpath wait until the following error tolerance has been achieved - so it won't cut corners.

without using aff, the control will begin executing the next move maybe ahead of time if you're running a high feedrate and will cut the corner. AFF just provides a way to control the amount of error you can deal with and that may imply faster cycles if the allowed error is big, and it may imply slower cycles for higher accuracies.

one thing that I don't know about is over-shoot. it seems that AFF assumes that there will be no overshoot, and its basically up to you to choose appropriate gain settings (M90, not associated with AFF), and to choose appropriate ramping (aff accel and decel) parameters to make sure that you don't overshoot.

so if you can find settings that don't overshoot, you use all G1 moves, and you run with AFF enabled - the machine performs like a champ. It's pretty cool. I'll need to test it out on some mold type surfacing, maybe with and without aff to see if the machine behaves differently in each case - it should where at a high feed rate and no aff, it may overshoot due to lack of ramping control.


AFF is not: spline interpolation or nurbs interpolation (maybe see fanuc for these $$ and modern options?) - it cannot look ahead and interpolate / fill in more data points to the motion that aren't directly programmed. Haas' high speed machining option does do this - it can make more points out of what you give it, which in theory increases the possible detail. I'm not sure what else the haas software does, but it probably has some kind of look ahead ramping too. But, at least AFF lets you modify how the control deals with high speed machining in the form / level of detail that you feed it.

I did a test of a trochoidal toolpath using AFF with all G1 moves vs. not AFF with G2/G3 allowed.

The toolpath with AFF runs 6% slower than the one with arcs allowed and no AFF.

That being said, the path using all G1 and AFF is much more smooth, it seems to be under much better motion control. I had to make a LUT of feedrate vs. helical angle / z delta to get my fadal to do the trochoidal paths because if you just let it go as the cam wants to, the fadal gives 'helical ramp too short' errors or something like that - meaning that it cannot interpolate the helix at the high feedrate. So the program will go especially for finishing / rest material paths that it feeds up to the helix at like 150ipm, then I have to instantly program a G9 and an F5, or F2, during a small helix, then reprogram the G8 and F150. I doubt that the control is really able to do this in reality - it probably just doesn't throw an error and the motion probably has a huge error on it. using this method the motion overall isn't quite jerky, but there are plenty of smaller booms still (down from clearly destructive booms and many errors when there is no LUT applied). I've been running like that for about a year. I was also told that G9 doesn't even take effect for something like 0.1" beyond where you program it due to the buffer, and due to high feed rates - so programming the G9, helix and F_low, G8 in reality doesn't do squat. interesting stuff

with all G1 moves + aff, there is no feedrate LUT, g9/g8, or other post processor nonsense required, the moves are really smooth, and the cycle time isn't much longer (and maybe I can shorten it by changing the aff ramp parameters).

Thanks for posting this. It'll be useful to me I think. If I don't fungus it us! lol:cheers:

Hi

I have Fadal vmc xt15 year of 1996. I updated hes memory
To 8mb memory board and same time replaced the software version
To sys103.5. We use Solidworks for cad and
Edgecam for cam. We use lot of time high feed milling
With 7000mm/min speed and many times the machine bumping on
Corner. And overshoot. We have to create special toolpath to get out
The bumping. I am interested to put aff board in machine if this silved
My problem.
Can we speak about your experience before i buy?
The aff reduce the speed before the corner and speed up after the corner?
What is the situation if radius on corner? Same slow down and speed up?
Works only with G01 code?


Thanks Tom

Quote:

---

Originally Posted by mflux_gamblej

I did a test of a trochoidal toolpath using AFF with all G1 moves vs. not AFF with G2/G3 allowed.

The toolpath with AFF runs 6% slower than the one with arcs allowed and no AFF.

That being said, the path using all G1 and AFF is much more smooth, it seems to be under much better motion control. I had to make a LUT of feedrate vs. helical angle / z delta to get my fadal to do the trochoidal paths because if you just let it go as the cam wants to, the fadal gives 'helical ramp too short' errors or something like that - meaning that it cannot interpolate the helix at the high feedrate. So the program will go especially for finishing / rest material paths that it feeds up to the helix at like 150ipm, then I have to instantly program a G9 and an F5, or F2, during a small helix, then reprogram the G8 and F150. I doubt that the control is really able to do this in reality - it probably just doesn't throw an error and the motion probably has a huge error on it. using this method the motion overall isn't quite jerky, but there are plenty of smaller booms still (down from clearly destructive booms and many errors when there is no LUT applied). I've been running like that for about a year. I was also told that G9 doesn't even take effect for something like 0.1" beyond where you program it due to the buffer, and due to high feed rates - so programming the G9, helix and F_low, G8 in reality doesn't do squat. interesting stuff

with all G1 moves + aff, there is no feedrate LUT, g9/g8, or other post processor nonsense required, the moves are really smooth, and the cycle time isn't much longer (and maybe I can shorten it by changing the aff ramp parameters).

---

G8/G9 is bad, just dont even use it. I did a post mod for my solidcam where i would change the ramp mode around, but the fadal control just doesnt work fast enough. I have an AFF board. it sucks. its just too old. the control cannot process enough G1 moves to go faster than about 70 IPM at 0.004" G1 resolution to not overrun the buffer even if running from internal memory.

i have a lot better luck simply letting your cam output arcs, and don't futs with the G8/G9 thing. just leave it G8 (not absolute stop).

the other thing that I did do, was my post is modded such that when there is an imachining tool path I have it modify the feed rate output by my cam so to avoid the 'helical ramp too steep' error. thats just trial and error to see what ratio of feedrate, z change, and arc radii the fadal control can handle.

also, just use those type of adaptive milling cuts for roughing and leave 0.01" on wall and floor, finish feed at lower rates like 50IPM max.

also you need to tune your servos, maybe get your machine ball bar checked.

Hi

I got my aff card last week. Working fine when only g1
Mooves i have. The feed parameter its procent? Example if the high feed milling is 300ipm then feed settings on 50 by offset whats happend?
I changed the feed but i not realized any different?
Lookat my videos: its seco 2incs dia high feed cutter run
300ipm. Gain 100 , accel 200, decel 600, detail .05 (mm)
Looks sexy moove. Feed settings is not clear for me yet.

https://vimeo.com/235007887
Password :7000

Thanks Tom

Quote:

---

Originally Posted by mflux_gamblej

also, just use those type of adaptive milling cuts for roughing and leave 0.01" on wall and floor, finish feed at lower rates like 50IPM max.

also you need to tune your servos, maybe get your machine ball bar checked.

---

Quote:

---

Originally Posted by Tomeeii

Hi

I got my aff card last week. Working fine when only g1
Mooves i have. The feed parameter its procent? Example if the high feed milling is 300ipm then feed settings on 50 by offset whats happend?
I changed the feed but i not realized any different?
Lookat my videos: its seco 2incs dia high feed cutter run
300ipm. Gain 100 , accel 200, decel 600, detail .05 (mm)
Looks sexy moove. Feed settings is not clear for me yet.

https://vimeo.com/235007887
Password :7000

Thanks Tom

---

Hey this looks pretty cool. It looks like your G1 moves are very long like many inches long. AFF may work well for that type of move. I think one of the key things is the buffer length. if you set the buffer away from 256 and down to like 32 or something low, I think you'll get the AFF to make programmed changes faster. I was told by Dave Decaussin at one point on the phone that any G8/G9, AFF, or M codes for gain otherwise won't even take effect until the buffer is used up after you code that line. so if your buffer is 256, then you program AFF on, it wont even turn on until 256 lines later in the program.

Fadal released this AFF feature with the intent of avoiding gouges especially for 3D contours / mold makers. The style of programs back then must have been just different. maybe some guys could run 0.01" long G1 moves and get a decent finish? I dont have a lot of ball end surfacing experience really. Mainly I run solidcam imachining as mentioned in previous posts - its the typical trochoidal style that everyone runs now. There's a lot of helical moves and small radii at high feed rate. If you run 0.004" long G1 moves, the buffer will run out and the machine will just jerk along while the buffer on the screen reads like 2 and it is starved for data. This is true whether u run DNC or from internal memory.

With big G1 moves, I bet AFF does work, especially if you turn it on as the first line in your program. You may consider changing the buffer setting down to a low number like 16 or 32 to make sure you're AFF code gets executed when you intended.

I had a big problem with AFF and rigid tapping that is worth mentioning. You cannot rigid tap with AFF turned on. The spindle will shoot fwd then stop then shoot then stop and jerk really bad. It's crazy. You have to make sure to understand and control your buffer. The really crazy thing is that when run from internal memory, the fadal control will look ahead back into the start of the program when you're down near the end of the program. its insane. it means that if you're on the last few lines, say tapping a hole at the end of a program, the control will look ahead back into the top of the program and turn on AFF which may have been programmed at the top of the program. wtf. I ended up doing a macro code #WAIT which forces the buffer to stop looking ahead. I put the #WAIT command just before calling AFF. the trouble is that if you program a lot of small G1 moves after that command the buffer will be empty and the control will be data starved.

overall its a ****ty situation and the real solution is to get a new control. the fadal control is great for a whole lot of reasons. but these days its too slow. AFF has it's place I think, and you may have found a good application for it. Big G1 moves. just control your buffer and i think you're good to go.

Hi

U give me bunch of information. I have to read well
Tomarow morning in my office. Thanks you are
Really good person! I like u. I have buffer set low on
Setp like 16 or less. I have 8mb internal memory.
We own solidworks 2017 prof for cad and solid edcam for cam.

The rigid tapping is same as thread cutting?
So when we use M3 thread cutter never activated

Yes the parts on video is like 12inch wide and 17inch long
Big aluminium block . Its specal designed for rainproof
Outdoor laser projector case. Would be nice to share
With me your email address. My is [email protected]

We are international company USA headqueter and
European factory.

Thanks Ton

Thanks Tom

Quote:

---

Originally Posted by mflux_gamblej

Hey this looks pretty cool. It looks like your G1 moves are very long like many inches long. AFF may work well for that type of move. I think one of the key things is the buffer length. if you set the buffer away from 256 and down to like 32 or something low, I think you'll get the AFF to make programmed changes faster. I was told by Dave Decaussin at one point on the phone that any G8/G9, AFF, or M codes for gain otherwise won't even take effect until the buffer is used up after you code that line. so if your buffer is 256, then you program AFF on, it wont even turn on until 256 lines later in the program.

Fadal released this AFF feature with the intent of avoiding gouges especially for 3D contours / mold makers. The style of programs back then must have been just different. maybe some guys could run 0.01" long G1 moves and get a decent finish? I dont have a lot of ball end surfacing experience really. Mainly I run solidcam imachining as mentioned in previous posts - its the typical trochoidal style that everyone runs now. There's a lot of helical moves and small radii at high feed rate. If you run 0.004" long G1 moves, the buffer will run out and the machine will just jerk along while the buffer on the screen reads like 2 and it is starved for data. This is true whether u run DNC or from internal memory.

With big G1 moves, I bet AFF does work, especially if you turn it on as the first line in your program. You may consider changing the buffer setting down to a low number like 16 or 32 to make sure you're AFF code gets executed when you intended.

I had a big problem with AFF and rigid tapping that is worth mentioning. You cannot rigid tap with AFF turned on. The spindle will shoot fwd then stop then shoot then stop and jerk really bad. It's crazy. You have to make sure to understand and control your buffer. The really crazy thing is that when run from internal memory, the fadal control will look ahead back into the start of the program when you're down near the end of the program. its insane. it means that if you're on the last few lines, say tapping a hole at the end of a program, the control will look ahead back into the top of the program and turn on AFF which may have been programmed at the top of the program. wtf. I ended up doing a macro code #WAIT which forces the buffer to stop looking ahead. I put the #WAIT command just before calling AFF. the trouble is that if you program a lot of small G1 moves after that command the buffer will be empty and the control will be data starved.

overall its a ****ty situation and the real solution is to get a new control. the fadal control is great for a whole lot of reasons. but these days its too slow. AFF has it's place I think, and you may have found a good application for it. Big G1 moves. just control your buffer and i think you're good to go.

---