I thought I'd throw this out to some of the CNCZone Okuma lathe experts. Our LC-20 was pulled out of moth balls about two years ago after a brief stint in the warehouse while our addition was being built. Since it's return we have mainly used it for chucking 5-6 inch casting with a tolerance of +/- .005. It's worked well in that role. However we occasionally will throw a threading job at it. It has an OSP 5000 control. We used to program using the G71 F and J without a problem. Since it's return we've noticed a .002/.003 lead problem per thread progamming it that way. We went to G33 and input the feedrate so it can be adjusted to give us a correct thread lead. This worked out fine until one of the operators told a vice president about the problem. He issued an edict to get it fixed. We had the Okuma tech in. We ran several threads sizes while he was here, all with the same results. The machine seems to run the threads consistent but the calculations just seem to be off. The Tech's involved are scratching their heads and after consulting with the Guru's at Okuma have suggested changing the threading encoder first to see if it has any effect. I don't mind dishing out $600 if it will fix the machine but my budget can't take trial and error. Up until I discovered the CNCZone I would have no choice but deal with it. Has anyone had a similiar problem or can anyone offer suggestions to correct the problem.

Thanks,
Gunner

Gunner, Have you calibrated the Z axis with a dial gauge? It sounds like the counts/inch may be off. Although I would think the Okuma tech should have checked that.
And the same time check the backlash.
Also the spindle encoder should be accurately calibrated to the actual spindle rpm.
If it is consistant it sounds like the above parameters should be confirmed.
Al

Al,
The Okuma tech checked the the X and Z axis out including backlash. All looks good. As far as I know he didn't have an instrument to check RPM for calibration. I know that hasn't been brought up in any of our conversations. Also I should have expanded my original message by saying this is a 4 axis machine. It has an upper and lower turret. The problem is the same when threading from either turret.

Gunner

Gunner,

Have you tried taking several thread passes at exactly the same depth to discover if there is any drift during the entire cycle?

Does your spindle rpm command match the actual rpm? Does the spindle motor hold constant speed throughout the threading? Possibly the spindle drive needs a bit of a parameter adjustment in its PID settings, in case it is over or under -reacting when the cutting load begins.

Hu, We have made several passes at the same depth. Problem exists. I just reviewed the service report and according to the tech he checked the spindle encoder and tuned the spindle drive to the motor. We also converted the machine to metric and tried that. All with the same result. He did note on his report that he questioned the software. He didn't want to reload it because our tape is in marginal condition and the reader hasn't been used since the machine was purchased in 86. He also recommended turret alignments but noted that they were only out .001 and did not feel this was contributing to the problem. Thanks for the response Hu.

Gunner

Gunner, I don't know whether you may have solved this problem or not by now, but I'll toss in a couple suggestions and questions anyway. Since your original post stated you had a lead error PER THREAD, I'm assuming you mean the lead is either increasing or decreasing along the thread.

You mentioned using g71 with F and J values and then going to G33 where you could tweak the lead. Unless its a multiple start thread you can leave off the J word, as it will default to 1. F word is identical in g71 and g33, so the auto-threading cycle lead can be tweaked in g71 the same as in g33. Since the B value is controlling the approach angle, have you made sure its set to the nose angle of the insert or some lesser value? If it was set at a value greater than the insert angle, it wouldn't cause a variable lead, but it would sorta "stretch" the thread, as the point of the insert would be ahead of where it should be when you reach the final depth. Of course in this scenario the back side of the thread should look like hell too.

Since the A and B turrets both give identical results, that would seem to rule out Z axis encoders or screws. It's hard for me to imagine the spindle pulse generator could produce such a consistent error. I'm an admitted electronic idiot, but the spg is driven by a timing belt, so in order to produce consistent error it would have to be shifting somehow inside itself or generating some erroneous signal, but either would have to be at a very consistent rate. Possible, but doesn't seem likely.

Have you brought up the page which shows all active control data and checked to see that the executive code isn't somehow setting an E value other than zero? I'm assuming there's not some E value in your programmed code.

Do you get the same lead error regardless of the thread lead? In other words, have you run, for example, an 8tpi thread, and then a 16tpi thread and checked to see if the lead error per thread is the same on both or if it's half as much on the 16 as the 8? If the error is the same on both, that would again point to the program somehow picking up an E value from somewhere. If you add E0 to your g71 word, it would override any erroneous value of E residing in the executive memory.

Finally, if the lead error is the same regardless of the thread pitch, and you've verified the E value is indeed set to zero, remember you can use E values to correct the variable lead you have now, in either direction you like, back to a constant lead. It doesn't fix the problem, but with the E designation it would be easy to sell it to the brass as a long forgotten Error compensation value :D

Oh...almost forgot.....there are some variables which can be set in user task. Some of them relate to specifying lead and lead error comp. I've never fooled with them, as I've had no occasion to, but I know they're there and might be something else to look at.

If you have found the problem in the interim, I'd like to know what it was in case I run into the same thing on one of mine.

Metlmunchr,
We have resolved this problem. We replaced the spindle encoder and repeated the same tests. Everything returned to normal. I'm not sure where the error was coming from since the tech did check this when he was in, I'm just glad to get the problem resolved. I hate having to "fudge" programs to get something to work. We do a lot of repeat work here and sometimes that repeat work doesn't go on the same machine. It usually plays havoc on setup times. I appreciate your input to the post. Seems like you have some good idea's that I will keep in mind for future reference. Next time I have a CNCZONE posted problem I will put a follow up as to how it was resolved.

Gunner

Yep, actually fixing the problem is a much better route than working around it. Doesn't take long to scrap $600 worth of parts, and you'd still have to buy the encoder.

Here's another Okuma problem I'm wondering if you might have any input on. A buddy of mine has an LC-20 with a 3000 control. The spindle drive on these uses fuses instead of the breaker like a 5000 uses. He's been having intermittent problems with fuses blowing as the drive decelerates the spindle after an M5. Never does it on spindle start. Usually shows up on short cycle high speed parts. He's putting in an S command to drop the speed once the cycle is done, but before the M5, and this seems to work for now. The Okuma rep's man says he has no idea, but that they could replace the spindle drive and see if that helps. Kinda like putting an engine in a car to see if that'll cure a miss :D

That sounds like one for Hu, Al, or one of the other machine guru's. I could understand if it was blowing on the acceleration side while there was current draw or load. I would think you would get an alarm not blow a fuse during decleration if it was a spindle drive. We don't use M5 much but I've never had a problem like that when we have used it. Okuma's fix does sound familiar though. Gotta love trial and error.

Gunner

Think back EMF may be the fault. Ask the tech rep if there are blocking diodes in the ckt that might have failed or getting leakege. I've seen higher amp draw on motors comeing out of a direction change under no load conditions many times and suspect this may be the problem. Anyway it's a thought!

Thanks Al..........that sounds like a reasonable cause to me............I'll pass the info along to him. He's got an independent tech who services his Fanucs but doesnt normally work on Okumas. He said he'd be willing to take a look at it, but being unfamilair with Okuma controls he figured it could take a while just to get oriented. This should give him a place to start looking. Thanks again.

Cliff

we bought an okuma lc20 osp 3000 but tis has nothing to do with ur problem but i was wondering if you could let me know how to pull up programs off it..for example like the old ones that are on it ....i cant find out how but we bought at an auction 2 months ago and im trying to run it but like i said i cant find out how to pull up programs..we on the other hand arenot useing tape or anything like that...if i have to we will call and have some1 teach on how to run it but dont want the company to have to go that far just yet...i havent been doing cnc work for long but my employer is letting me play around with it so get a general ideal of it..but im having problems all around...if you or any1 could help me that would be greatly appreciated and again thanks for any advice you give,...