Jump to content

Welcome to eMastercam

Register now to participate in the forums, access the download area, buy Mastercam training materials, post processors and more. This message will be removed once you have signed in.

Use your display name or email address to sign in:

Problem with TCP when rotaries are singly specified


PAnderson
 Share

Recommended Posts

Hello everyone. Can I ask for some help with a TCP problem? I have a Fanuc 31i-B5 control. I have toolpath that uses TCP but when it gets to the portion of the toolpath where only the rotaries are specified, no X, Y or Z, the feed slows way down almost to nothing. Feed is specified at 150IPM in the program. I'm hoping this is a parameter or some other ilk like that. It almost seems like Inverse Time is being invoked but is that possible?

 

(OPERATION 11)
( SWARF END CUT THE 45 CHAMFER MULTIAXIS MILL2 )
N20X.7873Y-.0001
G5.1Q1R5
G43.4H1
Z.2415
X.7166
G01X.6459Z.1001
X.9994Y0.Z-.2534F150.
Y-.9994C-2.2008B43.9411
C-4.7425B42.8171 (PROBLEM STARTS HERE)
C-7.3912B41.7518 (FEED SLOWS WAY DOWN)
C-10.1492B40.7498 (ALMOST TO NOTHING)
C-13.0174B39.8162
C-15.3911B39.1218
C-17.834B38.477
C-20.3441B37.8844
C-22.9187B37.3464
C-25.554B36.8656
C-28.2452B36.4442
C-30.9865B36.0844
C-33.7713B35.7881
C-36.5918B35.5568
C-39.4397B35.3919
C-42.306B35.2943
C-45.1814B35.2645
C-48.0561B35.3028

 

Thanks, Paul

Link to comment
Share on other sites

check your Control Definition to see what your feed settings are set to, I am not sure what is recommended for your machine but there is only a few it can be f you want to give Units per minute a try or Inverse. Machine tab --> machine definition --> edit control definition --> Feed

a.jpg

Link to comment
Share on other sites

Firstly is this a head/head, table/table, or head/table machine?  This will make all the difference in the world.

When there is no linear motion it just becomes degrees per minute.  IIRC there is a parameter setting in the control that will control the machine behavior in this case, making it move at the speed and accel limits that AICC sets, and move at "rapid" when there is no "xyz traverse" associated @ TCP.

I'd start there, or just switch to metric feed rates so the angular rates "become" much higher 🤨, or inverse time as said above would certainly help.

Bottom line, proper settings with TCP you should never need inverse time, and if you have no XYZ, properly setup in the parameters, should move at max "safe" speeds as determined by AICC.

 

On a table/table machine, you could also change to output code in part coordinates, which would force x/y/z on all moves and then the machine would be forced to calculate feedrates on every move.  However it should be doing this anyway.  Something seems funky with your machine parameters.

 

  • Like 1
Link to comment
Share on other sites
7 hours ago, huskermcdoogle said:

Firstly is this a head/head, table/table, or head/table machine?  This will make all the difference in the world.

When there is no linear motion it just becomes degrees per minute.  IIRC there is a parameter setting in the control that will control the machine behavior in this case, making it move at the speed and accel limits that AICC sets, and move at "rapid" when there is no "xyz traverse" associated @ TCP.

I'd start there, or just switch to metric feed rates so the angular rates "become" much higher 🤨, or inverse time as said above would certainly help.

Bottom line, proper settings with TCP you should never need inverse time, and if you have no XYZ, properly setup in the parameters, should move at max "safe" speeds as determined by AICC.

 

On a table/table machine, you could also change to output code in part coordinates, which would force x/y/z on all moves and then the machine would be forced to calculate feedrates on every move.  However it should be doing this anyway.  Something seems funky with your machine parameters.

 

Thank you Husker, my thoughts exactly. This is a table-table machine. I did find the parameters for feed in AICC when only the rotaries are posted. But 8466 says that if it is set to 0.000 then it should use the programmed feedrate and it also related to 8466. Currently, these two parameters are both set to 0.000 which should force it to use the programmed feedrate but it does not. I could place a set value in those parameters but that might not work for every case.

image.png.e2cc958dd130ef782771fcf983599e86.png

image.png.d3f83f1ad450184b56a9e79e3b864048.png

Link to comment
Share on other sites
24 minutes ago, PAnderson said:

but that might not work for every case.

Good thoughts.

Have you tried programming in workpeice coordinates instead of table coordinates where the programmed point is in relation to the moving part instead of fixed to the machine base axes, might force proper xyz output and resolve a feedrate properly?

I'd also look at trying Inverse time feedrate and see if the problem goes away.  I personally don't think it should make a difference, it seems there is something else off parameter wise that is preventing the machine from "speeding" up and resolving the proper feedrate.  Is it supposed to be feeding in part coordinate XY but accomplished only with rotary motion?

Link to comment
Share on other sites
11 hours ago, huskermcdoogle said:

and if you have no XYZ, properly setup in the parameters, should move at max "safe" speeds as determined by AICC.

Heidenhain does this by default.

You can edit-in a secondary feedrate directedly after TCMP code that'll limit this max speed.

Link to comment
Share on other sites
On 9/4/2019 at 11:23 AM, huskermcdoogle said:

Good thoughts.

Have you tried programming in workpeice coordinates instead of table coordinates where the programmed point is in relation to the moving part instead of fixed to the machine base axes, might force proper xyz output and resolve a feedrate properly?

I'd also look at trying Inverse time feedrate and see if the problem goes away.  I personally don't think it should make a difference, it seems there is something else off parameter wise that is preventing the machine from "speeding" up and resolving the proper feedrate.  Is it supposed to be feeding in part coordinate XY but accomplished only with rotary motion?

Just an update. Still not solved. All of our machines are locked to the table, not the machine coordinate system. My understanding of TCP is that the velocity of the tool tip must be maintained in relation to the workpiece. But this is not happening. Rick Schultz from Fanuc is involved now. Agrees it should be a parameter but his first suggestion did not work. Problem is, with Fanuc at least, it could be any number of parameters. Also wanted to say thanks to those who replied.

 

regards,

Paul

Link to comment
Share on other sites
2 hours ago, huskermcdoogle said:

What do you have in 19696 #6?

That is set to 1. We seem to have all these basic parameters well set. We even ran this by Seimens and they said it is not related to TCP or AICC. Just related to rotary moves specified singly, without linear axis moves. So, time for a programming change to a toolpath that doesn't spit out these rotary only moves. Problem is, this is a customer that is brand new to 5 axis and thinks picking a different style of toolpath is a "work around".

 

Thanks again Gentlemen,

Paul

Link to comment
Share on other sites
On 9/5/2019 at 4:11 PM, PAnderson said:

Problem is, this is a customer that is brand new to 5 axis and thinks picking a different style of toolpath is a "work around".

Well, I would agree with them....  With a properly setup post and a properly corresponding machine parameter set using TCP you should get what you are looking for.  I'm curious why the post isn't outputting XYZ moved with the rotary since you are running table coordinates.    But at the same point, it's interesting that even though only the rotaries are specified, I would think it would still result in linear machine movement.   Anyway, yeah likely a different toolpath, or just changing the way that toolpath is processing is the best approach.

Best of luck.

Link to comment
Share on other sites
On 9/9/2019 at 12:41 PM, huskermcdoogle said:

Well, I would agree with them....  With a properly setup post and a properly corresponding machine parameter set using TCP you should get what you are looking for.  I'm curious why the post isn't outputting XYZ moved with the rotary since you are running table coordinates.    But at the same point, it's interesting that even though only the rotaries are specified, I would think it would still result in linear machine movement.   Anyway, yeah likely a different toolpath, or just changing the way that toolpath is processing is the best approach.

Best of luck.

Husker,

The way TCP is specified is "If no linear motion RELATIVE to the workpiece" is specified then the rotaries go into degrees per minute. Fanuc said this and I called Seimens to ask them how their TCP works and they said the same thing. So, the rotaries are moving but the tool is in the same spot relative to the workpiece as the rotaries move. I agree with you on all your other points though. And, thanks for responding.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.

Join us!

eMastercam - your online source for all things Mastercam.

Together, we are the strongest Mastercam community on the web with over 56,000 members, and our online store offers a wide selection of training materials for all applications and skill levels.

Follow us

×
×
  • Create New...