Thanks - good to know things straight from the source. So - with specified - machine zero to 4th axis center (pivot 1) and then 4th axis center to 5th axis center (pivot 2) the effect at the end will be limited (and broken up) to a max tolerance? Is this with "New Kinematic Solver" turned off?
Mmm, a little confusion or misunderstanding here...
The machine zero to 4th axis center and the 4th axis center to 5th axis center would define the offsets between the rotary axes and the main MCS. These parameters along with the planes of rotation are used to transform tool path point/vector into XYZAB, either with new or old IKS (Inverse Kinematics Solver). This is independent of the machine's being HH, HT or TT.
The parameter that has the most direct impact to the results of linearization, is the mom_kin_pivot_gauge_offset on a HH machine (post). And yes, in the end, the breakups are limited to the lintol.
Ok - wrong vars. How is mom_kin_pivot_gauge_offset (one value) set in PB and wouldn't two vectors be needed? If I were going to look at the effect of tool point programming back through (say) 2 3d vectors (C leg not Z only) universal head to the ram attach point - I would need two vectors or offsets and two vectors that rotaries spin about. Also - the doc mentions mom_kin_pivot_dist_vec(3) would give me one 3d vector that would work for below as (-210,0,210) to tell (with GL) how much the ram is moving.
The offsets are only relative from machine zero to 4th and from 4th to 5th. These offsets + the axes of rotation are consumed during the IKS computation to figure out the XYZAB already. This is irrespective of the machine type.
Linearization is to smooth out the intermediate points (by minimizing the deviation of any given mid-point to be within lintol) between 2 consecutive moves that have been resulted from the IKS (XYZAB: in machine space). It can only be carried out, if the NC points (in machine space) are different from the tool path points (in part space). For a HH machine, when the NC points are at the tool-tip, which will be identical to the points of the tool path; there's nothing to compare against in order to minimize the deviation. So, for a HH machine, only when the gauge-pivot distance (or flute length) comes into play, then the linearization can be performed.
For other types of machines, the linearization can always be carried out is NOT due to the presence of the offsets (mentioned above).
Parameters required for IKS are not the same as those that affect the linearization. Hope we don't confuse one issue with another.
No idea why I took a tangent there. You have answered my question - that there is one vector along the tool vector considered in linearization. The point of the thread was that Randy felt the need to go to an external post for better linearization needed because of a finish problem. My suspicion is that Icam considers deltas in all axes for a tool point move - and breaks them up if it feels that they challenge the machine response. I am trying to decide what I would do to implement this same feature. When you mentioned that kinematic variables would make linearization happen - either by cam generator doing it or underneath code - I jumped to a conclusion that more than what you mentioned may be considered.
From the experience (and how the math is done), linearization by distributing tool axis vectors would produce better finish for swarffing cuts. When everything is done near the tool tip, it doesn't really matter which method you choose for linearization.
BTW, IKS is done algebraically and linearization is done numerically.
I am assuming that swarfing cuts are linearized to a tolerance. This would be done without regard to how much XYZ move out at the end of a kinematic chain. So for instance:
G1 X1.000 Y2.000 Z3.000 C4.000 A5.000
G1 X2.000 Y3.000 Z4.000 C5.000 A6.000
shows a 1 inch move in each linear axis. This will not be how much the machine XYZ have to move at the ram attach point. With long and offset pivot lengths - the 1 degree change in the rotaries may make the end effect much longer. I bet Icam determins this and while holding the straight line at tool end point in the goto positions - breaks the move into smaller increments - which represent a distance max out at the end of the kinematic chain. So - 1 goto point in cl may cause many G code points. This is done because machine performance is challenged and cannot hold path (is my guess.) I would not think that Icam would spline out motion - merely break straight line moves up into smaller ones.
There are a lot of ways to address machine performance to hold path when there is a lot of whipping around at the machine axes. I have seen breaking up the moves be one of the solutions - even when the same cam segments are followed.
When we first started with NX back at NX1 the only linearization that we knew of, and I worked with GTAC on this, was linearizing the tool tip points on swarfing cuts. So if I needed to swarf cut a planar surface NX would put out just a few points into the CL since the surface was planer. Then with LINTOL turned on PostBuilder would break up that motion to keep the tool tip centerline moving in a straight line between those CL points if you had a pivot or gauge length. If you had a zero gauge length and a zero pivot then it could not add points. But since rotarys were involved the Machine Pivot point would travel in arcs to accomplish the motion. The side of the cutter would leave excess or undercut as the length increased due to these arcs. But if you have a tool length or pivot length then Postbuilder added additional calculations which could kept the upper portion of the cutter in tolerance as well. A number of years ago I did a presentation on this effect at the PLM World Conference detailing this and what NX had done to help us to improve this. It sounds like more enhancements were made later that I was not aware of.
ICAM goes about this a little bit different in that it uses the Kinematics of the machine and provides you with several different methods (side angle tolerance, two point, or just tool tip) to control both the tool tip and the drive point of the machine tool. This allows you to drive both the tool tip and the machine drive point in near straight lines (even though you are driving arcs because of the rotary's) to improve the machined surface accuracy. You could accomplish the same effect by lengthening the gauge length or pivot length or if you are using Sequential Mill you can limit the maximum distance between points. The effect is similar to to what ICAM does but it seems easier to accomplish in ICAM since it is just a command that you can change at any time.
As far as shifting the XYZ centerline points for angle heads you can do that by turning off the mom_kin_clsf_generation flag in the CL File Generator (clsf.tcl). once I did that I was able to manipulate the CL Points as needed. But this had a negative effect on the rest of the program which made this option somewhat unusable without much more work. This command seemed to force most GOTO points to pass thru a procedure that I could not find and therefor I could not make the needed adjustment. As it turned out it took just a small bit of code in ICAM to accomplish what I had wasted a hundred hours on trying to do it in the CL File Generator in TCL.
But realize that everything is possible if you have enough knowledge in NX and Postbuilder.
I am back to square one again and I still need to resolve this. Are you saying I should build a Postbuilder post that outputs in a cl file format? Or do you mean something else? I have a temporary workaround from outside NX but I would like to get the output out of NX in the proper format without having to jump thru the extra hoops, my temporary fix can cause issues on my machines under certain cirsumstances.
What I can do:
1) I can edit the first goto after a First Move and an Initial Move.
What I can not do:
I cannot edit all of the remaining goto's in the toolpath.
The remaining gotos in the tool path seem to be output using a routine other than GOTO_OUTPUT proc and I have been unable to find that proc.