C axis "Jumpy" on lathe

[JoBalbis97]

Good morning,

I've been having some trouble understanding machining with the C axis on my mill/turn, was hoping you guys can give me a hand on this. 

I have an Haas St-30Y, using the post provided by the hsm website. When I do, for example an adaptive, when machining, the C axis is VERY jumpy. Doesn't seem normal. Also, let's say I make an adaptive circular pocket feeding at 100ipm from center to outside. When it plunges on center, it moves looking like 100ipm, but as it heads towards outside diameter, it goes very slow, like 20ipm slow. 

Do I have to do something to the post? I've seen machines like mine machining with live tool using C axis it look nothing like mine. The one's I've seen are extremely smooth. 

I'm attaching a program that I ran a few days ago and my post, maybe there's something wrong you guys notice. 

Hope I made it clear enough for you guys to understand. 

[Anonymous]

Came here to post about this. We are working with HAAS and have found the issue. It seems when fusion exports the ramping arcs it uses very small point to point instead of smoothing it into arc moves and the program will stutter when trying to process all the small moves.

Turning on smoothing does not change the program at all and it still posts all the small point to points.

[Laurens-3DTechDraw]

@Anonymous

Well. I think you are having a different issue but I can explain the small moves.

It outputs loads of small line segments because it's in XZC mode and not in polar(G112) mode.

And that is because Haas machines cannot handle G112 mode close to X0.

@JoBalbis97

What you see I think is more of an feedrate issue between post and machine. Because the post by default outputs degrees per minute. But your control seems to still take it as feed/minute.

Does the machine have inverse time capabilities?

If so, there is this line in the post you have:

var useInverseTimeFeed = false; // use DPM feeds

Change it to:

var useInverseTimeFeed = true; // use DPM feeds

[Anonymous]

So how do other programs post their program without jittering on arcs? when choose to use g112 it still exports a bunch of point and does not use arcs. If make the post export as xyz with arcs and then put in a g112 it errors out with wrong JKL, im guessing because it is exporting the the real X numbers instead of halfed x numbers. 

[ArjanDijk]

I'm curious why you would want to mill this shape? Why not inside turning?

C axis does maybe not move because the values stay in range, it will use the Y axis in that case

var yAxisMinimum = toPreciseUnit(gotYAxis ? -50.8 : 0, MM); // specifies the minimum range for the Y-axis
var yAxisMaximum = toPreciseUnit(gotYAxis ? 50.8 : 0, MM); // specifies the maximum range for the Y-axis
var xAxisMinimum = toPreciseUnit(-40.214, MM); // specifies the maximum range for the X-axis (RADIUS MODE VALUE)

[Anonymous]

It is not on center and it is not fully inside that range window.

we have already edited those values so when it is in the range it only moves xyz and that works fine because it uses arcs and not tiny points and ever changing feedrates.

[JoBalbis97]

I just generated a quick program so I can try to explain a bit better. The program basically pockets a circle on the material. Ramps in, then opens up to the diameter with a step-over. 

This is part of the NC:

X1.21 C1438.777
C1441.304
C1442.609
C1443.913
C1445.217
C1446.522
C1447.826
C1449.13
C1450.435
C1451.739
C1453.043
C1454.348
C1455.652
C1456.957
C1458.261
C1459.565
C1460.87
C1462.174
C1463.478
C1464.783
C1466.087
C1467.391
C1468.696
C1470.
C1471.304
C1472.609
C1473.913
C1475.217
C1476.522
C1477.826
C1479.13
C1480.435
C1481.739
C1483.043
C1484.348
C1485.652
C1486.957
C1488.261
C1489.565
C1490.87
C1492.174
C1493.478
C1494.783
C1496.087
C1497.391
C1498.696
C1500.
C1501.304
C1502.609
C1503.913
C1505.217
C1506.522
C1507.826
C1509.13
C1510.435
C1511.739
C1513.043
C1514.348
C1515.652
C1516.957
C1518.261
C1519.565
C1520.87
C1522.174
C1523.478
C1524.783
C1526.087
C1527.391
C1528.696
C1530.
C1531.304
C1532.609
C1533.913
C1535.217
C1536.522
C1537.826
C1539.13
C1540.435
C1541.739
C1543.043
C1544.348
C1545.652
C1546.957
C1548.261
C1549.565
C1550.87
C1552.174
C1553.478
C1554.783
C1556.087
C1557.391
C1558.696
C1560.
C1561.304
C1562.609
C1563.913
C1565.217
C1566.522
C1567.826
C1569.13
C1570.435
C1571.739
C1573.043
C1574.348
C1575.652
C1576.957
C1578.261
C1579.565
C1580.87
C1582.174
C1583.478
C1584.783
C1586.087
C1587.391
C1588.696
C1590.
C1591.304
C1592.609
C1593.913
C1595.217
C1596.522
C1597.826
C1599.13
C1600.435
C1601.739
C1603.043
C1604.348
C1605.652
C1606.957
C1608.261
C1609.565
C1610.87
C1612.174
C1613.478
C1614.783
C1616.087
C1617.391
C1618.696
C1620.
C1621.365
X1.2101 C1622.7

Why doesn't it just generate as:

X1.21 C1438.777

C1621.365

X1.2101 C1622.7

All those points just make a axis jitter for no reason. 

[Anonymous]

I also have a Haas ST30Y and have been fighting the issue for the last year. I can show the c-axis stuttering in slow motion video and have had haas techs here multiple times and they insist it is either programming or I am just pushing the machine beyond its limits.

I have also found that while the C-Axis is rotating if I change my rapid from 5% to 25% it will change the FEEDRATE, you can see this visually only, not on the display.

I am programming with mastercam and smoothing setting also do not help the situation.

[radamsRAWWM]

Have this same problem as well (Brand new Haas ST-35Y lathe w/ NGC). Trying to mill a 'square' bore axially into the end of a shaft. C-axis seems smooth while interpolating a helical move CZ or XCZ into the part but only under ~3rpm. Above that it is 'jittery' AF. Would like to see if HSM can stop C-Axis moves and only allow XYZ moves for axial milling so I can get a part done. I understand this would limit available travel, but would hold the c-axis stationary. From talking with Haas HFO, the drive mechanism for the c-axis is pretty 'weak' (look inside the machine). It's basically a large sprocket gear that engages on a M154. Ran into this 'jittery' problem on a Haas VF 4th axis and had to purchase the high speed milling option to get around it.

I've Tried without luck:

setting 191 Accuracy Control - Fine/Medium/Rough

G187 / Setting 85 (default 0.025") > 0.1"

InventorHSM Adaptive clearing pass tolerance changed from 0.004" to 0.1"

There has to be people out there simultaneous milling on a haas c-axis lathe above ~3rpm???

[Anonymous]

Have we found any answers to these issues? Im having the same problem with it being really jumpy.  Let me know if you guys have got an answers on this.

Thanks!

[radamsRAWWM]

Currently working with haas on a solution. They have now said they can recreate this issue on machines at the factory in cali. Their answer so far is they will have a solution by june. Why did I buy a machine (last april that was delayed an additional 3 mo until sept) that doesn't do what it's advertised to do? Good luck to anyone trying to get haas to work on something, like pulling teeth! For the longest time this was how I was programming and not their machine. Their actual first response was to ask why are you making something small on a 12" chuck! I will let you all know if we are actually able to come up with a solution; fingers crossed...

[Anonymous]

Oh Thank you for not making me feel like a dummy or that I was doing something wrong with programming. Please let me know what they say. I heard they were coming out with a new software update in May or so and was hoping this would be an issue that was resolved.

[swimleft]

Is there any update with anyone on this problem? 

I am having exactly this issue on a brand new st15y. I am trying to mill this feature using the C axis. The code which gets output makes the axis jitters and will not give a good finish. Does anyone have any updates on solving this?

[radamsRAWWM]

Haas has just informed us, as of last week, that they have not come up with a solution to this issue and they hope to get to it for the next software release (meaning next quarter). Quite honestly, we've moved on and just either live with horrible surface finish on parts that don't need anything special, or just don't do simultaneous 4th axis operations. Getting a hold of Haas is a complete waste of time as we were calling them daily to stay on them; obviously to no avail. Whats complete bs is they advertise this on these machines and they just can't do it. I know this works on a 30/30Y, but why they can't make it work across the board on all their machines is beyond me. Maybe they just wont get off their dead a$$es to make it work! If and/or when they come up with something I will let you know.

[Anonymous]

My issue was resolved for the most part after I used the most up to date post processor from the HSM Library.  I also had my machine software updated as well.  I still get a little jitter motion but nothing anywhere near like it was before and I can mill a lot faster now than I ever did before.  Try using G112 as well, sometimes that will help. Let me know if that doesnt help you, I'll try to run it on mine and see what it does if you want.

[swimleft]

So, after posting I just sort of got this to work. I turned off using g112
in the post and fusion just gives c and x values and everything works
well.... um new on the lathe side to this fix may not be the fix i think it
is. I will post up later on this.

[radamsRAWWM]

Yeah g112 does nothing for me as stated previously...

[swimleft]

So here is a run down on what I am experiencing. The goal is to cut the contour shown up thread.

If I post the program as using Polar (G112) I get code like what is shown below. This runs like crap on the lathe. Seemingly this is due some combo of being on a Haas and telling the machine to make really small moves. 

G112
Z0.2
G1 Z-1.327 F20.
X0.8554 Z-1.3298
X0.8552 Y-0.2758 Z-1.3326
X0.8548 Y-0.2757 Z-1.3354
......
......
X0.7568 Y-0.2383
X0.7541 Y-0.2376
X0.7513 Y-0.2371
X0.7486 Y-0.2368
X0.7458 Y-0.2367
X0.743 Y-0.2366
X0.7402 Y-0.2368
X0.7374 Y-0.2371
X0.7346 Y-0.2376
and so on

If I disable polar I get the code shown below:

(2D Contour11)

G1 Z-1.327 F20.
X1.7976 Z-1.3298
X1.7972 C-17.874 Z-1.3326 F11.1258
...
X1.5181 C-18.71
X1.5145 C-18.874
X1.5113 C-19.046
......
X1.495 C-21.064
C-141.064 F20.0669
C-261.064
C-381.064
C-501.064
C-621.064
C-741.064

....Then lead out

The second code runs fine at the expected feed. 

Since we are using a computer already to generate the code, is there a reason to care about using G112? My understanding is that G112 is primarily to make life easy for people who are programming by hand. If the computer can output acceptable code with out G112, then when would I want to use G112? 

[radamsRAWWM]

I would try not to use it. The machine has to make the xyz-to-xcz conversion on the fly.

One other question, when you're cutting this, what speed does the chuck indicate its turning at? I can get about 4 rpm without jitter but anything above that is game over.

[swimleft]

I just ran both codes again. (w/ G112 w/o G112)

As far as I can tell both might be running at the same speed. However, I can feed the machine stuttering when G112 is used. As for your question, even when I bump the speed on the G112 code down to 10% the machine stutters. As far as I can tell, the actual speed of the cut seems unrelated to the stuttering.