[fordav11]

Have Okuma twin chuck with OSP7000L with a strange problem.
On restart on sub spindle, the chuck opens and closes by itself when sequence restart button is pressed. But only when restarting from the 2nd tool and then only sometimes. Maybe 50% of the time it will stuff up but it's totally random. If I restart from the beginning of the 2nd end (first tool) the program runs fine and the chuck stays closed always. Unfortunately when the chuck opens the part falls out of the chuck so I get around it by just running the part to the end and if restart is required I run it from the beginning of the 2nd end on sub spindle. Getting a bit sick of constant Okuma issues :-/
Has anyone heard of such B.S. on any CNC machine? And a solution?
Okuma guys were consulted but no idea how to solve it.

I've kind of given up hope it can be fixed but thought I would amuse everyone with yet another Okuma issue that can't be solved. We're ordering a NL2500 soon so I guess it'll be OK Until Mori Arrives :-D
Gotta love those Okumas purely for the entertainment value ;-)


btw, I read a very funny thread about Multus B300W. Very entertaining. We have 3 of them and I refused to work them right from the start (5 years ago). The poor bastard that got stuck with it has had nightmares ever since he started. Took 6 months to get them running when installed from new (and I mean literally 6 months. no parts were produced in that time, machines sitting in factory doing nothing for 6 months while problems were fixed and fixed and fixed etc), multiple mechanical and electrical issues, throwing out tools (loved that photo of the thrown out tool stuck in the door in that thread haha!), switch problems, alarms up the wazoo every few days, runs for a few days then down with some issue for 2 weeks. Then repeat that for 5 years. I'm pretty sure the Okuma service guys have bought a 3 storey mansion just down the road from our factory and a couple of twin turbo Mercs with the money they got from coming in and doing repairs every day for 5 years so they can get here faster ;-)

[jasminder]

Have Okuma twin chuck with OSP7000L with a strange problem.
On restart on sub spindle, the chuck opens and closes by itself when sequence restart button is pressed. But only when restarting from the 2nd tool and then only sometimes. Maybe 50% of the time it will stuff up but it's totally random. If I restart from the beginning of the 2nd end (first tool) the program runs fine and the chuck stays closed always. Unfortunately when the chuck opens the part falls out of the chuck so I get around it by just running the part to the end and if restart is required I run it from the beginning of the 2nd end on sub spindle. Getting a bit sick of constant Okuma issues :-/
Has anyone heard of such B.S. on any CNC machine? And a solution?
Okuma guys were consulted but no idea how to solve it.

I've kind of given up hope it can be fixed but thought I would amuse everyone with yet another Okuma issue that can't be solved. We're ordering a NL2500 soon so I guess it'll be OK Until Mori Arrives :-D
Gotta love those Okumas purely for the entertainment value ;-)


btw, I read a very funny thread about Multus B300W. Very entertaining. We have 3 of them and I refused to work them right from the start (5 years ago). The poor bastard that got stuck with it has had nightmares ever since he started. Took 6 months to get them running when installed from new (and I mean literally 6 months. no parts were produced in that time, machines sitting in factory doing nothing for 6 months while problems were fixed and fixed and fixed etc), multiple mechanical and electrical issues, throwing out tools (loved that photo of the thrown out tool stuck in the door in that thread haha!), switch problems, alarms up the wazoo every few days, runs for a few days then down with some issue for 2 weeks. Then repeat that for 5 years. I'm pretty sure the Okuma service guys have bought a 3 storey mansion just down the road from our factory and a couple of twin turbo Mercs with the money they got from coming in and doing repairs every day for 5 years so they can get here faster ;-)

hello friend,
i just visited my friend's workshop who is having a sigma vmc with a fanuc on it. He told me that the machine was dropping the tool in the middle of the cutting operation (as you said it happened randomly, sometimes with the first tool sometimes with the second) The reason came out to be was humidity and moisture in the atmosphere that was giving a fake signal to it.
So he just added a push button to the control that he use just when the machine go for a tool change. rest all the time, the controller was unable to tell the plc to drop or change the tool.
i am not sure if your issue is similar to it but you can think this way too (specially, if your control and drive panel does not has a cooling system with moisture control)
my friend's sigma vmc has just some air filters and use external air for cooling.

jasminder singh

[underthetire]

They all have there problems i'm afraid. Even Mori has put some junk out. Fortunately the really bad Mori mills that came out ~97 were promptly pulled back from customers floors. Ive run and worked on Okumas, and for the most part were pretty good, but they had big issues on some machines , they never took them back. Thats why I just kind of chuckle when someone tells me they are buying some high function lathe or mill from a small or unknown builder, cause its cheaper.

[OkumaWiz]

In my previous post I asked if you removed the M84/M249 etc. commands, and you claimed you had, but your posted code shows them still in there. Take them out or put them in parenthesis () to have the control ignore them and then try the restart at N120 to see if the issue goes away.

Sorry-been busy and haven't been able to study your code or post in a bit.

Best regards,

[fordav11]

the program I posted was the original program un-edited. I did take them out and the problem stopped. easy temporary solution is simply add block delete to those lines and press the BD button before a restart so they are skipped
The permanent solution is to update the control software to current version as stated in previous post.

[OkumaWiz]

the program I posted was the original program un-edited. I did take them out and the problem stopped. easily temporary solution is simply add block delete to those lines and press the BD button before a restart so they are skipped
The permanent solution is to update the control software to current version as stated in previous post.

Better $ solution is to skip the software update and use the already standard system variable for Restart = VRSTT to skip automatically if restart is active...

Just add an IF statement before your chuck unclamp:


NCK2 IF[VRSTT NE 0]NRUN (IF RESTART)
M84
NRUN

Will work like a champ!

Best regards,

[OkumaWiz]

Better check your code for M84 commands telling the machine to open the chuck. That's probably what is becoming effective depending on where you restart. (May also be M249 if commanding opposite chuck to open.)

Best regards,

[fordav11]

That was the first thing the Okuma service guy said (not wanting to blame their FANTASTIC STATE OF THE ART machine ;-)
But already tried that. I'm restarting at the same point each time and the open/close is random. I even removed all of the M84 commands (and M249 etc). On restart it still screws up.

[OkumaWiz]

That was the first thing the Okuma service guy said (not wanting to blame their FANTASTIC STATE OF THE ART machine ;-)
But already tried that. I'm restarting at the same point each time and the open/close is random. I even removed all of the M84 commands (and M249 etc). On restart it still screws up.

Ok the obvious one is checked off, now for the not so obvious.

Have you checked (watched) your hydraulic pressure during th re-start?
I have seen some that lose enough pressure due to both turrets indexing at the same time that they can drop parts.

Watch for a big system pressure drop as the re-start is activated. Also check the chuck clamp output signal to make sure it is staying on.

Best regards,

[fordav11]

the hydraulic pressure looks ok.
Yeah I always watch the chuck clamp lights on the panel as soon as I restart. They usually toggle off/on and the part falls out :/
I did this yesterday as a test and the chuck stayed closed but it was in the morning. I think I've noticed it doesnt stuff up if its the first time I restart after powering on. I'm fairly sure it never dropped a part the first time. It's almost always on subsequent restarts, usually when setting and running the first part and restarting a few times with offset changes to get the sizes right.

I may have forgot to mention, Okuma got a Japanese tech to come out and have a look and he wasn't able to fix it either. Their solution was to re-write the entire O/S at $5.5k. We said thanks but no thanks

[OkumaWiz]

I didn't mean the chuck clamp lights, I meant the output to the solenoid from the control. You can view it in the check data screens.

Also when you re-start what clamp codes show up in your block data?

Which machine model are we talking here...multis?

Any special options such such as barfeeder interface?

[fordav11]

I solved the problem. Basically when Okuma Japan wrote the OSP7000 control software they didn't test it enough before signing off on the code

[zooloader]

Do you mind telling us how you solved the problem so the rest of us running untested 7000 controls can do the same?

[fordav11]

it's a controller software bug. it requires an update/bug-fix to the O/S from Okuma

[fordav11]

ah ok will try it.

Maybe you can help with another restart-related issue

Check the same program I posted before.
On restarting from the transfer (N110) the sub spindle goes into overtravel. It moves back about 2". Its not random, it does it every time when restarted from N110. When the program is run from start to finish it works fine. If I restart from any other place it works fine. I suspect it has something to do with the G00 Z50 lines from previous tools. Normally it would just go to maximum Z (which is the intention of that line) but on the transfer restart it seems to be trying to physically go to Z50 (max Z travel is about 20"-25"). Thus going into Z-overtravel :/
If this were a Fanuc I would use G28 etc but this doesn't seem to have a 'go home' command?

[budgieW]

Is the tool offset still active at N110?

[fordav11]

yeah it will be. If I were on a Fanuc I would put txx00 at the end of each tool but on this machine I haven't done that and it seems to work fine running normally. The reason is so I can rapid the 2nd chuck to a Z-position and it will be relative to the previous tool to speed things up so the chuck is not needlessly rapiding in and out between tool changes.... the machine isn't the fastest thing I've seen

[budgieW]

"If I were on a Fanuc I would put txx00"
You should do this on your OKUMA as well

"the machine isn't the fastest thing I've seen"
As it has a 7000 control it is probably the best part of 15 years old

[fordav11]

[QUOTE=budgieW;994802]"If I were on a Fanuc I would put txx00"
You should do this on your OKUMA as well/QUOTE]

I tried this today and it doesn't work as expected.
For example if there is a boring bar extended 8 inches and I stop it at Z2.0 at the end of the process then put T0100, on reading it the turret moves 8 inches minus! It cancels the offset and puts the turret in a position as if there is no tool length.
That's a potential crash situation. I recall now that's why I don't cancel the offset at the end of each tool. I don't know if that's correct Okuma behavior or if it's just another Okuma controller software bug... errr... I mean 'a special Okuma feature' ;-)

[OkumaWiz]

ah ok will try it.

Maybe you can help with another restart-related issue

Check the same program I posted before.
On restarting from the transfer (N110) the sub spindle goes into overtravel. It moves back about 2". Its not random, it does it every time when restarted from N110. When the program is run from start to finish it works fine. If I restart from any other place it works fine. I suspect it has something to do with the G00 Z50 lines from previous tools. Normally it would just go to maximum Z (which is the intention of that line) but on the transfer restart it seems to be trying to physically go to Z50 (max Z travel is about 20"-25"). Thus going into Z-overtravel :/
If this were a Fanuc I would use G28 etc but this doesn't seem to have a 'go home' command?

You may have a G30 command available on your machine for home positioning.

I think your main issue is that you are doing a restart with multiple axis movements which are "not in sync" when restarting. ALL axes will move at a rapid rate to their "restart point" (previous coordinate) after the sequence restart button is pressed. This may cause your coordinates and limits to shift for the Turrets as the W-axis repositions to it's restart point thus generating your alarm.

One solution is to make your transfer cycle into a sub program and design it fro the get go with valid restart points in it. We use NPASS line numbers on both turrets with G140/G141 commands on those lines. That way we can number search to the lines (jumps directly there with no waiting) Interlock + cycle start and do a transfer. We use block delete to ignore the call statements for the transfer sub, so we can run parts and stop before transfering and make any needed adjustments. Then transfer if needed by "jumping" to NPASS. We also have OP stops at the beginning of the transfer cycle to make a "check stop" possible without having to do the restart.


Code , code, code, is key!

Best regards,