[jheers]

I'm running a Haas VF-4, not exactly sure on the year, but it is relatively new, with the GUI, pretty sure it is less than three years old. I haven't had this problem before, but now it has happened on two separate programs in short succession. Most of the program is running fine, but when it gets to the G83 line, the machine stops moving. The coolant stays on, the spindle keeps spinning, and the readout on the GUI displays the right feedrate, but the machine is not moving. There are no errors, and the screen appears as if nothing is wrong. It happens on the G83 line in the G55 workshift in the following code:

G00 G90 G80 G17 G40 G49 G54
G00 X-0.1595 Y0.
M06 T2
G43 H02 M08
M03 S3400
G00 Z1.
G01 Z0.1 F30.
G83 Q0.05 R0.1 Z-0.17 F6.8
X-0.5875
G80
G00 Z2.

G55
X0.1595 Y0.
G00 Z1.
G01 Z0.1 F30.
G83 Q0.05 R0.1 Z-0.17 F6.8
X0.5875
G80
G00 Z2.

I didn't write this program myself, so the syntax is a little different from what I would use, but I don't see any obvious errors like missing decimals. If anyone knows what is happening, I would love to know.

[Geof]

As a quick test try putting X Y coordinates in the G83 line. There is a Parameter or Setting, I forget which, that controls whether the G83 will act without any X and Y values.


Found it; Setting 28 CAN CYCLE ACT W/O X-Y

[txcncman]

Did you run it in graphic mode before executing?

Break it down. Move your Z tool length positive an inch and run the following:

G81 Z-0.17 R0.1 F6.8

If that works, add the second X position back in and run it.

If that works, change it back to G83 and add the Q back in and run it.

[jheers]

Just tried it, and it made no difference. Still stopping in the same spot.

[jheers]

Program runs flawlessly in graphics. Tried changing to a G81, this time it froze on the first pair of holes. Switched back to G83, it worked for the holes in G54 and G55, then froze on G56. Reset and tried again with no changes, and now it is freezing on the first pair of holes. I'm beginning to wonder if it isn't a controller issue.

[jheers]

Alright, seems like I "solved" the problem. The machine didn't seem to like moving in rapid to a pre-position, then feeding in Z, then running the canned cycle. I first just rewrote the problem section of the program to make sure there wasn't something that wasn't readily visible, and so it was in a format with which I am more familiar. I used the same positions and G codes, just in a slightly different order that is easier for me to read. This made no difference. Out of curiosity, I eliminated the linear move right before the pecking cycle, opting to rapid to an inch above the part, then use the R plane in the G83 command. When I ran the program it went perfectly. I always write my programs so that it does a rapid move to .1 above the part right away, whereas the new guy is a little more conservative, preferring to feed the tool from an inch above the part. Seems like I had been habitually avoiding a strange quirk I hadn't known about. Here is the new segment of code:

G00 G90 G54 T2 M06
X-0.1595 Y0
S3400 M03
G43 H02 Z1. M08
G83 R0.1 Z-0.17 Q0.05 F6.8
X-0.5875
G80
G00 Z2.

G00 G90 G55
X0.1595 Y0
G00 Z1.
G83 R0.1 Z-0.17 Q0.05 F6.8
X0.5875
G80
G00 Z2.

I would still appreciate an explanation if there is one, but for now it seems the problem has at least been circumvented.