Cant figure out CRASH

[dlewis1000]

So today we had something weird happen. A program hit an M00 and upon hitting cycle start the tool and holder plunged straight down into the jaws of the vise. That sucked. So yesterday we ran a program with the exact same format with no crash. We verified it isn't a code problem. The only difference was that when the crash happened, the operator put the machine in handle jog to move the head up so he had room to work. When he hit cycle start, it's like the machine forgot its G43 offset. The code is attached and it happened at the M00. If we run the same code without moving the machine manually between the time of the stop and the time we hit go again it runs just fine. Could this be a setting or parameter issue? I have jogged machines around when I hit an stop with no problems in the past. I'm a little stumped here and now I feel bad because the operator is all nervous not knowing what caused that to happen.

Similar Threads:

• Need Help!- See if you can figure this one out!
• Need Help!- I Still Can't Figure It Out
• Help me figure out if this is possible.
• Can someone help figure this out, please?
• Can't figure out why...

[steve pies]

i cant say why it happened but many machines have a "Run-Stop-Jog-Continue" feature. if your model / year has it i would stick with that.

[Ydna]

I think it did exactly what you mentioned, the controller loses the active height offset when jogging, then when you jumped back into Mem mode it carried on with no active height offset. It allows the mill to move its probe reference plane (spindle nose) to your workpiece's Z-zero plane, and the tool in between gets crunched. It'd be as if you ran your code like normal but then deleted the tool's H-value from the offset page, effectively saying the tool has no physical height.

Personally I really avoid stating an M0 in the program unless the next couple lines include the start-of-module codes for things like the work offset, spindle start, and G43 Hxx. It might waste some movement in resetting those things, but it may prove to be more reliable for cases like this.

[dlewis1000]

I think it did exactly what you mentioned, the controller loses the active height offset when jogging, then when you jumped back into Mem mode it carried on with no active height offset. It allows the mill to move its probe reference plane (spindle nose) to your workpiece's Z-zero plane, and the tool in between gets crunched. It'd be as if you ran your code like normal but then deleted the tool's H-value from the offset page, effectively saying the tool has no physical height.

Personally I really avoid stating an M0 in the program unless the next couple lines include the start-of-module codes for things like the work offset, spindle start, and G43 Hxx. It might waste some movement in resetting those things, but it may prove to be more reliable for cases like this.

Normally I would agree with you, but it did it again while our second shift operator was running it. The machine is a HAAS VF4ss with a next gen control on it. Nice new machine. What's weird is that we ran that cycle a few times with the M0 and it did not crash. How can it crash only sometimes with the same code? I think I need to just use the force tool change command in my CAM between the stop and the next operation to force it to call up the offsets again. While that's a fix that I am going to do today, I still am curious.