Community Tip - Visit the PTCooler (the community lounge) to get to know your fellow community members and check out some of Dale's Friday Humor posts! X
I am learning Creo NC(milling) and have run into an issue. When the following situation occurs, it will omit the "G1" causing the tool to enter the next cut at rapid instead of feed. Not good. It appears to be tied to using the parameter value for "free_feed" to anything other than "0"
Here is a code example and more info below it explaining the details.
If a new sequence is created where the tool repeats, is using “free_feed = 500” or any value other than zero and follows a previous sequence that posts out a “G0” rapid move, then it does not post out a “G1” with the first linear feed move. It will omit it the “G1” and enter the cut in Rapid.
If you set the “free_feed = 0” in the constant load vol mill it will then output the “G1” correctly. This will not resolve the problem because the tool then moves in “G0” rapid during the retract tool motions risking damage to the tool and workpiece. The only solution I have found is to set the post to handle the “G1” as non-modal. This resolves the crash but makes the program unnecessarily large due to the redundant entries.
The toolpath I'm trying to achieve is a roughing operation like Mastercam's Dynamic Milling. So close but can't get it to post out cleanly.
Does this look like a post issue or some parameter I'm overlooking?
Mike Swan, Tool design
Great Plains Mfg
Solved! Go to Solution.
Mike,
CL is correct. Definitely postprocessor problem. I'm guessing somebody had customized postprocessor to output smoothness factor and had overwritten the default handling for G1/G0. You should post with a generic 3x mill and compare the results with your output. This will help you to debug the problem.
Feliks.
Hi all,
Mike, you should take a look at your 'CL Data' (similar to Mastercam NCI data). What you had shown here is a HAAS posted g-code. It is hard to pinpoint the problem - could be either your operation settings or your postprocessor settings, most likely it is postprocessor. Whatever you had marked yellow plus N90 line looks like canned postprocessor tool change output. You should search CL Data for LOADTL, RAPID and FEDRAT lines and compare it to your posted code.
Feliks.
Feliks,
I did look at the CL data and it had a FEDRAT line where I would expect it to be but it doesn’t output the G1 with the actual federate.
Would the FEDRAT normally be all that is required to output the G1?
Here is the snippet of the CL file where the problem occurs.
Seems like a post problem to me?
GOTO / 6.00000, -3.12500, 0.00000
RAPID
GOTO / 6.00000, -3.12500, 2.00000
SET / OFSETL, OFF
$$-> END /
$$-> FEATNO / 283
$$-> BLOCK_START /
INSERT//G187P1E100$'
$$-> BLOCK_END /
PPRINT / NC SEQUENCE NAME : VOLUME_MILLING_1
SET / OFSETL, 54
$$-> CSYS / 1.0000000000, 0.0000000000, 0.0000000000, 0.0000000000, $
0.0000000000, 1.0000000000, 0.0000000000, 0.0000000000, $
0.0000000000, 0.0000000000, 1.0000000000, 0.0000000000
FEDRAT / 500.000000, IPM
GOTO / -6.06055, 3.18015, 2.00000
GOTO / -6.06055, 3.18015, 1.00050
FEDRAT / 30.000000, IPM
GOTO / -6.06055, 3.18015, 0.80050
GOTO / -6.08800, 3.16168, 0.18442
GOTO / -6.10659, 3.14084, 0.00691
GOTO / -6.11760, 3.11711, -0.09722
GOTO / -6.12121, 3.09025, -0.16328
GOTO / -6.11708, 3.05916, -0.19736
Thanks for looking into it.
Mike
Mike,
CL is correct. Definitely postprocessor problem. I'm guessing somebody had customized postprocessor to output smoothness factor and had overwritten the default handling for G1/G0. You should post with a generic 3x mill and compare the results with your output. This will help you to debug the problem.
Feliks.
I downloaded a post from PTC and it resolved the issue.
Thanks for the suggestion.
Mike