Sign in to follow this  
PAnderson

Problem with TCP when rotaries are singly specified

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

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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?

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

what's it do without the G5.1?

Share this post


Link to post
Share on other sites
2 hours ago, PAnderson said:

Just an update. Still not solved.

What do you have in 19696 #6?

Share this post


Link to post
Share on other sites
3 hours ago, mkd said:

what's it do without the G5.1?

The same thing except the other moves are quite jerky, which is to be expected.

 

Paul

Share this post


Link to post
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

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

Just a thought!

 

Those parameter say Max allowable feed rate. if it is set to 0.0, does't that mean no feed?

you should try changing that parameter to set a max feed rate. 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • 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