Tapping cycle posting seems messed up

[JeremyV]

I've noticed how the tapping parameters in the tap dialog box when you want to edit the tool is so different from X6 to X9.

 

That being said, I realized I had to click on the correct tap in the drop down list so the correct parameters came up and so the correct feeds post right between our Mazaks and HAAS.  I was able to fix that... however...

 

The Kuraki doesn't seem to want to post the right way and that post processor file is.... 13+ years old.  I was wondering if anyone had any issues?  Some of the feed rates for the Kuraki came to F90125. (as if it can tap THAT fast LOL)

 

I'm thinking the tapping code in the post file needs adjusting somewhere...

 

-JD

[JeremyV]

This is our current tap cycle:

 

ptap$        # Canned Tap Cycle
               #n, "(", "USE TAP FLUID", ")", e
               n$, "M29", pss,e$
           n$, p_lh_rh, g98_g99, *x$, *y$, *dpoint, *wrefht,*rontap,e$#pplunge
               #------Above is the original drill cycle line using the "W" to Drill/Tap--------------
               #------Below is the new line using "Z" to drill/Tap-----------------------------------
           #n, p_lh_rh, g98_g99, *x, *y, *z, *rrefht, *rontap  #pplunge

 

We would like to know the correct word/code to desiginate feed per tooth from the tool definition of mastercam so it posts correctly?   That is if anyone has any idea?

 

as a side note rontap formula is    rontap   = frplunge$ * ss$

 

Edit: I tried incorporating this formula:       rontap  = (1 / n_tap_thds$) * ss$     that formula works... sorta... except posting causes an error message to appear saying "The formula is attempting to divide by zero, , Calculation returned zero"

[Ben Wood]

Looking at one of my posts the one thing that looks different is the space before and after the /

Try (1/n_tap_thds$) instead of (1 / n_tap_thds$)

[JeremyV]

Well... I tried a variety of combinations with that formula to no avail. The formula works great, but there is something in the Kuraki post file that is giving me an error still... something about the "formula is attempting to divide by zero"... not sure where this is coming from.

 

Ben - I tried that, posting still throws errors, but the formula works =\

[Guest]

If you want to shoot it to me at 

 

jmparis65 @ gmail dot com

 

a z2g that incluses a file, post, control & machine def, I'll take a gander

[Guest MTB Technical Services]

Well... I tried a variety of combinations with that formula to no avail. The formula works great, but there is something in the Kuraki post file that is giving me an error still... something about the "formula is attempting to divide by zero"... not sure where this is coming from.

 

Ben - I tried that, posting still throws errors, but the formula works =\

 

 

FWIW, When I am working on posts, and that included other systems as well.,

I always build logic if the possibility of division by Zero exists.

If you assign a value of 0.00000001 to what is Zero you can prevent the error and the formatting

of the address should handle the rest.

As a practical matter assigning a value that is at least one decimal place greater in precision than the formatting for the output,

you should be OK.

 

I do this for all 5-Axis posts as it's possible to have a vector value of 0 pretty regularly.

 

Given the age of the post, it sound like something that can occur from using the Post Update C-Hook.

If anyone can find the bug, it will be JP.

[Colin Gilchrist]

If you select a Tap cycle, but don't have a Tap tool selected, you will get a divide by zero error due to the fact that your tool doesn't have any Threads Per Inch assigned to the tool. (This could also happen if you create a new tap, but make the number of threads per inch zero. (If the dialog box even lets you...)

 

You could potentially add some logic to catch the error, and assign a small decimal value as Tim mentioned, but in this case I would rather see the error. This just lets you know you've got something wrong with your tap definition.

 

Fixing your tool (you should also force a regeneration) should eliminate your error...

[Guest MTB Technical Services]

If you select a Tap cycle, but don't have a Tap tool selected, you will get a divide by zero error due to the fact that your tool doesn't have any Threads Per Inch assigned to the tool. (This could also happen if you create a new tap, but make the number of threads per inch zero. (If the dialog box even lets you...)

 

You could potentially add some logic to catch the error, and assign a small decimal value as Tim mentioned, but in this case I would rather see the error. This just lets you know you've got something wrong with your tap definition.

 

Fixing your tool (you should also force a regeneration) should eliminate your error...

 

 

Great information!

 

With ESPRIT I do something similar to what Colin suggests.

Unfortunately, ESPRIT actually lets you pick any tool for a Tapping Cycle.

 

The ESPRIT API makes it easy to interrogate the operations before posting to make sure the tool is defined properly and is the correct type.

[JeremyV]

We do have threads per inch assigned to all taps.

 

Would it help to post the entire post file?    If I do how do i go about doing so?   Post as code so it doesn't cover the entire screen?

 

I'm not sure where the zero is really coming from =(  I'm hoping another set of eyes might catch it if possible =)

 

And thanks!

 

-JD

[Guest]

Waiting to hear back on the change...

 

The reason for the error, this post is old, very old, circa 2001

 

The processing of post blocks has changed, this formula was defined very early in the post and not in the ptap section.

 

So what is happening is while the post is processing all of the variable and formats being set, it is also trying to process that formula, as such the formula doesn't have all of the needed info at that point as tool path processing has not yet begun....

 

I altered and moved the formula into the ptap section and also altered the formula as the n_tap_thrds$ variable didn't exist when this post was written, so the number of threads had to be calculated, no longer as they are defined in the tool definition.

 

so your new formula is

 

rontap = (1/n_tap_thrds$) * ss$

[JeremyV]

Sorry to keep you waiting - I was so busy I forgot about this till i looked at my e-mail at home.  Many apologies!

 

I ran the code this morning and it worked beautifully!  MANY THANKS!!!!!!!

 

We have 3 Kurakis total and I adjusted the code to match what was changed and those worked like a charm.

 

It was awesome. I never thought to put the formula in the ptap section.

 

 

 

 

As a side question, we are going to get 2 new machines to replace our againg Mazaks.... a lathe and a mill.... with DOOSAN.  I'm fairly sure we will need a post file from the dealer on both machines to start or is there a generic template I can use within mastercam or?  I just wanted to ask for future reference as a just in case sorta thing.

 

 

The reason for that was when we got the HAAS 5 years ago, we modified a mazak post file to be compatible with a HAAS, but of course, it was from an old post file around 2001 as well.  it works, unless I should be using something else?