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

[hheinze]

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.

[KenFarley · Accepted solution]

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.

[hheinze]

Jep, thank you for that quick answer!

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

[BF_14259101]

Hi,

This shouldn't be that difficult to do with GPOST.   I set my FIL up so that certain conditions trigger RESTAR flag, I could just track time and when time hits the limit, trigger the restart.  In addition, my FIL has 4 different ways to safely retract and reaproach the part if the trigger happens mid-cut.  The restart macro could be modified to create a new tape.  A new vocabulary word could be created to make settings.  The problem is that you are going to only want to track time below a feedrate threshhold or when not at RAPID, if you are only concerned about tool wear.

Sky is the limit if you have some programming and post-processor experience.  Otherwise, it is pretty tough.

However, I wouldn't do it this way as I wouldn't want to add to post-processing time.

I have a utility originally written in FORTRAN for breaking up programs based on tool cutting time which I recently rewrote in PYTHON.  These utilities run lightening fast and run on the import APT file as a sort of pre-processor before running G-POST..  I use it often when programming hard metals and it is very configurable, doing just about anything you want when you hit the "limit".

If interested, I may be able to help out.  Find me at www.trueprecisioncnc.com

[hheinze]

When I read all of this, it should be really easy to realize what I want:
Split programs when a new tool is selected.

I do not understand why PTC did nto implement this in the fiorst place: run through all steps instead of only one by one or all into one.

And for you, who knows this language: is there no "one liner" that just creates a new file when a new tool is called?

Ok, it is not a one liner.. btu lets say 5 lines 🙂