Continue to Site

Welcome to MCAD Central

Join our MCAD Central community forums, the largest resource for MCAD (Mechanical Computer-Aided Design) professionals, including files, forums, jobs, articles, calendar, and more.

Circular interpolation B Axis in 4 axis

MAXKUM

New member
Hi all,


I am creating one trajectory sequence and making the cutter go around a cylinder. But while post processing I am getting output in fractions like below


X.7801 Z9.6957 B1.685
X.7706 Z9.6963 B3.371
X.7595 Z9.697 B5.071
X.7478 Z9.6977 B6.777
X.7341 Z9.6985 B8.494
X.722 Z9.6992 B10.206



I want to get one B value like B210 etc like that. Looks like it is giving me output different z values. Its just a cylinder. The Z should not be changing and programe should be very small.





Please suggest.


Thanks


Mahesh
 
Hi Mahesh,


First, you will not get a single B move when in 4-axis mode, unless you wrote some special FIL code to trap this condition and output just the last B move. But, you should be able to get rid of the X's and Z's if you are on a true cylinder.


The rest is a bit difficult to figure out just like this, but I will check the following though:


1- Make sure config option MFG_IJK_NUM_DIGITS is the default value (10). This should never be changed.


2- Tighten the TOLERANCE value in your sequence. This will make a big difference in this case.


3- Make sure your AXIS_DEF_CONTROL option is from geometry that will keep the tool axis going through the center at all time.


4- If all fails, you need to explicitely tell pro/E that you want the tool axis to go through center at all times. Trajectory does not have this, but you can accomplish the same thing using cutline machining. Just use the same edge/curve for both start and end cutline definiton, and then under axis control, select the center axis as 'pivot axis". This should do it.


Good luck,


Charles
 
Charles,


Mahesh sent me the cl file. The motion is 6 parameter GOTO's with continously changing tool axis vector. That is why all the "B" axis moves. Unless ProE puts out a better clfile, nothing will change.


Don
 
Charles,


Here is the beginning of the cl file. Note the I-J-K value constantly changing.


$$* Pro/CLfile Version 2001 - 2002310


$$-> MFGNO / 0180267


PARTNO / 0180267


$$-> FEATNO / 1801


MACHIN / UNCX01, 6


$$-> CUTCOM_GEOMETRY_TYPE / OUTPUT_ON_CENTER


UNITS / INCHES


PPRINT / DATE TIME : 14-MAR-07 15:52:59


PPRINT / CUTTER_DIAM : 0.375000


LOADTL / 2, OSETNO, 2


$$-> CUTTER / 0.375000


SET / OFSETL, 54


$$-> TRANS / 0.0000, -2.0000, 0.0000


$$-> CSYS / 1.0000000000, 0.0000000000, 0.0000000000, 0.0000000000, $


0.0000000000, 1.0000000000, 0.0000000000, 0.0000000000, $


0.0000000000, 0.0000000000, 1.0000000000, 0.0000000000


MULTAX / ON


SPINDL / RPM, 2000.000000, CLW


COOLNT / ON


RAPID


GOTO / 0.7875, -0.1720, 12.0000, $


0.0000, 0.0000, 1.0000


RAPID


GOTO / 0.7875, -0.1720, 9.7552, $


0.0000, 0.0000, 1.0000


FEDRAT / 1.000000, IPM


GOTO / 0.7875, -0.1720, 9.6952, $


0.0000, 0.0000, 1.0000


FEDRAT / 20.000000, IPM


GOTO / 0.7875, -0.1919, 9.6952, $


0.0000, 0.0000, 1.0000


GOTO / 0.7875, -1.0027, 9.6952, $


0.0000, 0.0000, 1.0000


GOTO / 1.0648, -1.0027, 9.6686, $


0.0294, 0.0000, 0.9996


GOTO / 1.3394, -1.0027, 9.6342, $


0.0588, 0.0000, 0.9983


GOTO / 1.6137, -1.0027, 9.5919, $


0.0884, 0.0000, 0.9961


GOTO / 1.8869, -1.0027, 9.5417, $


0.1180, 0.0000, 0.9930


GOTO / 2.1586, -1.0027, 9.4837, $


0.1477, 0.0000, 0.9890


GOTO / 2.4292, -1.0027, 9.4178, $


0.1772, 0.0000, 0.9842


GOTO / 2.6973, -1.0027, 9.3444, $


0.2062, 0.0000, 0.9785





I am surprised there are only 4 decimal places.


Need more data/contact: [email protected]


Donald W. Rhea


Woodruff, South Carolina, USA
 
Charles,


Here is a piece of someone elses cl file. Note number of decimal places.


MULTAX / ON
SPINDL / RPM, 2000.000000, CLW
RAPID
GOTO / -2.0806193173, 1.6217425443, 8.4253000000, $
0.0868587145, -0.0824889098, 0.9927996492
RAPID
GOTO / -2.0806193173, 1.6217425443, 7.4434887603, $
0.0868587145, -0.0824889098, 0.9927996492
FEDRAT / 20.000000, IPM
GOTO / -2.1240486745, 1.6629869992, 6.9470889357, $
0.0868587145, -0.0824889098, 0.9927996492


Not that it matters but this clfile is a piece of crap! The "movie" of the tool path looks great, but the clfile does not reflect the "movie tool path". Does not make the part.


Don
 
Hi Don and Mahesh,


That explains the issue. It is due to MFG_IJK_NUM_DIGITS set to 4. So it confirms my most likely scenario. It is not the first time I see this. I have seen it in a lot of places.


There seen to have been some very bad advice floating around for many years, or someone who made a Pro/E setup template and passed around. I have seen this config setup at companies that tell me they had not touched it for the last 10 years. Horrible!


Bottom line, this config setting should never be touched. You want as much decimals as possible on your vector.


This does not mean that the other 3 potential problem areas are precluded. But, this is the most obvious issue to resolve (and the easiest).


Charles
 
Don,


I do not understand your point about "Here is a piece of someone elses cl file. Note number of decimal places."


I do not see anything wrong with this CL file (from a form point of view). It is rapid move to a position with bothrotaries set out of zero, and then a small plunge feed move down.


Itmight not be cutting what he wants to cut, but that would be his own doing. Though, it is a perfectly good CL per ISO.


Charles
 
Charles,


The format of the cl file is OK, just the data is bad. Like I said the "movie" of the tool path looks great, the cl file does not look like the tool path "movie".


If you send me an e-mail I will send you the "movie", the cl file and a picture of what it made. 2 different people have tried this and the cl file DATA is bad.


Don


[email protected]
 
Hi Don and Charles

Thanks for your replies. Here are the some of the points I would like to add

1. I am using Pro/E 2001.
2. If I tighten the tolerance value it will give me more smaller radiuses instead of one big radius. Axis definition control does not work very good in curve trajectories.

When I use curve trajectories I found my tool axis is not going thru pivot axis and there is not parameter to specify that unless I make a lot of axeses all around the cylinder but that a LONG tiring exercise.

I finally used surface machining with cutlines. In this also I was getting same result with Z and X movements but the movements were only within .0008" which I could live with.

And voila I just tried Charles method of setting the IJK digits to 10 while I was writing this IT WORKED but only in surface machining not on trajectories. I am not getting as many Z and X values but B values are in fractions. Here is the result.

G00 G40 G49 G80 G90 Z0
( / DATE TIME : 18-MAR-07 09:41:14)
( / CUTTER_DIAM : 0.375000)
T02 M06
S2000 M03
G00 G54 X-.1829 Y.058 B4.65
G43 Z12.0247 H02 M08
X0.
Z9.775
G01 Z9.715 F1.
Y-1.0027 F20.
B6.163
B7.677
B9.191
B10.705
B12.219
B13.733
Z9.7149 B15.247
Z9.715 B16.761
B18.275
B19.789
B21.303
B22.816
Z9.7151 B24.33
Z9.715 B25.844
B27.358
B28.872
B30.386
B31.9
B33.414
B34.928
X-.0001 B36.442
X0. B37.956
B39.469
B40.983

Looks great to me. I will set my IJK values to 10 now on. Tightening the tolerance gives more B values. It still does not make sense to give so many B value instead of one big one.

Anyways thanks for brain storming on this. I really appreciate that. One more question. How can I put B Axis lock and unlock in the program. I am programming it for FANUC 16M. It takes M11 and M10 for locking and unlocking. Does anybody has Post file for FANUC 16M.

Thanks Again,
Mahesh
 
Don and Charles,

Any idea how can get rid of so many B values one after another. It does not make sense. I can have just one B value.

Please help.

Mahesh
 
Hi Mahesh,


I am not sure I explained myself well the last time. Basically, you have 2 seperate problems:


Problem 1- Your vectors in your toolpath do not all go through the center. Thiscomes from 2 potential areas:

  1. <LI>you choping the vector. MFG_IJK_NUM_DIGITS set back to default fixes this.</LI>
    <LI>a matter of toolpath compute discretization. This is more difficult to solve.
    I recommended lowering the tolerance to get better discretozation, but this is not a sure bet solution, and also will make more point.
    My second recommendation is going with cutline machining, which you seem to do. But from your output, it does not seem that you used AXIS_DEF_CONTROL to force vector through the center axis. So, it is the same as what trajectory does (unless you use AXIS_DEF_CONTROL ).</LI>


Problems 2 - You get many B moves instead of justa singleB move. This will always happen because in MULTAX, there is no circular records that translate to a B move. They are multiple small moves that end up only moving B on your machine.


I do not think there is any setting you can do in GPost to strip these extra B output moves automatically. You can write a FIL to strip the excess B moves, but it will not be easy. You basically have to trap all feed B-only moves, hold them until you determine whetehr the next output is a another B-only move in the same feed.


I would send you the FIL if I have it, but I do not have it in GPost. I did similar programs in the past with NCPOST (the post system with Pro/NC prior to GPost), and the logic is the same, but I never needed it since using GPost.


Charles
 

Sponsor

Back
Top