Missing "G1" causes a crash

[mswan]

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

This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

[FV]

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.

[mswan]

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

[FV · Accepted 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.

[mswan]

I downloaded a post from PTC and it resolved the issue.

Thanks for the suggestion.

Mike