Beware - Canned Cycles buggy (and dangerous) in DWO

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.

heh, that's funny, I'm chasing that same exact thing around right now.

Your code samples lack context. I'm assuming these are using G254 at some point. This behavior is also different using G98 or G99. You have an R plane like you're using G99, but i can't see how you're using either of those in your code.

From the Haas UMC 750 supplemental manual (https://diy.haascnc.com/sites/defau...ent/UMC/2017/96-8250_revG_umc750_Dec_2017.pdf)

"After G254 is invoked, you must specify an X, Y, and Z Axis position before a cutting command, even if it recalls the current position. The program should specify the X and Y Axis position in one block and the Z Axis in a separate block."

coyoinu said:

heh, that's funny, I'm chasing that same exact thing around right now.

Your code samples lack context. I'm assuming these are using G254 at some point. This behavior is also different using G98 or G99. You have an R plane like you're using G99, but i can't see how you're using either of those in your code.

From the Haas UMC 750 supplemental manual (https://diy.haascnc.com/sites/defau...ent/UMC/2017/96-8250_revG_umc750_Dec_2017.pdf)

"After G254 is invoked, you must specify an X, Y, and Z Axis position before a cutting command, even if it recalls the current position. The program should specify the X and Y Axis position in one block and the Z Axis in a separate block."

Click to expand...

Yes, in DWO using G254...
Just trying to keep a long post a little shorter. Here you go:


G98/G99 doesn't matter as far as the crash condition is concerned. Sure you can use those to either stay at R or initial level for all the holes in one cycle but the second cycle is where you'll have problems. My original problematic program I sent Haas was:


Sure, G99 keeps the tool at R-level between holes, but the program still crashed after the 4th hole. Removing or different combinations of G98 or G99s had no affect on whether or not it crashed.

are you near union city, by chance?

looks like we touched this problem 8/10 of last year and pretty much came to the same conclusion about how to use the code. nice job on figuring out the fix, it took me half a day to rediscover the workaround on my own.

it also sounds like running this same code on an older Coldfire machine would give similar results. It's just a quirk with how DWO works. Your sample code, using G54, will work as written, but one must be more verbose with positioning in DWO mode.

how are you writing this code? maybe a post processor could use some updating.

coyoinu said:

how are you writing this code? maybe a post processor could use some updating.

Click to expand...

What would you change about the formatting?

Please excuse the sloppy pseudocode. There should be a segment in your post describing a canned cycle like this:

<Cycle 84> G (84) X Y Z R F

You probably need to format canned cycles something like

<Cycle 84> G (0) X! Y!; (usually theres an operator to force output even if the position doesn't move)
G (0) Z!;
G (84) X Y Z R F;

In the Fusion / HSM post processor, the appropriate segment seems to handle G98 and G99 differently:

case "tapping":
F = tool.getThreadPitch() * rpmFormat.getResultingValue(tool.spindleRPM);
writeCycleClearance();
if (gPlaneModal.getCurrent() == 19) {
xOutput.reset();
writeBlock(gMotionModal.format(0), zOutput.format(z), yOutput.format);
writeBlock(gMotionModal.format(0), xOutput.format(cycle.retract));
writeBlock(
gCycleModal.format(gCycleTapping),
getCommonCycle(x, y, z, undefined),
pitchOutput.format(F)
);
} else {
forceXYZ();
writeBlock(
gCycleModal.format(gCycleTapping),
getCommonCycle(x, y, z, cycle.retract),
pitchOutput.format(F)
);
}

Yes, it makes more lines of code, but I think we can agree more code is better than more crashes.

Before you start hacking away at the PP, we just had a meeting a few minutes ago about how to fix this specific problem in the next software release since the specific wording in the manual is slightly ambiguous (the latest software is 18.1010, probably out next week). I'll keep you posted about how we handle it, since I'm doing the QA on this problem.

Hopefully you guys can get it fixed sooner than later. Adding extra code for a post to spit out isn't a big deal, but this could really bite people doing simple parts, drilling/tapping/reaming... hand coding right at the machine. Punching out some code by hand at the machine is easy enough to do and if you aren't aware of this issue, it could really bite you.

In my situation, the program has not changed, however the machine has produced vastly different results, based on slight differences of the fixture location (vise isn't located with dowel pins or anything, just "close to center") and/or tool holder lengths. Those are the only differences between this latest run and previous. That will totally bite someone hand-writing a program at the machine. It might work that time fine, but next time could be a disaster.

Is hand-writing a simple program like that so unrealistic? I don't think so myself. Not everybody who runs these machines has the latest and greatest software to make it go. The only simulation I have is what Surfcam thinks it will do. I don't have any code-based verification. On the other hand, all the verification software in the world wont help you if the machine doesn't do what the code says it should do...


Since the original problem with the 8mm drill, I updated my post to spit out G0 XYZ between cycles, if more than one on the same side. This problem only came up again with the peck-tapping cycles. I guess sometimes the error wasn't enough for us to notice, but this time it was significant. I suppose I'll have to modify that macro to add extra rapid moves in the while/do loop.


Is this bug related to the incorrect distance-to-go display?

I looked at the distance-to-go bug, and it doesn't seem to be directly related to this problem but who knows. that fix also seems to be scheduled for 18.1020

A point of discussion we had earlier was how forgiving the software has been towards less than perfectly formatted code, allowing the canned cycles to run correctly while incorrectly specified as per the documentation. That will weigh into the coming fix, which I will test your original code also and give you some feedback.

I do think hand-writing this code at scale is unrealistic since the coordinate space moves around in hard-to-visualize ways during DWO. Possible, yes, but not for the faint-of-heart, kinda like hand programming mill-turn. Hand-editing is easier, for sure.

You are right about Surfcam, or whatever, only running an approximation of the code. I'd be surprised if Vericut could properly handle DWO weirdness without a lot of fussing around. It's even hard enough to find these problems in graphics mode versus run mode, or on a control simulator versus the machine with tools loaded and fixtures mounted.

Make sure that your updated post processor posts XY moves and Z moves on different lines before the canned cycle. It may work in other forms, but that's what's specified in the docs.

I'm trolling this forum every day during the week, so expect to hear back from me as soon as I get a fix from the developers.

coyoinu said:

I looked at the distance-to-go bug, and it doesn't seem to be directly related to this problem but who knows. that fix also seems to be scheduled for 18.1020

A point of discussion we had earlier was how forgiving the software has been towards less than perfectly formatted code, allowing the canned cycles to run correctly while incorrectly specified as per the documentation. That will weigh into the coming fix, which I will test your original code also and give you some feedback.

I do think hand-writing this code at scale is unrealistic since the coordinate space moves around in hard-to-visualize ways during DWO. Possible, yes, but not for the faint-of-heart, kinda like hand programming mill-turn. Hand-editing is easier, for sure.

You are right about Surfcam, or whatever, only running an approximation of the code. I'd be surprised if Vericut could properly handle DWO weirdness without a lot of fussing around. It's even hard enough to find these problems in graphics mode versus run mode, or on a control simulator versus the machine with tools loaded and fixtures mounted.

Make sure that your updated post processor posts XY moves and Z moves on different lines before the canned cycle. It may work in other forms, but that's what's specified in the docs.

I'm trolling this forum every day during the week, so expect to hear back from me as soon as I get a fix from the developers.

Click to expand...

All,

Haas Automation recognizes the canned cycle Z depth problem while in DWO is as stated a problem and will be fixed. The scheduled fix version is 100.18.000.1030. This means the fix will be released mid October. I want to thank everyone for your feedback keep em coming as Haas Automation is always looking to continuously improve and get as close to perfect as possible.

Thank you,

PMC

PMCCNC said:

All,

Haas Automation recognizes the canned cycle Z depth problem while in DWO is as stated a problem and will be fixed. The scheduled fix version is 100.18.000.1030. This means the fix will be released mid October. I want to thank everyone for your feedback keep em coming as Haas Automation is always looking to continuously improve and get as close to perfect as possible.

Thank you,

PMC

Click to expand...

I've since been using my own macro for DWO. I aliased my own programs to G254 & G255. Will probably just continue to use it, unless the distance-to-go is fixed by then. I guess if I get both in an update I'll go back. Coyoinu reports it the distance bug will be fixed by 18.1020? so by 100.18.000.1030 they should both be corrected?