cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Want the oppurtunity to discuss enhancements to PTC products? Join a working group! X

Translate the entire conversation x

Is there a way to use Gpost to split an nc file in couple .tap-files

hheinze
10-Marble

Is there a way to use Gpost to split an nc file in couple .tap-files

Dear @KenFarley and @BryantMorgan,

With reference to this topic!

Is there a way to use Gpost to split an nc file in couple .tap-files?
So that Gpost looks for time or length?

 

I would like to use this information to export an "SET", and then let GPOST split it into different TAP-parts (every tool has then his own NCL-File).

That would make the explort of CL-Files easier.. because now we have to calculate every Step one by one becuase the NC-Machines/Worker prefer it that way.

ACCEPTED SOLUTION

Accepted Solutions
KenFarley
21-Topaz II
(To:hheinze)

I suppose it might be possible. You'd have to get pretty good at using FIL code to query and manipulate the code that is going to be output to the G-Code file. You'd have to look into the POSTF function calls that will get you the accumulated runtime for your program. For example, POSTF ( 1, 3, 0495 ) gets you the current runtime calculated by GPOST.

As I vaguely indicated in the previous discussion of this, you need to explicitly define what steps are to be taken when your tool has been "used up" or needs to be replaced. How are you going to retract from execution? What do you need to do to allow tool replacement? How are you going to adjust the tool offsets? How are you then going to bring the tool back into service? What is the re-entry path into the working area of the part?

You'll have to do a lot of testing, but more importantly figure out every single thing that needs to be done when it's time to change tools. Then get good enough at FIL code to implement everything.

This is no small order and not something anyone, including me, is going to provide on a message forum. Plus, it's just my estimate of how I might approach things, but no doubt as you get into it you'll find there are more problems to consider.

View solution in original post

2 REPLIES 2
KenFarley
21-Topaz II
(To:hheinze)

I suppose it might be possible. You'd have to get pretty good at using FIL code to query and manipulate the code that is going to be output to the G-Code file. You'd have to look into the POSTF function calls that will get you the accumulated runtime for your program. For example, POSTF ( 1, 3, 0495 ) gets you the current runtime calculated by GPOST.

As I vaguely indicated in the previous discussion of this, you need to explicitly define what steps are to be taken when your tool has been "used up" or needs to be replaced. How are you going to retract from execution? What do you need to do to allow tool replacement? How are you going to adjust the tool offsets? How are you then going to bring the tool back into service? What is the re-entry path into the working area of the part?

You'll have to do a lot of testing, but more importantly figure out every single thing that needs to be done when it's time to change tools. Then get good enough at FIL code to implement everything.

This is no small order and not something anyone, including me, is going to provide on a message forum. Plus, it's just my estimate of how I might approach things, but no doubt as you get into it you'll find there are more problems to consider.

Jep, thank you for that quick answer!

 

This is not worth the time and as you said, it is very complicated.

Announcements

Top Tags