[GTard]

Hi all, the Gilda 20 (one of two twins) we have here, is doing something I've never seen in my CNC days. The X axis for this machine shrinks the diameter of the part .003 on average, for every one part cycle. The issue is global(all tools). Once homed, the machine seems fine, for one part, then starts the descending process on part #2 and so on until the the machine is homed again. Any help greatly appreciated.
Chuck Moore
So Cal

[GTard]

Forgot to add, this machine has a Fanuc O-T control.

[MCImes]

Couple things:
Have multiple programs have been tried and the issue remains?
Is the shrink consistent? (like, exactly .003 every part, or is is .0015 sometimes and .0035 sometimes?)
Has this program run fine in the past or is it a new program?
Are macros used in the program?
Is auto tool life management used?
Was anything done to the machine recently (regular maintenance, crashed ect)

Im not familiar with the machine, but Im intrigued by the problem...

[GTard]

Couple things:
Have multiple programs have been tried and the issue remains? We loaded the exact same program that is running on the other twin and I double checked it for comparison. No difference that I can see.
Is the shrink consistent? (like, exactly .003 every part, or is is .0015 sometimes and .0035 sometimes?)Yes, the shrink is exactly .003 every consecutive part.
Has this program run fine in the past or is it a new program? This program runs fine and is a proven program from some months ago.
Are macros used in the program? No macros.
Is auto tool life management used? Not that I know of, as in, I don't think that switch has been flipped, and I wouldn't know where or how to enable that function.
Was anything done to the machine recently (regular maintenance, crashed ect)We recently converted the machine from 1/2 dia stock to run 5/8 stock (collets and so forth) and there was a part off tool smack but that has happened before with no adverse reactions other than liberal use of f-words.
Im not familiar with the machine, but Im intrigued by the problem...

Thank you for taking interest in my issue, I didn't know about auto tool life management but will look in to it to make sure it is not on. Question, do you think I should cross post in the Fanuc forum?


Thank you again!

[MCImes]

With that in mind, I doubt its a physical issue, it has to be a parameter or code issue...

Are the 2 machines identical? Although it may be the same model, there may be subtle differences between them. For example, on our Citizen machines, when using C axis superimposition some machines had to have a parameter changed so that the sub rotated the same direction as opposed to opposite even though they are the same model and were even consecutive machines off the factory floor.

Just wondering aloud... is there a line in the program like G50 U-.003, or some other type of axis shift? (it may be a different code on guildimiesters, but G50 is an axis shifting code). another thought, if you command something like G28U0 to retract an axis, is there a G50 X0 or something like that on the next line? On citizen swiss, I see some people enter G50Z0 after a G28 for some reason. It works fine, but is technically unnecessary. If the Z0 was Z-.003 instead, you would get .003 axis creep per part, but be nominal after a reference return.

Your no macros shot a hole in my theory too. We use macros to auto offset some tooling every few parts with an equation like #2711=#2711-.001, but if you're not using macros then that's not the problem.

Couldnt hurt to post this in the Fanuc forum. I bet its a parameter or code issue, although I cant tell you why. We had a similar problem, but the axis growth/shrink was inconsistent. In our case, a little T shaped piece on the servo motor shaft that engages with the encoder came loose and would move slightly during rapid moves. We swegded it back on the shaft and it works fine now, but we saw ±.005 variation when the issue was happening.

[GTard]

With that in mind, I doubt its a physical issue, it has to be a parameter or code issue...

Are the 2 machines identical? Although it may be the same model, there may be subtle differences between them. For example, on our Citizen machines, when using C axis superimposition some machines had to have a parameter changed so that the sub rotated the same direction as opposed to opposite even though they are the same model and were even consecutive machines off the factory floor.

Just wondering aloud... is there a line in the program like G50 U-.003, or some other type of axis shift? (it may be a different code on guildimiesters, but G50 is an axis shifting code). another thought, if you command something like G28U0 to retract an axis, is there a G50 X0 or something like that on the next line? On citizen swiss, I see some people enter G50Z0 after a G28 for some reason. It works fine, but is technically unnecessary. If the Z0 was Z-.003 instead, you would get .003 axis creep per part, but be nominal after a reference return.

Your no macros shot a hole in my theory too. We use macros to auto offset some tooling every few parts with an equation like #2711=#2711-.001, but if you're not using macros then that's not the problem.

Couldnt hurt to post this in the Fanuc forum. I bet its a parameter or code issue, although I cant tell you why. We had a similar problem, but the axis growth/shrink was inconsistent. In our case, a little T shaped piece on the servo motor shaft that engages with the encoder came loose and would move slightly during rapid moves. We swegded it back on the shaft and it works fine now, but we saw ±.005 variation when the issue was happening.

One of our maintenance guys came over and after some testing feels the encoder for the axis is bad. I will update the thread when I know more. Thank you again MCImes!

[GTard]

After installing a new encoder with no change in behavior, the cable for the encoder was replaced and machine is functioning again. Thank you MCImes for your time and effort to help.

[GTard]

Just wanted to update this thread as it turns out the encoder wasn't the issue. It turns out my trainee who is very bright, driven to perfection, but still learning, had created a programs (and several others), mostly by piecing together parts of other programs as well as raw editing, programs that had G41-42 calls in them, but no G40 cancellations. He wasn't calling the creating the G41-2's, they were leftovers from other cycles he had pieced in doing copy and paste from other proven programs, somehow the G40's got left out. We tested these programs in our other machine that is for the most part identical and there was no problem so we decided to rule out a programming error early in trying to cure the problem. While doing more internet research over a weekend two weekends ago I came across a thread either here or somewhere else talking about lack of a G40 in a program causing problems, sure enough, that was our problem, and my fault for not catching it as I am an experienced CNC machinist I just don't do much of it anymore. Cheers and thanks for the help to all who chimed in.
GT