[rbitt]

Hello-

I've got a Fanuc 6T control on a Hitachi Seiki 3NE-300 lathe. Recently it's developed an odd problem. It will overshoot a negative Z position by about 450 thousands when given a G0 or G1 command. Give it a positive Z position and a canned cycle, it's fine. I've swapped out main PCB's and the problem persists. Servo motor appears good, ball screw is good, drive pin and shear pin all appear good. I can work around it by putting a 450 thousand offset, but I'd like to fix it. Any thoughts?

Bob-

[Dan Fritz]

You've got an odd problem there Bob. I've got some questions for you:

Does the Z axis "overshoot" the intended position whenever the DESTINATION is a Z - dimension, or does the axis move .4500 too far whenever it's going in the negative Z direction? There is a difference.

If you look at your "Command" page, you should be able to see all the G-codes that are effective at that moment. Can you list those G-codes for us when the axis is out of position?

You say that you're using an offset to compensate for that .4500 error. How are you doing that exactly? Could it be that a tool offset is becoming effective with a Txxxx command, then you're not canceling the offset with a Txx00 command?

Does the servo move into position smoothly, or does it do a little mambo-dance when the Z moves into position?

Let us know ..

[Al_The_Man]

I would try and check to see if is mechanical first, what direction does is it travel when it zeros the Z, does it normally travel in the + over the dog or come back in the - direction to zero?
I would run it by HW in the Z+ up to a dial gauge, zero the gauge, then reverse HW direction and check dial guage against registered move on the screen. Over 0.4 is heck of alot of movement, it seems too much to be mechanical though.
Al.

[rbitt]

You've got an odd problem there Bob. I've got some questions for you:

Does the Z axis "overshoot" the intended position whenever the DESTINATION is a Z - dimension, or does the axis move .4500 too far whenever it's going in the negative Z direction? There is a difference.

If you look at your "Command" page, you should be able to see all the G-codes that are effective at that moment. Can you list those G-codes for us when the axis is out of position?

You say that you're using an offset to compensate for that .4500 error. How are you doing that exactly? Could it be that a tool offset is becoming effective with a Txxxx command, then you're not canceling the offset with a Txx00 command?

Does the servo move into position smoothly, or does it do a little mambo-dance when the Z moves into position?

Let us know ..

*************************

1)
It overshoots when the destination is -Z. You can G0 it from it's safe tool position and it'll go right up to Z0.0. Now give it a G0 or G1 to -Z 1.0 and it moves about 1.45.

2)
G00
G97
G22
G99
G20
G40

3)
I don't have tool geometry offsets. My machine is old enough (1984) that it wasn't included in the options. So...I hard code my tool offsets into the program after I measure them off of T0100. I then relate everything off of T0100. The "offsets I use are to fine tune my X diameters and Z lengths. They should not be any more than .020 for fine adjustment, tool wear, etc. I call up the tool G40 it, then G50 the position, then move it with the tool offset-as in T0101 to use the work offset.

4)
Servo moves smoothly. However we do have some nasty weather here and I'm wondering if corosion is a factor.

As an afterthought...I originally thought this had to be a main PCB problem. I swapped X/Z control chips. The Intel 8086 chip. No such luck. However, what's in the ROM board as far as system logic, math, canned cycles, etc? Thanks.

Bob-

[tobyaxis]

Have you tried a G49 (Cancel Z Height G43/G44) in the Begining of the program?

Like this:

G0G17G20G40G49G54G80G90

I have heard of this happening when G43/G44 hasn't been Canceled.

Just throwing it out there for something to try.

[rbitt]

Unfortunately G43/G44 and G49 aren't available on this machine. Thanks for your thoughts, tho.

Bob-

[jackson]

Have you checked to see if an offset got put in on the work page

[tobyaxis]

Unfortunately G43/G44 and G49 aren't available on this machine. Thanks for your thoughts, tho.

Bob-

Ooops!!!!!!! I was thinking 6M

[Al_The_Man]

What about a relative move?
Al.

[rbitt]

>>What about a relative move?
>>Al.

********************

Well once you have established what is Z 0.0 and then moved to Z -.1 ( with a big offset ) for example, all - or + Z moves work fine. I'm going to dig into the Z velocity board this weekend. Maybe I'll find something there, or not.<G>

Perhaps I should start a new thread. "What's the best retrofit for an old 6T control?" Thanks.

Bob-

[Dan Fritz]

Look to see if you have any parameters in the 1000 or 2000 range. If the option "pitch error compensation" is turned on, then you will have parameters in these ranges for setting pitch error. A large number in the pitch error comp parameters could cause the axis to jump out of postion when you get to a certain point on the axis travel. These parameters are normally set to very low numbers (most of them should be zero). No large numbers should appear anywhere in the 1000 or 2000 range. A "large" number would be anything larger than + or - 2


The fact that the error is always the same, and that it only happens when you pass a certain point on the Z axis tells me that its pitch error comp. That's the only function I know of that can make the axis move that much without it showing on the position display.

[rbitt]

Look to see if you have any parameters in the 1000 or 2000 range. If the option "pitch error compensation" is turned on, then you will have parameters in these ranges for setting pitch error. A large number in the pitch error comp parameters could cause the axis to jump out of postion when you get to a certain point on the axis travel. These parameters are normally set to very low numbers (most of them should be zero). No large numbers should appear anywhere in the 1000 or 2000 range. A "large" number would be anything larger than + or - 2


The fact that the error is always the same, and that it only happens when you pass a certain point on the Z axis tells me that its pitch error comp. That's the only function I know of that can make the axis move that much without it showing on the position display.

************************
OK, I've looked at the parameters. I've got fifteen pages and they go up to 407. My manual states that parameters 1000 to 1127 are X pitch error compensation and 2000 to 2127 are Z. However I can't see or access them. The manual also states that inputing -9999 clears all pitch error compensation. However since I can't see them I'm guessing pitch error compensation is not turned on.

So, is there a way I can see these parameters or should I just input P -9999 and see what happens? Parameter write on or off? I'd like to see these values if they are there. Thanks.

Bob-

[Dan Fritz]

If you can't see the parameters in the 1000 and 2000 area, then we're barking up the wrong tree here. You don't have the pitch error comp. option, so that's not your problem.

I'll have to put on my thinking cap again. I can't think of any reason for this to be happening.

One more question: When the Z axis is "off" by .4500, do you see the error on the position display, or is the axis off by this amount and the position display shows the correct (non offset) position?

If you press the POS key several times, you will see a screen with 3 different position displays: Absolute, Relative, and Machine. Do you see the .4500 error on the "machine" display also? That is supposed to read the distance from the zero-return point at all times.

If I think of anything else, I'll chime in.

[roseng]

Hope you guy's don't mind my 2 cents, but,
what are the chances this machine has a linear scale on the Z axis, with a dirty spot in the area in question?

[Dan Fritz]

roseng: That's more than2 cents worth. I'd say it's a good theory, but I don't see very many lathes with linear scales.

On the system 6, it is possible to set the DMR and CMR parameters wrong, resulting in axis motion that does not agree with the display. That kind of error is progressive in nature, not a "jump" at a certain point along the axes.

[Al_The_Man]

The thing that puzzles me is that it appears to be a fixed amount in one direction, almost implies a large backlash comp being present, so as soon as you reverse, it adds the comp. immediatly.
Al.

[roseng]

lol, thats what i was thinking too, at first, however, the largest backlash value you can set in the 6 series is .025" or .25 mm

[Dan Fritz]

Just thinking out loud here ..

It doesn't sound like backlash comp because he says that the error only happens when the destination is a Z- value. If it were backlash comp, the error would appear whenever the axis moved in one direction or the other. That's why I was thinking pitch error comp instead, but he apparently doesn't have that option turned on.

The amount of the error (.4500 inches or 11.2mm) also doesn't equate to any even increment of a ballscrew or pulse coder rotation that I can think of.

Either the control is picking up an offset is some bizzare way, or there is something really wrong with the position control circuits or the interpolator ICs. Since he's replaced the main PCB, that would eliminate a problem with the position control circuits.

It's very unlikely to be the Z servo amplifier because the axis seems to be moving to the location that the CNC is commanding rather accurately. The servo isn't just "wandering around" on its own.

A mechanical problem can't be ruled out, but I can't think of any mechanical problem that would introduce an error this big only at a Z- location.

Here's an interesting experiment: The machine position of Z0 is established by his G50 statement. What if he changed the G50 statement so the whole travel of the machine is in the Z+ ?? (say, set Z0 to be the face of the chuck, and program from there). Would the problem just go away?

If changing the G50 also changes the point at which the error occurs, then we can also logically eliminate any mechanical problem.

The next step would be to completely erase all tool offsets, parameter data, and part programs, then reload the parameters and give it another go. There might be something entered in one of those "undocumented" parameters that's makeing the control go nutty.

[rbitt]

Hi-

I've been reading all this with some interest. Thanks for all your thoughts. I thought about changing the G50 and just go with positive Z moves just to see what happens. However if the end result of that experiment is to zap all the parameters and offsets, I think I'd just as soon try that first. It's pretty easy to do and I don't mind feeding in parameters and such. Anyhow if anything comes of that experiment, I'll let you know. Thanks again.

Bob-

[rbitt]

I am going to introduce one more oddity to this thread. I changed the order of tool selection in this program and the problem went away for the tools that I had changed. I know what you are thinking. I'm thinking it myself. Ah-ha, a programing error. I wish it were that simple.

This stuff is boilerplate. I have used these tool calls over and over. It's just copy, cut and paste.

So, why would a tool call at the beginning of the program vs. the same tool call at the end of the program introduce an offset error, or not? The cutoff tool still has this error. I can't change that. It's got to come last. This is new.

I'll post a copy of the offending code vs. non offending code if anyone wants to see it. I'm baffeled.

Bob-