[tc429]

here is a part program, start, to crash...
/m90
g50 s2000
g94
n101 g0 x35. z35.
n102 t0909
/g97 s2000 m3
/m8
g0 x7.1743 (crash z never moved away, x drove right thru workpiece)

the program was started from the beginning, the position was about x24., z0 (its the wheel load position on this horizontal lathe), normally the x35. z35. moves the wheel back to the limits at about x25. and z18. (ballpark- varies by machine), for some reason, the slides never retracted from the load position, and it cleaned the chuck. its has happened a couple times before on other Okumas also. just before cycle start, the setup guy had ran a wheel, cycle finished, door opened, program reset, he went to manual, indexed the turret 1 station, changed a insert, indexed back to tool 9 went to re-run the part and BAM.

I dont see a g90 in there, but assume its modal/wouldnt change by indexing turret(incremental x+ wouldnt have moved that way anyhow)

I'm suggesting they move the tool inside the forging before starting the spindle from now on, but still...this shouldnt happen.

Same guy (very experienced setup/cam operator, never saw him wreck anything the last ten years - until these Okumas arrived.

He showed me a couple weeks ago a similar problem, but reverse- I didnt jot down the gcode, but it was basically mid program, call a tool, move x to 0, and (only about half the time) if started mid program it would move z and x right into the chuck on a line with only x commanded. starting from the beginning of program toolpath was totally different...I still cannot fathom how a line that says X could move Z also...and all 5 of these machines will do it...
I assume there must be some sort of a modal gcode that triggers geometry for the new tool to stack onto whatever was running when program was stopped or something like that, but wouldnt even know where to tell him to look...If I get a chance, I'll ask him to show me the x+z on x line thing again and post the code/check the current block/modal status (assume okuma has this page- I'm used to Fanuc...)

Just thought I'd toss the question out here with some okuma gurus- any help appreciated

[tc429]

another thought- if the cycle was stopped mid-move, then the program reset, is there any way that the remaining 'distance to go' from the previously stopped block could still be in the buffer even after a reset?

if so, how can it be prevented?

[RWACKO]

i dont write g-code all we use is the igf and in igf they have approach and return points for each tool this has saved us from crashing. if i had to guess you need to move the z axis with the x axis at the end of your program.

[tc429]

i dont write g-code all we use is the igf and in igf they have approach and return points for each tool this has saved us from crashing. if i had to guess you need to move the z axis with the x axis at the end of your program.

I still dont understand how either a x only line in the program can move both z and x, or how a programmed move can be skipped...those are the two situations that have occurred, only on the OSP7000 equipped lathes.
I need to call the rep anyway, maybe they can shed some light on this

[littlerob]

here is a part program, start, to crash...
/m90
g50 s2000
g94
n101 g0 x35. z35.
n102 t0909right here!! did it change tools?
/g97 s2000 m3
/m8
g0 x7.1743 (crash z never moved away, x drove right thru workpiece)

If it changed tools than you were up against what the machine considers the soft limits, and that would be your problem, something changed!! System parameter or User parameter. It is not going to index if it isn't against the stops (unless you know how to make it). And if it didn't index it didn't complete the block and would not proceed.

As to your other question about restarting, if you re-start inside a canned cycle it may not restart at a safe distance. IE If you restart on a sequence number that is a bar in the bottom of a bore it will travel to that spot on both axes until it reaches that spot-- CRASH. You have to be very cautious restarting on sequence numbers.

Robert

[tc429]

they dont use any canned cycles here at all...everything is high volume production, faster to optimize than use a canned cycle usually.

these lathes are horizontal/moving spindle/z axis points towards the operator. load position is x full right, z full out, putting the chuck right at the door. the turret was already on station 9 before he started it. the x35.z35. should have just retracted the z all the way back, as x was already on its limit- for some reason, sometimes the z will not move at all, the next move line going to x7.whatever just broadsides the part into the turret. that was the one that happened a couple days ago.

a couple weeks ago, he showed me how starting from the second tool in the program, (turret already back and away at limits) the tool indexes, then on the first move line (x only commanded) he hit feedhold- x distance to go was off by like 8 inches, and z distance to go was like 12 inches- BUT THERE WAS NO Z move programmed on that line. moving a axis that is not programed cant be right, but he said all of them do the exact same thing if not started from the beginning of the program...
I was just hoping someone might know what could cause this, hoping some modal g code thats stacking or not clearing tool geometry offsets or something- or somehow improper reset procedures arent cancelling the last move that was held before manually resetting and going to another line in the program- although I would expect if that were the case, the move would resume at cycle start, not several lines in at the first motion block...
ive seen wear offset cancellation issues on a couple version of Fanuc zero controls, but nothing like this.

[tea hole]

Without seeing the code, it is difficult to help. I do know that if you do a program restart mid program that the machine goes to the last known position before the N line you are after. Usually in lathes unless I have compound macros that calculate at the begining of a program, I don't use the "program restart" feature, rather, program each tool that I can just press interlock and cycle start to begin from a preceding M1 with all the modal commands and safe positions in place.

[OkumaWiz]

On Okumas, when you call up a tool offset, the offset becomes effective on the first "move" so if there is any Z offset in the tool data register, that amount will become effective during the first move If it is only an X move, the Z will move also based on the amount in the tool data.

Normally this is not enough to cause a crash, but it sounds to me like they may have touched off the tools wrong or hit SET when they should have hit ADD.

Do you have large offsets?

During restarts, the tool will travel shortest path back to the restart point and starts on the block previous to the one commanded in order to make the one you want to restart on effective next. The previous tool also becomes effective if you start on the T0909 line. Sometimes if you tell it to restart on X35 Z35 you may get both a Tool index and a rapid to the part that you may not be expecting. Restart points are critical.

Another thing is what technique of restart are you using? By RESTART and either block number or line number, or by INTERLOCK and cycle start?

Interlock + cycle start does not read the program, so offsets may not even be effective depending on where you pick to restart.

The only other thing I can think of at the moment is if you put X and Z coordinates on the G50 line. This would cause a program shift and very easily cause crashes.

To eliminate all of these problems, turn on single block, turn your feed rate to zero and watch you distance to go screens when restarting from a clear point. You will see what is going to happen before the unexpected BANG occurs.

Best regards,

Just some food for thought for you.

[littlerob]

I promise you this is O.E. I have seen a machine totally crash as a result of electrical problems. (also O.E. really) I let the coolant drip off the top of the door onto a relay that was mounted on the back of the front enclosure, and wow that made big problems. But I am willing to bet, this is not a malfunction. $100 bet? takers, makers?

Robert

[tc429]

Another thing is what technique of restart are you using? By RESTART and either block number or line number, or by INTERLOCK and cycle start?

Interlock + cycle start does not read the program, so offsets may not even be effective depending on where you pick to restart.

I do not know how they are stopping/restarting- but assume as we have hundreds of Fanucs, they are doing the same old edit/program/reset/cursor to line/cycle start?

The only other thing I can think of at the moment is if you put X and Z coordinates on the G50 line. This would cause a program shift and very easily cause crashes.

will check- all our older Fanuc lathes use either g50 x/z or g92 x/z depending on g-code system, newer ones use geometry offsets, Fanuc mills use g50 x/y/z if they dont have g54~g59 available.
sounds like g50 x/z on okuma is like a 'work shift' on a Fanuc...most machines require careful use, we just dont use it at all

To eliminate all of these problems, turn on single block, turn your feed rate to zero and watch you distance to go screens when restarting from a clear point. You will see what is going to happen before the unexpected BANG occurs.


Best regards,

Just some food for thought for you.

will pass that along to setup- hate to HAVE to do something new to prevent intermittent crashes, but youre right- until we find out whats different from our Fanucs, it could prevent a crash.

I'll try to get him to show me the x+z thing on the x only line again and post up the g-code in here later...I'm betting someone will be able to see exactly why it does it.
thanks,
Tim

[broby]

When performing a restart, the machine will attempt to re-establish all conditions that should normally exist if the program had run from start to the restart point in the program.
In the program fragment you supplied, if you restart on line N102 T090909 the machine will first rotate the turret to the previous tool (if the machine is on the soft limit) and then the machine will attempt to move into position with the tool offset being activated also.
Obviously if you are on one limit the turret can index, it the resulting index brings a tool around that will hit the chuck/job your will be in the doggy dodo...
You need to restart on line after N102 for the machine to not index first.
Also if the operator is not reducing the rapid override to safe levels before hitting the "restart" button and things are not as expected, you WILL crash!
ALWAYS have your rapid set to zero or 5% BEFORE hitting the restart button!
THAT IS JUST GOOD PRACTICE!
Get used to reading your distance to go also.
It also sounds like that you must have large offsets on some of the tools, resulting in large moves as the machine tries to move the tool point to the desired position, X and or Z programmed or not.
Cheers
Brian.

[OkumaWiz]

I do not know how they are stopping/restarting- but assume as we have hundreds of Fanucs, they are doing the same old edit/program/reset/cursor to line/cycle start?
If you do it this way NOTHING is read and you will crash. Use:EXTEND>RESTART>NT9>WRITE wait for the program to advance & press SEQUENCE RESTART (of course have single block ON & feed rate @0%)


will check- all our older Fanuc lathes use either g50 x/z or g92 x/z depending on g-code system, newer ones use geometry offsets, Fanuc mills use g50 x/y/z if they dont have g54~g59 available.
sounds like g50 x/z on okuma is like a 'work shift' on a Fanuc...most machines require careful use, we just dont use it at all
Good - not the way to use an Okuma.




will pass that along to setup- hate to HAVE to do something new to prevent intermittent crashes, but youre right- until we find out whats different from our Fanucs, it could prevent a crash.

I'll try to get him to show me the x+z thing on the x only line again and post up the g-code in here later...I'm betting someone will be able to see exactly why it does it.
thanks,
Tim

Re-read my previous post. I'm sure it explains what is happening to you.

Best regards,