Rotary surface spedd in IPM for given diameter not equivilant to linear IPM speed

[johnh]

did a search, not much to see.

Using SheetCam on a Cosmec with a 4th axis installed and working fine. This seems to be independent of the OS or POST or the CAM, similar results with different packages.

Having an issue in getting the rotating surface IMP for a given diameter to match the the X axis commanded IPM

Say I am cutting out a square hole on the side of round tube. the hole traverses 180 degrees of the tube on the A axis and 1" on the X axis.

I have commanded the tool to cut at 20 IPM

when the tool travels along the X axis the code shows 20IPM and the machine moves at 20 IPM, but when it rotates it the code says something like 2291 IPM? it whips around way faster than 20IPM

I've looked into the posts to try and find a clue to no avail. I would assume, given a specific radius the post, or something, should interpret desired IPM then calculate the correct degrees per second needed to match the commanded IPM at the radius specified in the rotary plugin setup then write that IPM needed into the Gcode.

I do have the A axis settings correct and double checked. (as far as I can tell)

BASIC CODE PRODUCED AFTER PRE-POSITIONING AND TORCH START

N0240 G01 Z0.5900 A270.0002 F2291.8312
N0250 X-0.0000 F20.0
N0260 X0.0000 A89.9998 F2291.8312
N0270 X-1.0000 F20.0

For a surface speed of 20IPM on a 1" diameter, it should take about 10 seconds, 20 ipm/3.1416" traveled per rev = 6.366 revs. 60 seconds/6.366 revs = 9.42 seconds
if I enter G1 A360 F80 in the MDI I get a full rotation in about 10 seconds. So my cave man intuition tells me instead of F2291.831 it should be F80? bigger dia slower, smaller dia faster.

If I tell the Sheetcam Rotary plugin that my diameter is 28" I get around 80 IPM during the A move but the Z is way off of course.
If I replicate this cut ion solidworks using HSMworks I get similar resulting IPM on the A axis.

This problem makes for some radically different cutting speeds around a fish mouth cut on a tube which is real bad for dross and heat affected zone.
Any ideas??
Where am I missing it?

john

Similar Threads:

• Need Help!- Bobcad Post IPM versus IPR - Can not get it to take IPM
• My 4x4 160 ipm rapids 80 ipm cut
• Would like to increase IPM cutting speed
• Tool diameter/ipm/plunge rate/etc question.
• New Taig, 8 ipm maximum rapid speed?

[deadlykitten]

hy john sometimes rotary axis can be tricky

Say I am cutting out a square hole on the side of round tube. the hole traverses 180 degrees of the tube on the A axis and 1" on the X axis.

I have commanded the tool to cut at 20 IPM

when the tool travels along the X axis the code shows 20IPM and the machine moves at 20 IPM, but when it rotates it the code says something like 2291 IPM? it whips around way faster than 20IPM

x axis is behaving normally, it is a linear axis/default stuff, with no relation to the rota

but the rota alone seems to have it's own mind ... and this mind may get more complex when movement :
... involves synking the rota with one/or more linear axis
...... or
... rota is alone, and still behaving diferently, depending on static position of linear axis

---

if you run an okuma machine, i can help with formulas, otherwise it may be needed to discover them

patience is needed

a set of simple rotary movements with diffent feeds has to be created, then compared real vs simulation time, and after that see how it changes if linear axis changes; those results have to be analyzed

after that, code may involve simple rota + 1linear axis synking, and so on, add more and more, and keep a record of durations

in the simplest case, corelation is somehow linear, proportional, and should be easy to observe/guess for simple movements

you need to scale the toolpath and theoretical/estimated times, to be sure that programeed feed will be reached in reality, and also that you timing record deviation is small enough not to affect final results; for example :
... don't program a high feed for a short toolpath
... don't program a feed close to upper axis feed limit, thus take into consideration linear mm/min limit, and rota rpm limit
... don't program an estimated duration of 0.4 seconds, if your measuring accuracy is 0.5 seconds or more; if your measuring accuracy is 1 second, then target times of at least 30 seconds for example

if you wish, i can help you / sugest trial codes; once formulas will be found, i can help with an application that will automatiicaly scan your program & map feeds corectly / kindly

[johnh]

Wow, that sounds complicated! So thisd sounds like a math formula that needs to be in the post. I see where the post has some math for rotation speed it seems. but no idea where any syncing might need t occur?

[deadlykitten]

its a bit complicated only when you do it the 1st time

Lucky me, there was examples and formula inside the programing manual; coding the same example was easy, but what took me longer was to understand why it is like that

i have less doubts now, even for a machine that i never worked on before

why dont you ask in the apropiate forum ? even so, few guys look into such details / kindly

[RCaffin]

Yes, a bit complex.
Linear stuff is simple: so many Steps per millimetre. Easy
But rotary motion can be approached in two ways: so many steps per degree (which is still simple), or so many steps per millimetre on the surface. But that will depend entirely on the radius! Mach3 can be persuaded to do this for you, provided you tell it the radius first.

Mind you, I found some disagreement here between the Mach3 screen set and other instructions. The label on the DRO or display says 'diameter' when It really means 'radius' - or vice versa, I forget which.

Now, if you have something else - dunno! Maybe work entirely in degrees?

Cheers
Roger

[deadlykitten]

But rotary motion can be approached in two ways: so many steps per degree (which is still simple), or so many steps per millimetre on the surface. But that will depend entirely on the radius!

hy rcaffin on okuma lathes, in order to feed only c axis, 360 degress is equivalent to 500mm, regardless of x axis position, thus radius/diameter is not taken into consideration ... this leads to a bit of math, in order to compute the right feed; things gets a bit more complex when more axis are added

it took me years to figure them out for simpleG01s, more complex Gcodes, special M codes that require only mm/min, or only mm/revo, etc, run trials, check data, etc, and in the end i succeded to simplify the formulas from the manuals, making the macros work faster; i needed that speed, because the amount of math required to compute some feeds was simply too much, even for on okuma model osp200 ( 300 being the actual ), thus axis motion was delayed until calculations are finished, and so on

at some point, i could use a macro to generate linear code, thus initial program was runing using a macro, and it printed a simple linear program file, to compute faster

i recognize, figuring out the rotary feeds was a bit of chalenge / kindly

[RCaffin]

Hi Kitten

I prefer, where possible, to work in steps/degree and to do all the maths and programming myself. This may not work with a CAD/CAM package.
But if it was all simple, we wouldn't be here!

Cheers
Roger