Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
Largest Manufacturing Technology Community on the Web
Stay Connected:
Inverse time question
- Thread starter Mtndew
- Start date
- Replies 28
- Views 6,136
gkoenig
Titanium
- Joined
- Mar 31, 2013
- Location
- Portland, OR
Higher inverse time feed rates = faster feed rates.
Hence the "inverse" part, which I think they did just so that it would be more intuitive (bigger number == faster). The basic concept is simple enough, but the inverse business tends to confuse the hell outta folks.
Hence the "inverse" part, which I think they did just so that it would be more intuitive (bigger number == faster). The basic concept is simple enough, but the inverse business tends to confuse the hell outta folks.
That's what I thought!
I only question that because it seems that my Genos goes slower on higher G93 values. I've been pulling my hair out trying to figure out why it's crawling around my part. But on a straight A move it's super fast.
thesidetalker
Stainless
- Joined
- Jan 11, 2015
- Location
- Bay Area, CA
Increasing the length of your line segments would decrease the inverse time feedrate.
gkoenig
Titanium
- Joined
- Mar 31, 2013
- Location
- Portland, OR
It might not be G93 that is the problem, it could also be HiCut Pro clamping down feed rates, or getting some funky motion, around the very short path segments that drive the higher feed rate numbers.
The funky thing about G93 is that the relationship between velocity and the feed rate number isn't constant. In standard G94, the velocity of the tool on a .001" block versus a 10.000" block is identical. In inverse time, the feed rate is a function of the path length. Then you add path smoothing and accel/decel control (HiCut Pro) to the mix, and you add a lot more complexity.
imachine909
Cast Iron
- Joined
- May 17, 2010
- Location
- South East
I have never ran Genos control so this might be a silly question. But in general what's the advantage of using G93 over G94?
Rick Finsta
Stainless
- Joined
- Sep 27, 2017
In G93 the control doesn't need to know where the part is relative to the dynamic center of movement.
imachine909
Cast Iron
- Joined
- May 17, 2010
- Location
- South East
So what about this makes a better/faster part than G94?
gkoenig
Titanium
- Joined
- Mar 31, 2013
- Location
- Portland, OR
In G94 (Feed Per Minute) part of the block processing involves calculating the line length of the move and figuring out the precise servo commands to get the tip of the tool to hold that velocity over the travel distance.
Once you add a rotation move, the control no longer knows the linear distance that tool tip will move. If the part is a .25" rod in a chuck rotating around the centerline, a 5 degree cut only moves the tool tip .0109". If you have a piece of 3" stock in the same setup, a 5 degree cut moves 0.4363". Older, or non-multiaxis controls do not know where the center of rotation is, so they can't calculate the velocity necessary to execute a G94 commanded feed rate.
The older methods of getting around that are Inverse Time Feed or Degrees Per Minute programming. Your CAM software (which knows where the center of rotation is) back-calculates the linear motion length for each block of code, and puts an F number on each of those blocks. You can also do this by hand, which seems monotonous.
In DPM, the CAM figures out the velocity of the rotary moves (in... degrees per minute) and puts that on each line of code with any rotary motion. The control just moves the linear axes at their standard (G94) feed, and twiddles the rotary at the commanded speed.
Inverse Time Feed is really just "time feed," where the CAM figures out exactly how many seconds the cut should take for all axes, and the control just moves them at the proper velocity so they all reach the block end point at the same time. The inverse part is where this gets confusing; the CAM software figures out the speed in minutes, then divides that by 1 to inverse the numbers. The inverse part happens because otherwise, smaller numbers would be faster, and really short blocks would have F values of like 0.00002302.
Both DPM and Inverse TIme Feed already run into issues where most controls can only take F values at a maximum of 9999.9999. With G93 and DPM, when you get into complex geometry, the line segments get extremely short (like 0.0005" length of cut command blocks). Shorter segments means really high feedrate numbers for cuts with even moderate feed rates. As such, you'll bump into all sorts of issues doing serious multi-axis finishing work with these techniques.
The modern solution on any serious multi-axis control is Tool Center Point Control. With this, the machine controller knows exactly where it's centers of rotation are, and has the horsepower to do all these back calculations in real time. With TCPC, you program even the most intricate of multi-axis simultaneous cuts in G94, and the machine figures everything else out.
EmGo
Diamond
- Joined
- Apr 14, 2018
This might be a more complex explanation than needed. The normal feed is distance over time. The inverse is time over distance. Viola, simple answer
If you program in inverse time, 9,999 minutes would not normally be an issue
It seems to me that helical interpolation in a K&T C control had to be inverse time. A 4 mhz PDP-8 was not exactly ground-shaking speed.Which brings me to the reason - I was told (but have no way to verify) that most controls internally do their calculations in "inverse time." Therefore, if you program in inverse time it is one step less for the computer to go through when driving the tool. There was even one control (TERA ?) that did parabolic interpolation, which would have definitely needed to offload any computation possible.
You mean, like APT did in 1967 ?
CarbideBob
Diamond
- Joined
- Jan 14, 2007
- Location
- Flushing/Flint, Michigan
K&T C, PDP-8 and APT.... you are officially an old fart.
Check the calendar and century.
Check the calendar and century.
I turned Hi cut off, and on that page set the max feedrate to 3937.
It's still not acting right.
I guess it's time to get Gosiger out here.
Here is a pic of my part and my program.
1/4" end mill programmed to 48.8 ipm
One thing to note, the higher feeds are EXTREMELY slow, and the lines with just an A move, they are super fast, almost like it's as fast as the rotary can go.
Code:
N100 (CUT SLOT)
(COMPENSATION TYPE - COMPUTER)
/M08
G15 H1
G56 H1 X.4744 Y0. Z4.1875 S6112 M03
(Z STOCK TO LEAVE = 0.)
(XY STOCK TO LEAVE = 0.)
A.611 X.4744 Y0. Z4.1875 S6112 M03
Z3.1875
G94 G01 Z.8375 F150.
G93 X.4814 A.27 F5666.7
X.4836 A.113 F15402.75
X.4844 A-.072 F17425.04
A-47.54 F70.47
X.4828 A-48.124 F5620.8
X.478 A-48.669 F5270.01
X.4706 A-49.135 F4844.56
X.4608 A-49.493 F4413.08
X.4495 A-49.717 F4164.37
X.4374 A-49.793 F4024.04
X.4253 A-49.715 F4016.82
X.414 A-49.488 F4149.53
X.4043 A-49.129 F4432.8
X.3969 A-48.66 F4836.43
X.3922 A-48.115 F5284.95
X.3906 A-47.531 F5634.4
A47.539 F35.19
X.3922 A48.125 F5607.69
X.397 A48.669 F5269.73
X.4045 A49.136 F4834.28
X.4142 A49.494 F4438.71
X.4255 A49.718 F4151.39
X.4377 A49.793 F4008.05
X.4498 A49.714 F4030.88
X.4611 A49.487 F4162.98
X.4708 A49.126 F4445.06
X.4782 A48.657 F4854.71
X.4828 A48.111 F5297.85
X.4844 A47.523 F5599.85
A47.47 F40000.
A-.554 F69.65
X.4836 A-.741 F17202.97
X.4814 A-.895 F15649.51
X.4744 A-1.236 F5669.5
G94 Z3.1875 F350.
G00 Z4.1875 M09
X-10. Y20. Z20. S50
G90
M278(CHIP AUGER OFF)
VC1=VC1+1
M30thesidetalker
Stainless
- Joined
- Jan 11, 2015
- Location
- Bay Area, CA
Yeah there are only so many ways that I can tell Mastercam to spit out my program using Inverse Time, and every way my machine acts wrong. So using Spock's Vulcan logic it must be the machine.
Mike1974
Diamond
- Joined
- Nov 5, 2014
- Location
- Tampa area
K&T C, PDP-8 and APT.... you are officially an old fart.
Check the calendar and century.
Or maybe well versed in old equipment to "inspire" others assumptions..?
On a serious note, I ran a Blanchard that was built in the 40's which outdated my birth by 3 decades'ish so... (just saying
)
EmGo
Diamond
- Joined
- Apr 14, 2018
And got the grey hair to prove it
But somebody's gotta remind these guys that the wheel was not invented yesterday ... and it wasn't invented by the Japanese, either. The US came up with this stuff.
Once upon a time we could find our ass with both hands in a dark room ....
gkoenig
Titanium
- Joined
- Mar 31, 2013
- Location
- Portland, OR
This might be a more complex explanation than needed. The normal feed is distance over time. The inverse is time over distance. Viola, simple answer
That is an elegant answer... but only for folks who have the context of why you would ever need to do this. It took me forever to wrap my head around Inverse Time Feed, mostly because nobody ever really explains the context of why it is necessary.
I don't even know what a K&TC control even is. Probably one of those MBT companies that was super innovative in 1958 and had gone bankrupt by 1985. There are a lot of those.
On a modern control without TCPC, I can tell you that inverse time feed definitely has issues if you are trying to cut complex swoopy geometry for something like a swarf surface. If you want to do a helix around a cylinder or a simple J cut? Not a problem because the code is straightforward with relatively long block distances. Trying to machine a spline made up of rasterized G01 segments is extremely difficult due to inverse time limitations around short travel block distances.
Let's take a simple move:
G01 G91 X0.005 Y0.005 Z-0.005
(We are ignoring rotational movements to make the math simple).
The distance formula tells us that the total distance moved on this block is 0.0087". At a feed rate of 100 IPM, that block will take 0.000086 minutes to cut (0.311 seconds, but everyone's base unit in inverse time is minutes, so we work with that.
So to get the G93 inverse time feed rate, we do 1/0.000068, which gives us F11547.0053... oh look! We have too many digits over the maximum our control can take for a feed rate!
Inverse time is great for simple stuff, but if you want to machine complex geometry in a multi-axis (4 or 5) machine, TCPC is sort of a base requirement unless you want to be frustrated.
Larry Dickman
Titanium
- Joined
- Jan 30, 2014
- Location
- Temecula, Ca
I have no idea what any of that means. We use inverse feed everyday. I wouldn't call an impeller with simultaneous 5 axis simple stuff. For us, inverse time is a complete no brainer. Has nothing to do with tcp or dfo.
fwiw, we have our max federate parameters set to 50,000
fwiw, we have our max federate parameters set to 50,000