thesidetalker
Stainless
- Joined
- Jan 11, 2015
- Location
- Bay Area, CA
Just want to warn others about this, since it appears Haas doesn't have any intention of fixing it.
Original problem happened July last year. Reported it then, supposedly they were able to reproduce the problem, and it was logged as a bug. This is on our UMC750SS with the NGC.
The original problem was drilling two sets of holes at different depths on the side of the part using DWO. After the last hole, instead of retracting to initial Z, the drill plunged into the part further than the drill depth.
Eg.
Z1.
G81 X0 Y0 Z-1.0 R.1
G80
G0 X1. Y1.
G81 X1. Y1. Z-1.2 R.1
G80
Initial fix I found was between canned cycles, you must call out a rapid move of not only XY to the next position, but Z as well. (even if values not changing!)
Z1.
G81 X0 Y0 Z-1.0 R.1
G80
G0 X1. Y1. (Z1. - this can be all one line, or two.)
Z1.
G81 X1. Y1. Z-1.2 R.1
G80
All was good (I thought) up until just recently, I was tapping some holes with my peck tapping macro. On the second depth, the program plunged through the part, pushing the material out of the vise and stopping about 1mm short of the spindle nose hitting the vise. Repeat and proven program no less.
Wrote to my HFO asking WTF? We had our software updated just recently and I would've thought this was fixed by now. Originally they told me maybe October last year. The knowledgeable tech that usually helps me out showed me on their log, the bug listed as "WONT FIX/INVALID". Cool...
Anyway, the problem seems to be with ALL canned hole cycles, not just G81. I didn't catch this before now for two reasons. First because of my bandaid fix I found of using G0XYZ between canned cycles seems to fix most. Second, the amount of which the retract is off by varies time to time, depending what your offsets are (and tool lengths probably) Sometimes so little you don't notice unless you're looking at position page. Maybe 0 - 0.050".
This latest crash happened since I was using my peck-tapping macro. It uses a while/do loop to call G84's at increasing depth. Well with no XYZ call between any of those G84's, the machine is free to fuck up and retract to whatever Z level it feels like. In this recent case, through the part.
My proven program that decided it didn't want to run just for that day, has a cycle for each hole. Like below:
G204 X0.5394 Y0 Z0.0828 R0.5528 F13.7795 Q0.16
G204 X0.1642 Y0 Z0.0828 R0.5528 F13.7795 Q0.16
I wondered if maybe the control didn't like the while/do loop, which has worked fine before (and is perfect on the older control)
Changed those to G84's:
G43 H37 Z1.4527
G84 X0.5394 Y0 Z0.0828 R0.5528 F13.7795
G80
G84 X0.1642 Y0 Z0.0828 R0.5528 F13.7795
G80
and it still resulted in plunging to some arbitrary Z value after the second hole, instead of initial Z.
I added rapid moves between the holes:
G43 H37 Z1.4527
G84 X0.5394 Y0 Z0.0828 R0.5528 F13.7795
G80
/ G00 X0.1642 Y0
/ Z1.4527
G84 X0.1642 Y0 Z0.0828 R0.5528 F13.7795
G80
Block skip off, no crash: block skip off - YouTube
Block skip on, crash: block skip on - YouTube
(you can see the test program in the video description)
Seems to have the same error with other cycles. I tried changing those G84's to G81&G84, G81&G81, G81&G85, and all had the same results.
So... two fixes. First, if using more than one canned cycle in a row with DWO on, be sure to use G0 XYZ between each one.
Or second, make your own DWO macro. I'm testing one right now, aliased over G254/G255. It works just like the 4axis one I posted in another thread, using G52 to offset the current WCS. Tried mine on the above examples and the canned cycles work as they should. Need to do more thorough testing at different angles and offsets though, then later I might post it in this thread.
Original problem happened July last year. Reported it then, supposedly they were able to reproduce the problem, and it was logged as a bug. This is on our UMC750SS with the NGC.
The original problem was drilling two sets of holes at different depths on the side of the part using DWO. After the last hole, instead of retracting to initial Z, the drill plunged into the part further than the drill depth.
Eg.
Z1.
G81 X0 Y0 Z-1.0 R.1
G80
G0 X1. Y1.
G81 X1. Y1. Z-1.2 R.1
G80
Initial fix I found was between canned cycles, you must call out a rapid move of not only XY to the next position, but Z as well. (even if values not changing!)
Z1.
G81 X0 Y0 Z-1.0 R.1
G80
G0 X1. Y1. (Z1. - this can be all one line, or two.)
Z1.
G81 X1. Y1. Z-1.2 R.1
G80
All was good (I thought) up until just recently, I was tapping some holes with my peck tapping macro. On the second depth, the program plunged through the part, pushing the material out of the vise and stopping about 1mm short of the spindle nose hitting the vise. Repeat and proven program no less.
Wrote to my HFO asking WTF? We had our software updated just recently and I would've thought this was fixed by now. Originally they told me maybe October last year. The knowledgeable tech that usually helps me out showed me on their log, the bug listed as "WONT FIX/INVALID". Cool...
Anyway, the problem seems to be with ALL canned hole cycles, not just G81. I didn't catch this before now for two reasons. First because of my bandaid fix I found of using G0XYZ between canned cycles seems to fix most. Second, the amount of which the retract is off by varies time to time, depending what your offsets are (and tool lengths probably) Sometimes so little you don't notice unless you're looking at position page. Maybe 0 - 0.050".
This latest crash happened since I was using my peck-tapping macro. It uses a while/do loop to call G84's at increasing depth. Well with no XYZ call between any of those G84's, the machine is free to fuck up and retract to whatever Z level it feels like. In this recent case, through the part.
My proven program that decided it didn't want to run just for that day, has a cycle for each hole. Like below:
G204 X0.5394 Y0 Z0.0828 R0.5528 F13.7795 Q0.16
G204 X0.1642 Y0 Z0.0828 R0.5528 F13.7795 Q0.16
I wondered if maybe the control didn't like the while/do loop, which has worked fine before (and is perfect on the older control)
Changed those to G84's:
G43 H37 Z1.4527
G84 X0.5394 Y0 Z0.0828 R0.5528 F13.7795
G80
G84 X0.1642 Y0 Z0.0828 R0.5528 F13.7795
G80
and it still resulted in plunging to some arbitrary Z value after the second hole, instead of initial Z.
I added rapid moves between the holes:
G43 H37 Z1.4527
G84 X0.5394 Y0 Z0.0828 R0.5528 F13.7795
G80
/ G00 X0.1642 Y0
/ Z1.4527
G84 X0.1642 Y0 Z0.0828 R0.5528 F13.7795
G80
Block skip off, no crash: block skip off - YouTube
Block skip on, crash: block skip on - YouTube
(you can see the test program in the video description)
Seems to have the same error with other cycles. I tried changing those G84's to G81&G84, G81&G81, G81&G85, and all had the same results.
So... two fixes. First, if using more than one canned cycle in a row with DWO on, be sure to use G0 XYZ between each one.
Or second, make your own DWO macro. I'm testing one right now, aliased over G254/G255. It works just like the 4axis one I posted in another thread, using G52 to offset the current WCS. Tried mine on the above examples and the canned cycles work as they should. Need to do more thorough testing at different angles and offsets though, then later I might post it in this thread.