lathe shrinking parts.

[bak3r11]

Just had QT200 serviced. First part of the year is shrinking 0.05mm each time. Tested over 10 parts.

EIA programming using G53.5 and no wear compensation. Was a parameter changed? Am I missing something?

[Jim Dawson]

Not sure I understand the question. Each part is 0.05mm smaller than the previous part? Or are all the parts 0.05mm undersize?

[bak3r11]

Not sure I understand the question. Each part is 0.05mm smaller than the previous part? Or are all the parts 0.05mm undersize?

Yes they are shrinking. 7.00, 6.95, 6.90, etc. 0.05 Everytime I hit run.

[Jim Dawson]

Try homing the machine between parts and see if that makes the parts come out correct. If so, I would say there is a calibration issue, or maybe a problem in the G code. But if the G code hasn't changed since the last successful run then it is unlikely that G code is the problem.

[bak3r11]

Try homing the machine between parts and see if that makes the parts come out correct. If so, I would say there is a calibration issue, or maybe a problem in the G code. But if the G code hasn't changed since the last successful run then it is unlikely that G code is the problem.

Yeah I have already tried the homing bit. The gcode is good and even hash checked it against the original it has not been altered. I have no idea, I have reached out to the maintenance guy, but still waiting his response. I even went as far as restarting the machine between parts for 3 parts.

[Jim Dawson]

That is crazy. I'm out of ideas.

[bak3r11]

Ran 2 more parts this morning, still shrinking. The machine appears to have remembered its last value since the 2 parts this morning were consistent with yesterdays string of 10 parts, so #11 was 0.05mm smaller than #10 and #12 0.10mm smaller than #10. Spoke with the maintenance technician, nothing was changed, and no enlightenment on what could be causing this problem.

[Jim Dawson]

Does the DRO agree with the actual position (too small) or is it showing where it ''thinks'' it is?

[bak3r11]

It will show the "7.00mm" on X every time. The offsets on the tool data page also stay the same, i can keep incrementing +0.05 to get "good" parts. I am working to confirm, but I believe only half of the tool posts are effected. It is a simple part, turn, groove, drill. I believe only the turn profiling tool is being affected.

[Cyrus-SX]

try mazatrol programming

[Jim Dawson]

Is there anything you have done that will reset the part to normal size and start the ''shrinking cycle'' over again?

[bak3r11]

Using the tool eye to re-offset the tool will return it to the "normal size" +/- some tool eye error.

[bak3r11]

4 Part Re-Run to record values, offset appears to have increased from 0.05mm to 0.08mm

RUN / POS / MACHINE POS / TOOL OFFSET / WEAR COMP / MEASURED TURN / MEASURE GROOVE / MEASURED DRILL

#1 / 9.9 / -328.0918 / -337.9918 / 0 / 9.94 / 6.79 / CENTER
#2 / 9.9 / -328.0918 / -337.9918 / 0 / 9.86 / 6.79 / CENTER
#3 / 9.9 / -328.0918 / -337.9918 / 0 / 9.78 / 6.79 / CENTER
#4 / 9.9 / -328.0918 / -337.9918 / 0 / 9.69 / 6.79 / CENTER

Appears the only tool affected is post #2 on primary and sub spindle. Stopping the program before completion will not introduce the shrinking.

[Jim Dawson]

If it's only one tool being affected, then my best guess is some kind of very strange encoder problem just in that particular area of the encoder. The only thing I can think of to do to to test this theory is to reset the tool position by a half inch in or out, just to get into a different part of the encoder.

[bak3r11]

Appears to be fixed but not solved.

Loaded up another program (cheaper to throw away). The 2nd program exhibited no "shrinking" problems. pull gcode for both parts, examine for any differences (we use have a bunch of pre written templates we use). Unable to find any variations. Call back up the original program, no signs of shrinking 5 parts in now. It appears at least to me the fix was changing the program then changing back again. Is there any reason for this? is it possible that there are memory registers that were cleared and reloaded when changing to program?

[Jim Dawson]

Appears to be fixed but not solved.

Is there any reason for this? is it possible that there are memory registers that were cleared and reloaded when changing to program?

I think that is as good of an explanation as any. I have never heard of any machine doing anything like this before.

[bak3r11]

Very bizarre, up to 20 parts with no fluctuations. I'm not sure what i did exactly but it appears to be resolved.