[HuFlungDung]

I've been working with this weird problem for a couple of days now and have come to the conclusion that maybe my problem can be solved by a smart Haas serviceman.

First of all, this involves an older (red) HRT-310 rotary table in good working condition. In fact I had no idea of this deficiency because it is very low backlash and very repeatable so far as indexing is concerned. The Haas was prewired for 4th axis and that is how I am using it, doing some helical milling.

The part is quite basic: consists of a RH square thread about .256 wide, pitch of .875" per rev.
Superimposed on this, is a LH square thread, same description. It is a guide for a cable winding device, many of you might have seen a miniature version on the old fishing reels.

So the procedure: rough cut the groove with a 6mm endmill. Then take a profile cut on each side of each groove. This is a combined XA movement. Quite a simple program.

What happens: the right hand groove comes out narrow, 0.241" wide. The left hand groove comes out wide, 0.261" wide. There is no reason so far as the programming is concerned, that they should differ one iota from .256 except for uncertainty in the tool diameter.

So I'm thinking what is happening, is that the A axis either lags or begins slightly ahead of the X axis (timewise). There is no Y axis motion involved in this program except for the initial positioning.

Quantitatively, the error could be 1/4 degree of phase angle, which seems like quite a bit.....must be almost 1/16 a turn of the A axis motor if this is a 90:1 worm drive.

I got this figure from the fact that the part is 1.5" diameter, the helix angle is approx 80 degrees, so a change in width (normal to the groove) of .020 amounts to .020SIN10 = .0035" in circumferential distance. At this diameter, 1 degree = .013" along circumference.

I suppose the less elegant solution is to climb mill one side of the thread and conventional mill the other side, so that A is always rotating the same direction. Yuk.

Note this is not a positioning error per se, rather a dynamic motion error. Its as though the X and A do not really cam together identically in forward and reverse.

Backlash setting for A = 15 and X = 32, if that has any relevance.
So my question to any Haas guys that may be reading: is there any way to compensate for this in parameters?

[Geof]

....I suppose the less elegant solution is to climb mill one side of the thread and conventional mill the other side, so that A is always rotating the same direction. Yuk.

Get a left handed cutter for the 'other' side?

[littlerob]

Don't get me started, still no solution to my problems. This is out there (but you guys listening are out there).. A rotary Axis really has no idea what it's feed rate is. Depending on it's PI value, it is going to move at a different speed determined by what diameter it is, right? I.E. If it were determined by true center line it would move an infinite amount of inches per minute. ( since there are an infinite amount of inches at true center line, not trying to turn this into some insanity, like Black holes and Boring Bars... Geof) I would check the start point of each thread to make sure they are identical. Because you are calculating I.P.R but really it is a mill and it is moving in inches per minute. At the same time (an afterthought). There is a formula for calculating how many thousandths something moves at P diameter, what is the formula for calculating haw many thousandths something moves with the Helix? On a different axe. Because the further you moved from center line the less the Axis would need to move. I guess there has to be one, other wise we wouldn't have the software that we have. This is interesting from two very bright guys (not me i'm the third) Robert

[HuFlungDung]

The start points are identical in the program, but once motion begins, then it is difficult to know whether the two axis actually began motion together.
For that matter, I don't know how to adjust the balance of the drives in a Haas, but in some simpler cnc's, a little tweak of the balance for A might make its speed more symmetric in forward and reverse.

I've had the suggestion that I use inverse time feedrate instead of letting the control convert the feedrate from input of the diameter setting for the A axis. Just pondering that, I can see perhaps using inverse time would improve the pitch spacing of a multi-turn thread (5400 degrees) if that were out of spec, but I haven't even gotten to worrying about that one yet

If inverse time feedrate were going to be the cure, I'd still have to estimate the difference required between one groove versus the other. And I don't see evidence of one thread pitch advancing on a turn by turn basis. Its simply phased late or early the entire distance of the cut.

[Geof]

If your A axis feed is programmed in degrees per minute, which it normally is I think, you do not need to worry about the diameter of the work piece.

If the lag is repeatable just offset the starting point in X by the appropriate amount to compensate for the lag. One way to do this is run this part of the program using G52 and simply make the G52 X value the necessary offset.

I think.

[Khalid]

HuFlungDung..You are also stucking in 4th axis dilemma..

[HuFlungDung]

Yes, I am stuck

I have tried swapping the X and Y, then A and Y drive amps but cannot discern any difference in machine motion, ie,. it stays asymmetric.

Back to a hack method, I guess

[littlerob]

Yes, I am stuck

I have tried swapping the X and Y, then A and Y drive amps but cannot discern any difference in machine motion, ie,. it stays asymmetric.

Back to a hack method, I guess

I am upset that we didn't get a better answer, it would have been interesting, Robert.

[holbieone]

the right is off .015 and the left is off .005

i would expect them to be off almost identical ,sounds like a problem in the program

[HuFlungDung]

I think the tool diameter is a factor: for all I know, on the narrow groove, the tool could be cutting on the wrong side of the programmed path altogether, because of the lag, which puts it .005 opposite.

Anyways, I ended up cutting with only A axis running one direction. This involved profiling one side of the groove in 'conventional milling' mode. Now I know of a good use for a left handed endmill

[littlerobb]

I think the tool diameter is a factor: for all I know, on the narrow groove, the tool could be cutting on the wrong side of the programmed path altogether, because of the lag, which puts it .005 opposite.

Anyways, I ended up cutting with only A axis running one direction. This involved profiling one side of the groove in 'conventional milling' mode. Now I know of a good use for a left handed endmill

I an much more satisfied with that response. Robert

[HuFlungDung]

Interesting little tidbit to add: I did get the groove width uniform when milling as described above, rotating the rotary only in one direction for all cuts.
I noticed in a subsequent operation, chamfering the top corners of the slots, that once again, the tool was not following the corners, similar situation with +/-lag.

Turns out that this condition was caused by using two different feedrates between the profiling op and the chamfering op. When I slowed the chamfer down to match the previous feedrate, then things phased in correctly.

In hindsight, this makes sense when one must consider what happens on a lathe if one were to vary the spindle speed during a threading operation (on older controllers this is forbidden). The different effective feedrate causes a change in the phase angle of the start of the motion.

I never thought of it applying to rotary axis on the mill because everything is just creeping along compared to a lathe, but apparently the effect is still there.

[Geof]

I didn't ask it when this thread was active because I didn't think about it; did you try using M11 to unlock the 4th axis before starting your synchronized motion?

To quote the Haas Mill Manual;The M11 code will "pre-release" the 4th axis brake. This is useful in preventing the delay that otherwise occurs when a 4th axis is used with a brake and a motion is commanded in that axis. It is not require but, without a prior M11, there will be a delay in motion in order to release the air.