TLAXIS macro motion in App/Ret macro management

Samarinder Singh

TLAXIS macro motion in App/Ret macro management

Hi,

I have been dealing with this for a long time. It poses a few problems.

1. Discretization settings are applied to TLAXIS macro moves for the ballnose endmills. And all the moves are calculated at the center of the ball. Resultant tool-tip position changes since tool is not moving at the tip. This poses a risk for a large ball nose endmill being too close to the part of fixture especially if there is not enough travel limits and you are positioning in the limited space.

Depending on the Discretization settings this macro motion generates lots of extra points. Please see attached g-code snippet from a production program. In g-code file tool is approaching to A-90 C-167 approximately with 128 blocks of code whereas it can be done with a single block if cutter is not ballnose.

Proposed solutions: a) This move can be calculated as if it is not a ballnose cutter. b) An optional switch to keep legacy style just in case if somebody is using it out there.

2. Another problem is to set the vector for this macro motion. Please attached images. This comes really handy for knuckle head machines for example AC-Head machines. The reason for having this enhancement is to control the swing of C-axis head. I have written a special vb macro to get a safe positioning move. But it would be nice if TLAXIS macro motion acts same as inside Point to Point MO.

Regards,
Samarinder
Attachments

  • TLAXIS_macro_ballEndmill1.pptx (123.3k)
  • TLAXIS_Macro1.pptx (163.7k)
  • TLAXIS_macro_ballEndmill1.NC (5.9k)

Dave Frank

RE: TLAXIS macro motion in App/Ret macro management
(in response to Samarinder Singh)

Hi Samarinder

 Nice observation.

 1. Discretization settings are applied to TLAXIS macro moves for the ballnose endmills. And all the moves are calculated at the center of the ball. Resultant tool-tip position changes since tool is not moving at the tip. This poses a risk for a large ball nose endmill being too close to the part of fixture especially if there is not enough travel limits and you are positioning in the limited space.

 I think the request for this came from folks using RTCP, and also setting the gage length at the ball center, not the tool tip. The advantage of doing this, is if you need to jog the machine in TRAORI mode with a ball, the "ball" stayse stationary, as the center of the ball is the RTCP pivot center. Just so you see there is a reason. But YES, control, control control, programmers want control

 Depending on the Discretization settings this macro motion generates lots of extra points. Please see attached g-code snippet from a production program. In g-code file tool is approaching to A-90 C-167 approximately with 128 blocks of code whereas it can be done with a single block if cutter is not ballnose.

 Proposed solutions: a) This move can be calculated as if it is not a ballnose cutter. b) An optional switch to keep legacy style just in case if somebody is using it out there.

 I agree with this.

 2. Another problem is to set the vector for this macro motion. Please attached images. This comes really handy for knuckle head machines for example AC-Head machines. The reason for having this enhancement is to control the swing of C-axis head. I have written a special vb macro to get a safe positioning move. But it would be nice if TLAXIS macro motion acts same as inside Point to Point MO.

Regards,

 I agree with this also. Good JOB

 Dave

Jim Barkelew

RE: TLAXIS macro motion in App/Ret macro management
(in response to Samarinder Singh)

Interesting Samarinder.  I never noticed that before so I had to check it out. My first thought was to un-check the ball nose box in the cutter definition.  That didn't work.  So I changed the end radius by 0.001 and that changed the output.  So the macro system is looking at the tool parameters to decide the output.  I tried changing the radius by 0.0001 and that also changed the output.  V6 may offer better visualization of the tool axis effect on the machine.

I agree with Dave, this is likely for mold and die where ball nose cutters are king.  Would allow rotating the tool while it's in contact with the part.  I never did that.  Also with the 840D and TRAORI basically what you see in CATIA is what you see on the machine as far as the tool path on knuckle/fork head machines.  The tool tip goes from point to point as you see in CATIA.

Samarinder Singh

RE: TLAXIS macro motion in App/Ret macro management
(in response to Jim Barkelew)

Hi Jim,

Thanks for the tip. I changed the radius by .00001in to 0.24999in and it works fine but I cannot use this workaround unless I change all of the ballnose endmills' definitions. I programmed automotive parts and sometimes I used to program with center of ball but that was for only for roughing. Idea was to rough the part with the larger endmill and then use a smaller endmill using the same program to rough it again. But I never mixed RTCP from tip to center of the ballnose endmill. I still don't understand why would someone program such toolaxis motion for cutting or positioning and have the RTCP motion shifting from the tip to the center of the tool in the middle of the program.

I believe it is a bug/limitation because this is not what a part-programmer would want. I have part-program with .500in to 1.00in safety distance for the safety plane. Imagine sending a ballnose of 2.00in diameter to the safety plane and then a rapid positioning move using tool-axis. If tool is close to the part or fixture then it will gouge on a Retract move. In Approach move the tip of the tool may run into travel limits because it works opposite since the rotation is done at the center of the ball.

Regards,
Samarinder
Attachments

  • TLAXIS_macro_ballEndmill1.CATProcess (553.8k)

Bryan Carpio Felsher

RE: TLAXIS macro motion in App/Ret macro management
(in response to Samarinder Singh)


This is good to know.  I'm not really worried about it though.  I never use approach/retract macro's to rotate tool axis anywhere near close to the part.  Also, I believe you would catch this type of collision during verification. 

 

Still, I agree with you.  All rotations should be about the tool tip, regardless of tool type.  We are always programming the tool tip in Catia, so the control should not change in the macro.  In my opinion (as well as yours) this is a bug and should be fixed!

Jim Barkelew

RE: TLAXIS macro motion in App/Ret macro management
(in response to Bryan Carpio Felsher)

It can't be a bug since it's in the documentation.  I found it yesterday under creating a macro but no explination of why.  At this point the fix would have to be a switch with the default like it is.

Samarinder Singh

RE: TLAXIS macro motion in App/Ret macro management
(in response to Jim Barkelew)

Hi Jim,

I am aware of the documentation and I didn't mention it because I wanted others' opinion on it to without knowing the limitation. Documentation doesn't explain much on this. All it says that it is done this way. Well if user runs into real life scenario then this is considered a weakness in the software. Moreover if you look for the consistency of RTCP then it is not doing what it is supposed to do when compared to other tool types.

To me it is a simple fix by adding a small piece of code like this.

If motion-macro type is TLAXIS
    If Not LegacyTLAXISmacro1 'to support old style, an optional check box somewhere in the motion-macros.
    Define a temporary variable for corner radius say tempCornerRad1
        If CutterType is ballnose
           tempCornerRad1 = 0
           ...
           Do the calculations using temCornerRad instead of whatever original variable.
           ...
        endif
    endif
endif

Regards,
Samarinder

Dave Frank

RE: TLAXIS macro motion in App/Ret macro management
(in response to Samarinder Singh)

I think we need both.

I dont think its a bug. I used to pivot around the center of a 2.000 ball, in NCL.

 

I did it using dont cut

 

DNTCUT

GODLTA/COR

TLAXIS/NEWVE

GODLTA/-COR

CUT

 

Davey

Randy Hitzeman

RE: TLAXIS macro motion in App/Ret macro management
(in response to Samarinder Singh)

Acutually,

I've used this function to program a test for 5 axis machine fanning accuracy.

This test involves chucking up a tooling ball and pivoting the machine around the center of the ball.

Dial indicators are placed on the front side and bottom to record how well the machine positions.

It's like a 5 axis ball bar test. I swing it thru the ZX and YZ planes, and then at planes at 45 degrees.

This tests the A axis, then the B axis, and then combinations of both.

This test can expose machine or controller flaws that are often overlooked. 

Randy Hitzeman

Dave Frank

RE: TLAXIS macro motion in App/Ret macro management
(in response to Randy Hitzeman)

yep... been doing that test for decades.

3 indicators. South pole, north and east on the equador

run it slow run it fast for following error

Bryan Carpio Felsher

TLAXIS macro motion in App/Ret macro management
(in response to Randy Hitzeman)
That's a damn good point Randy. I've done that too using the
macro...totally forgot about that. Stick a large ground tooling ball in a
long holder, put indicators on 3 sides and pivot to test.

Samarinder Singh

RE: TLAXIS macro motion in App/Ret macro management
(in response to Bryan Carpio Felsher)

That is ok to check the machine's fanning accuracy with indicators. I built a special program to cut 2.00" sphere and it really worked great. I made it for one of my customers around 5 years ago on OKK KCV1000 5-axis with AB head. This way you'll see how precise your machine will cut under some light cutting load.

It doesn't do any good in everyday programming of some complex parts. Also I did not say that it is bug. I said, "I believe it is a bug/limitation.."

P.S. You don't need Catia or any other CAM system to write a simple ball-bar test motion. At my work Maintenance Engineer has written such routines manually and I have seen him using it with our 5-axis machines.

Regards,
Samarinder

Samarinder Singh

RE: TLAXIS macro motion in App/Ret macro management
(in response to Samarinder Singh)

Hi,

Lately I am involved with a project where lots of such TLAXIS moves are required for some complex machining. I have already requested some APIs from DS which is in Top ten list from 2012. I hope they become available soon. Anyway I put together some info to explain in details why user needs such control to avoid any collision or dangerous move for AC head machine.

I could just simple add PP statement to output the desired move using post-processor. But it defeats the purpose of the collision-checking because it will not cause any movement of the machine tool especially when checking the tool-motion between 2 consecutive MOs.

RAPID
MOVETO/AAXIS,5

EDIT: I forgot to mention that this option is needed for both Approach and Retract. The only difference will be TLAXIS vector used in calculation will be the Last TLAXIS for the retract and the Next TLAXIS for the Approach. So GUI can have option for NEXT and LAST and if not selected then it can be an automatic option where it detects the macro type: if such TLAXIS is used while tool is retracting or approaching.

Regards,
Samarinder
Attachments

  • TLAXIS_Macro2.pptx (251.5k)
Edited By:
Samarinder Singh[CUTPATH] @ Oct 24, 2012 - 12:17 PM (America/Pacific)

Dave Frank

RE: TLAXIS macro motion in App/Ret macro management
(in response to Samarinder Singh)

Samarinder is 100℅ on target here.  How to do colision checking?????

If the DS answer is MS,  I point out that 88℅ of programmers wish they had it, BUT only  12% have any authority to purchace it....

therefore..... this is needed.

Plus... even with MS..  CD does not work the same way...? it would be g code...after the apt generated...and posted

Dave

Samarinder Singh

RE: TLAXIS macro motion in App/Ret macro management
(in response to Dave Frank)

Dave,

Thanks for your input.

And here is a small app that all NC-programmers could find useful to calculate this TLAXIS vector as desired/required so there is no movement in C-axis rotary. It would help to avoid any possible collisions/over-travel or unwanted motion for AC head machines. I wrote it last month and I added lots of other options over this weekend. Attached is a free version of this TLAXIS calculator so some of the options are not there. I didn't write any validations for the input hoping that the user will use correct numeric inputs in the text boxes. Unzip it and change the extension to .exe

Anyway this is a limitation in the software and I hate to say that some folks are not able to realize it. Please don't take it personally. This behavior only happens in multi-axis MOs using ballnose endmill. And I have provided a simple solution to fix it in my earlier post in this topic.

Bottom line is as an NC-programmer I would like to see a consistent output from Catia either on the tool-tip or at the center of the tip and not a mixed output.

Regards,
Samarinder
Attachments

  • TLAXIS_Calculator1_exe.zip (144.7k)
Edited By:
Samarinder Singh[CUTPATH] @ Nov 24, 2013 - 06:07 PM (America/Pacific)

Dave Frank

RE: TLAXIS macro motion in App/Ret macro management
(in response to Samarinder Singh)

Thanks for posting this...... I can't wait to try it.

Dave

Bryan Carpio Felsher

RE: TLAXIS macro motion in App/Ret macro management
(in response to Dave Frank)

I think the moral of the story is that DS should change it so that all tool axis motion is about where ever the COMPENSATION is set.  If set, to tool tip (default) then rotate about tool tip, if set about tool center, then rotate about tool center.  THAT is intuitive to me.

Until then, as I've always done, set your safety planes far enough away from the part where it doesn't matter.  Then, you're not going to hit your part if you rotate about EITHER the tool tip, or the tool center.

Don't post RAPID tool axis motion, so that the machine control will always rotate about the XYZ points in the program (as opposed to rotary center!)

Yes, you will have more XYZABC motion when using a ball EM. As long as your above the safety plane, and your safety plane is larger than the biggest ball radius, this isn't a problem.

I have never programmed a ball EM bigger than 2" diameter.  My safety plane is NEVER less than 1" above the highest point on the part or stock where my tool is going to be safely positioned for the next move.  I never post out RAPID tool axis motion, unless it is done at machine Z home.  Therefore, I have never ran into a problem. 

I get the problem, and I get the idea behind the tool axis calculator.  I'm just not going to take the time to over analyze each tool axis move with a ball EM, when it doesn't have any affect on whether I make a good part, and the customer's not going to even notice that the ball em's aren't rotating about tool tip.

I might just go and change every single ball endmill in my tool catalogue so that the radius is .00001 smaller.  Not like that would affect the program....and if it gets rid of the funky tool axis BS, I'm happy.

Samarinder Singh

RE: TLAXIS macro motion in App/Ret macro management
(in response to Dave Frank)



In Reply to Dave Frank:

Thanks for posting this...... I can't wait to try it.

Dave


Hi Dave,

Thanks for your comment. I gave it(full version) to my programmers at work and they really love it for checking the limits of the machine. Oh.. and I forgot to mention that it works with .NET framework 4.0 because I had to recompile it for one of my colleagues. Unlike Catia's "check reach-ability" it tells you exactly if the given cl point is in limits or not. If not then it shows the over-travel amount of each axis in fault. Also I discussed it briefly with our friend at R&D this morning.

Regards,
Samarinder