n_tpln_mch - what is its possible values?

[Giang-TT]

Hello,

I'm working on the generic 5X post to add the tilted work plane (G68.2) function to the post. But there is a hidden variable - "n_tpln_mch" which I really want to study clearly about. 

I guess it relates to the "top_map" and some other stuffs in the binary file. During the tests, its value makes me confused.  I want to ask about all of its possible values and the meaning of each value. Wondering if anyone can help me out, or this section should be kept secret.

In my post, the "top_map" is set to 1, when I have a true 5-axis toolpath (mill5$ <>0), the "top_map" is set back to 0.

During the tests, I realized the "n_tpln_mch" has different values depend on how I posted the toolpath.

The case is: I have a true 5-axis toolpath (5-axis helixbore) following by an indexing toolpath (Area roughing). Using the post debugger, I checked the value of the "n_tpln_mch" variable when it passed through the indexing toolpath:

- When the indexing toolpath was posted alone, the n_tpln_mch = 5, I got the G68.2 worked correctly

- When I posted both toolpaths together, the n_tpln_mch = -1 when it passed through the the indexing toolpath, the G68.2 then skipped.

I think I will add another condition for this case but it will be the best if I know what "n_tpln_mch" exactly is. 

Thank you.

[Greg Williams]

Giang,

This can be done, For the G68.2 block I would use 2 angles not 3. If you want to use 3 angles you will need to create the Euler maths in a post block. If you create the maths use the new recalculated X axis vector from inside the post. If you use the toolplane to calculate the 3 angles the X axis may come out incorrect depending on how the tool plane has been created.

Also you will need to write a block to handle the transition from 3+2 world to 5 with TCP on and 5 with TCP on back to 3+2 world with the same tool, currently there is no solution for that in the generic 5 axis post for this senario.

Top Map will only output 1 or 2 off G68 blocks which will rotate the Gcode but on most machines I have seen the G68 will not datum track the rotations. For this we need G68.2

I have not used n_tpln_mch for any calcs but further down the string is mentioned and commented

n_tpln_mch  : -2    #Nutating machine selection when toolplane output 

I dont know who originally wrote the Generic 5 axis post but full respect to them as it is quite a document.

[Colin Gilchrist]

'top_map' is only the first variable used, to designate that we want to "map toolplane coordinates" to the WCS.

The "mechanism" in the Post was first added to support G7 Rotation for 5-Axis Heidenhain controls.

'top_map' is just a "yes/no" (0 or 1) on/off variable. There is a helper variable called 'top_type' which has 5 possible values: 1-4 select different "automatic rotations" (in the locked portion of the Post), for Heidenhain G7 rotation. You don't want 1-4, you want '5' for Top Type. This lets you use two existing Post Blocks, ptop_type_ax and ptop_type_lim, to be able to calculate your rotation values, and set/check limits.

How to enable G68 in Mastercam generic 5-axis post? 

 

1. Set variable ‘top_map’ to be 1; 

2. Modify the rotary axis settings in post block ‘p_nut_restore’ so that they match with the initial rotary settings right above this post block. 

3. Modify the value for variable ‘n_saxisx’, ‘n_saxisy’ and ‘n_saxisz’ if necessary. 5X uses ‘n_saxisx’ variables. Toolplane based toolpaths use ‘saxisx’ variables. 

4. Modify the value for variable ‘top_type’. 

5. If the value of ‘top_type’ is set to be 5, modify the rotary axis settings in post block ‘ptop_type_ax’ and ‘ptop_type_lim’ accordingly. In ‘ptop_type_ax’, also check the axis label, make sure they are set correctly. 

6. Modify the mapping logic in post block ‘pg68_map’ and ‘pg68’. Basically the axis to be rotated around may be modified. In ‘pg68_map’, check ‘axisx$’ and make sure it is set to be the right vector to rotate about. In ‘pg68’, check ‘ivec ‘ and make sure it is set to be the right axis vector to rotate about. Also check variable ‘map_r’ is set to be the correct angle. The sign of this angle may need to be changed depending on rotary axis type. For example, ‘map_r’ should be set to ‘p_out’ and ‘s_out’ for head/head machine.  

7. The G code for G68/G69 may be modified if necessary. 

8. Add code to turn on spindle for G68 mode in ‘p_goto_strt_tl’ and ‘p_goto_strt_ntl’. This is to fix a bug in our 5x post. 

9. Add code to turn on G90 mode in ‘p_goto_strt_tl’. This is to fix a bug in our 5x post. The post block ‘p_goto_strt_tl’ and ‘p_goto_strt_ntl’ should looks similar to code below. 

p_goto_strt_tl  #Make the tool start up at toolchange 

…… 
     …… 
      if n_tpln_mch > m_one, #Toolplane mapping mode 
        [ 
        #Enter your mapping scheme here... 
        pg68_map 
        #spindle on 
        pbld, n$, *speed, *spindle, pgear, e$ 
        pbld, n$, "G43", *tlngno$, *zabs_s, e$ 
        pbld, n$, *sg00, pwcs, *sgabsinc, "X0.", "Y0.", *zabs_s, e$ 
        pcan1, pbld, n$, *sgcode, *xabs_s, *yabs_s, *p_out, *s_out, strcantext, e$ 
        ] 

…… 
     …… 
      
 

p_goto_strt_ntl #Make the tool start up at null toolchange 
     …… 
     …… 
      ##### Custom changes allowed below ##### 
 
        if n_tpln_mch > m_one, #Toolplane mapping mode 
          [ 
          #Enter your mapping scheme here... 
          pg68_map 
          #spindle on 
          pbld, n$, speed, spindle, pgear, e$ 
          pbld, n$, pwcs, sgabsinc, *xabs_s, *yabs_s, *zabs_s, *p_out, *s_out, e$ 
          pg68 
          pbld, n$, *xout, *yout, *zout, e$ 
          ] 
     …… 
     …… 
 

 

10. Add code to update work offset at the end of ‘p_goto_strt_tl’ and ‘p_goto_strt_ntl’. 

      !workofs$ 
 

 

11. The G68 rotation center will always be WCS origin in our current post. This may need to be fixed if customer wants the rotation center to be the tool plane origin. Be aware of misc integer #6, that would affect the output. The fix needs to be related to the settings of ‘mi6$’. 

 

pg68_map        #Map the first postion to the machine 
      if p_out | s_out, 
        [ 
        #Rotate xabs back  
        xabs_s = vequ(xabs) 
        axisx$ = vequ(caxisx) 
        xabs_s = rotv(-p_vec_rot, xabs_s) 
        axisx$ = vequ(baxisx) 
        axisx$ = rotv(p_vec_rot, axisx$) 
        xabs_s = rotv(-s_vec_rot, xabs_s) 
        if add_wrk_sht = 0, map_x = vequ(tox$)  #work shift is not turned on, rotate around tool plane origin 
        else,  
          [ 
          map_x = 0, map_y = 0, map_z = 0 #work shift is turned on, rotate around WCS origin 
          ] 
        ] 
 
 

12. Add the highlihghted logic below in post block ‘pg69’ as below.  

 

pg69            #Cancel mapping mode 
      if top_map & prv_map_mode = one, 

 

[Colin Gilchrist]

That document talks about adding only "G68 single axis rotation".

To add G68.2 support, you basically need to set 'top_type' to '5'. This tells MP not to use any of the automatic rotations, and lets you add code to 'pg68' and 'pg68_map', to support the Tilted Work Plane output.

Some sample code (without variable definitions, just look at the structure first, to see if you can figure out what is going on).

 

# --------------------------------------------------------------------------
# Mapping mode -
# Rotations are always about the zero point
# Only toolplane toolpaths by entire toolpath section use mapping mode
# Modify according to specific post setup
# --------------------------------------------------------------------------
pg69            #Cancel mapping mode
      if top_map,
        [
        #Add your code to cancel mapping mode...
        pbld, n$, smap_mode, e$
        ]

pg68_map        #Map the first postion to the machine
      if p_out | s_out,
        [
        if map_mode = 0,
	  [
	  tmpmtx_xx = mteq(m1$)   #Copy toolplane into temp matrix
	  #####
	  # Find alpha angle
          ieul = -atan2(tmpmtx_zy, tmpmtx_zx)-90
	  #####
	  # Rotate tmpmtx_xx matrix about wcs z by alpha angle - this should make zx equal zero
	  axisx$ = vequ(caxisx)
	  tmpmtx_xx = rotv(ieul , tmpmtx_xx)
	  tmpmtx_yx = rotv(ieul , tmpmtx_yx)
	  tmpmtx_zx = rotv(ieul , tmpmtx_zx)	  
	  #####
	  #  Find beta Angle between Tool Z Vector and WCS Z about X
	  axisx$ = vequ(aaxisx)
	  jeul = -atan2(-tmpmtx_zy, tmpmtx_zz)  #pay attention to quadrants this is rotated 90 degrees, think of wcs z as an x axis and the vector needs to be measured counter clockwise from there
	  #####
	  # Rotate tmpmtx_xx matrix about wcs x by beta angle
	  axisx$ = vequ(aaxisx)
	  tmpmtx_xx = rotv(jeul , tmpmtx_xx)
	  tmpmtx_yx = rotv(jeul , tmpmtx_yx)
	  tmpmtx_zx = rotv(jeul , tmpmtx_zx)
	  #####
	  #  Find gamma Angle between rotated Tool Plane X Vector and WCS x about z - tmpmtx_zx should be 0,0,1
	  axisx$ = vequ(caxisx)
	  keul = -atan2(tmpmtx_xy, tmpmtx_xx)
	  #####
	  #  Rotate tool plane matrix - xx,yy,zz  should all be equal to 1 
	  axisx$ = vequ(caxisx)
	  tmpmtx_xx = rotv(keul , tmpmtx_xx)
	  tmpmtx_yx = rotv(keul , tmpmtx_yx)
	  tmpmtx_zx = rotv(keul , tmpmtx_zx)
	  ]
	if map_mode = 3,
	  [
          #Rotate xabs back
          xabs_s = vequ(xabs)
          rt_tox = vequ(tox$)
          axisx$ = vequ(caxisx)
          xabs_s = rotv(-p_vec_rot, xabs_s)
          rt_tox = rotv(-p_vec_rot, rt_tox)
          temp1_nx = vequ(aaxisx)
          temp1_nx = rotv(-p_vec_rot, temp1_nx)
          axisx$ = vequ(temp1_nx)
          xabs_s = rotv(-s_vec_rot, xabs_s)
          rt_tox = rotv(-s_vec_rot, rt_tox)
          if add_wrk_sht = 0, map_x = vequ(rt_tox)
          else,
            [
            map_x = 0, map_y = 0, map_z = 0 #work shift is turned on, rotate around WCS origin
            ]
          ]
	 ]

pg68            #Enable mapping mode
      map_mode = one
        if p_out | s_out,
          [
            if map_mode = 3,  #G68.2 P3 Q1,2 - two vector method
	      [
              ivec = vequ(m1$)
              pbld, n$, *smap_mode, "P3 Q1", *map_x, *map_y, *map_z, *ivec, *jvec, *kvec, e$
              ivec = vequ(m7$)
              pbld, n$, *smap_mode, "P3 Q2", *ivec, *jvec, *kvec, e$
              pbld, n$, "G53.1", e$
	     ]
	  if map_mode = 0, # #G68.2 - euler angles
	    [
	    pbld, n$, *smap_mode, *map_x, *map_y, *map_z, *ieul, *jeul, *keul, e$
	    ]
          ]

 if p_out | s_out, prv_map_mode = one

##########################    
# Original mapping output
#         
#      #Primary mapping output
#      ivec = vequ(caxisx)
#     if p_out,
#        [
#        map_r = -p_out
#        pbld, n$, smap_mode, *map_x, *map_y, *map_z, *ivec, *jvec, *kvec, *map_r, e$
#        prv_map_mode = zero
#        ]
#      #Secondary mapping output
#      ivec = vequ(baxisx)
#      if s_out,
#        [
#        map_r = s_out
#        pbld, n$, smap_mode, *map_x, *map_y, *map_z, *ivec, *jvec, *kvec, *map_r, e$
#        ]
#       #if p_out | s_out, prv_map_mode = one
##########################

[riverhunter]

Tagging this post.  I watched Colins's entire youtube course on this and ended up with a pretty nice post.  We have CAMplete so this was just for fun, but I'm really interested in eventually adding G68.2 to the generic 5x post just to have for simple projects and ensure the setup guys are seeing the same code on the floor.   So, Thanks again Colin!

[Giang-TT]

I don't have much knowledge and experience with the vector functions of the MP language, so I tried to minimize the modifying work as much as possible to make the G68.2 work. 

This post is created for a rotary table type machine. In my G68.2  it only has one option formatting - using Euler Angles IJK.

In my post I created a new post block p_twp for calculating the value of X,Y,Z origin and I,J,K angle - based on the data read from NCI (1013 and 1014)

 

After doing many tests it looks working correctly. But as mentioned before, there is one variable, the "n_tpln_mch"  , it appears in some existing post block and makes me confused, it also changes the result of the output code. So if I know what exactly it is, I can still sticking with it, if not, I will try a different way.

Thanks again Colin, I also learned a lot from your post course videos.

[Colin Gilchrist]

49 minutes ago, Giang-TT said:

I don't have much knowledge and experience with the vector functions of the MP language, so I tried to minimize the modifying work as much as possible to make the G68.2 work. 

This post is created for a rotary table type machine. In my G68.2  it only has one option formatting - using Euler Angles IJK.

In my post I created a new post block p_twp for calculating the value of X,Y,Z origin and I,J,K angle - based on the data read from NCI (1013 and 1014)

 

After doing many tests it looks working correctly. But as mentioned before, there is one variable, the "n_tpln_mch"  , it appears in some existing post block and makes me confused, it also changes the result of the output code. So if I know what exactly it is, I can still sticking with it, if not, I will try a different way.

Thanks again Colin, I also learned a lot from your post course videos.

The important thing to understand is that some functions were created inside the 5-Axis Post "early in the development" of the Post, and that architecture can be used to support other things. This is the case with 'n_tpln_mch'.

It was originally used to support Nutating Heads/Tables for the G7 function, and using only "mechanical kinematics" to calculate the correct output for a Tool Plane, giving us XYZ P/S (Primary/Secondary) output.

n_tpln_mch gets initialized to '-2'. A setting of '-2' indicates "5-Axis". A setting of "-1" indicates "a path that is not Toolplane Based (3+2 output)". For example Axis Substitution where the input is a Tool Plane, but the math tells the Post to "wrap the rotary axis".

n_tpln_mch gets set to 'top_type' if 'top_map' is active. Otherwise, the post does some other calculations for 'n_tpln_mch', and eventually sets it to 0-4, indicating the type of internal processing (mapping) to achieve the desired output for angles and coordinates.

When 'top_type' is set to '5', then 'n_tpln_mch' also gets set to '5', and then it just overrides all the automatic Nutating internal logic calls, and just calls the "Custom settings, ptop_type_ax and ptop_type_lim" instead.

When G68.2 is implemented using the default architecture For a non-Nutating machine, 'top_map' should be '1', and 'top_type' should be '5', and the only values n_tpln_mch should have are -2 for 5-Axis, and '5' for Plane Mapping (Tilted Work Plane) output.

It is only when 'top_map' is off or 'top_type' is not set to '5', when you'll get the value of 'n_tpln_mch' set in the range between -1 and 4. 

In a properly configured Post, using the default architecture, you should only see -2 or 5, or maybe -1 under certain circumstances. 

Just for clarity, the only valid values I believe the post should return for n_tpln_mch are: -2, -1, 0, 1, 2, 3, 4, or 5.

[Greg Williams]

Giang,

If you use m1$ to m9$ the plane will need to have the correct orientation, if the plane is not correct to the final machine orientation then the code will be different to what the G68.2 block is outputting. Post ops 8 and 9 of the attached file, you will see if your calculation is correct, both ops should give the same G68.2 IJK angles.

G68.2 X0. Y0. Z0. I180. J-23. K0.

If your machine is XYZAC you already have the 2 correct angles, if you have XYZBC or XYZAB then you will need to run the calculation or create a matrix and rotate the 2 angles you have back to AC orientation.

Euler Angles.mcam

[riverhunter]

opps

 

 

[Giang-TT]

On 2/24/2024 at 1:08 AM, Greg Williams said:

Giang,

If you use m1$ to m9$ the plane will need to have the correct orientation, if the plane is not correct to the final machine orientation then the code will be different to what the G68.2 block is outputting.

 

Hi Greg, sorry for my english, but what do you mean when you say "the plane will need to have the correct orientation"? In my post, I'm still using the s_out and p_out variable to get the rotary angles for the table to index (before calling the G68.2)

N120G54G0G90C180.A-23. (those angles are taken from s_pot and p_out)
N122G68.2X40.Y24.1802Z45.4073I0.J23.K45. (The I, J, K values are calculate from mi1 -> mi9)

 

Quote

Post ops 8 and 9 of the attached file, you will see if your calculation is correct, both ops should give the same G68.2 IJK angles.

I don't think I,J,K have the same value when those 2 planes are not the same orientation for X and Y, are you sure?

I tried posting your file, this is what I got from my post (it is modified for a table table AC machine). The output A and C are the same for both planes. 

G68.2 X40.Y24.1802Z45.4073 I0.J23.K45. for Hole-1 Plane (C180 A-23)

G68.2 X40.Y24.1802Z45.4073 I0.J23.K245. for Hole-1 Rotated Plane (C180 A-23)

 

(------End Tool Measurement ------)
(---Tilted Work Plane---)
N118M11 M13
N120G54G0G90C180.A-23.
N122G68.2X40.Y24.1802Z45.4073I0.J23.K45.
N124G53.1
N126M10 M12
(---Tilted Work Plane---)
N128G0G90X0.Y0.
N130X0.Y0.
N132G43H16Z50.
N134G81G98Z-10.R5.F250.
N136G80
ptoolend$
ptlchg0$
(HOLE 1)
p_goto_strt_ntl
N138G91 G28 Z0.
(---Tilted Work Plane---)
N140M11 M13
N142G54G0G90C180.A-23.
N144G68.2X40.Y24.1802Z45.4073I0.J23.K245.
N146G53.1
N148M10 M12
(---Tilted Work Plane---)

 

 

Quote

if you have XYZBC or XYZAB then you will need to run the calculation or create a matrix and rotate the 2 angles you have back to AC orientation.

Can I ask what is the purpose of this "back rotation" while I'm just using s_out and p_out to get the angle value and using toolpath NCI (m1-m9) to calculate the IJK? 

 

Thank you a lot for all off your comments.

[Greg Williams]

Hi Giang,

If you use s_out and p_out to calculate G68.2 you will always get the correct result. if you use the plane you will not always get the correct result. If you use mi10 to flip the solution you will not get the correct result unless you flip the plane as well.

Post ops 10 and 11, they should give you exactly the same gcode.

T19 M6
G0 G54 G90 A-23. C180.
G68.2 X0. Y0. Z0. I180. J-23. K0.
G53.1
M38
M10
X0. Y-51.7542 S1800 M3

Op 12 is the same but the solution has been flipped with mi10, so hence the Y axis values are now inverted.

G0 G54 G90 A23. C0.
G68.2 X0. Y0. Z0. I0. J23. K0.
G53.1
M38
M10
X0. Y51.7542 S1800 M3

Euler Angles.mcam

[Giang-TT]

On 2/21/2024 at 11:28 PM, Colin Gilchrist said:

The important thing to understand is that some functions were created inside the 5-Axis Post "early in the development" of the Post, and that architecture can be used to support other things. This is the case with 'n_tpln_mch'.

It was originally used to support Nutating Heads/Tables for the G7 function, and using only "mechanical kinematics" to calculate the correct output for a Tool Plane, giving us XYZ P/S (Primary/Secondary) output.

n_tpln_mch gets initialized to '-2'. A setting of '-2' indicates "5-Axis". A setting of "-1" indicates "a path that is not Toolplane Based (3+2 output)". For example Axis Substitution where the input is a Tool Plane, but the math tells the Post to "wrap the rotary axis".

n_tpln_mch gets set to 'top_type' if 'top_map' is active. Otherwise, the post does some other calculations for 'n_tpln_mch', and eventually sets it to 0-4, indicating the type of internal processing (mapping) to achieve the desired output for angles and coordinates.

When 'top_type' is set to '5', then 'n_tpln_mch' also gets set to '5', and then it just overrides all the automatic Nutating internal logic calls, and just calls the "Custom settings, ptop_type_ax and ptop_type_lim" instead.

When G68.2 is implemented using the default architecture For a non-Nutating machine, 'top_map' should be '1', and 'top_type' should be '5', and the only values n_tpln_mch should have are -2 for 5-Axis, and '5' for Plane Mapping (Tilted Work Plane) output.

It is only when 'top_map' is off or 'top_type' is not set to '5', when you'll get the value of 'n_tpln_mch' set in the range between -1 and 4. 

In a properly configured Post, using the default architecture, you should only see -2 or 5, or maybe -1 under certain circumstances. 

Just for clarity, the only valid values I believe the post should return for n_tpln_mch are: -2, -1, 0, 1, 2, 3, 4, or 5.

I tried posting some 5axis toolpaths ( swaft machining/5axis helix bore/5 axis drilling)  the n_tpln_mch was initialized to '-2', then it got the value -1. So, looks like "-1" is for multiaxis toolpaths.

But when I post a multiaxis toolpath with another toolplane-based (3+2) toolpath, the n_tpln_mch can not get back to 5 when it passed through the (3+2)  toolpath. Do you have any idea on it Colin?

[Greg Williams]

YOu will need to add the code to transition from 3+2 to 5 axis and back again. You can cycle it back through

p_goto_strt_ntl 

or create a new block

[Giang-TT]

It took me some time to catch what you are mentioned about.

I think I found one different thing between my G68.2 approach and yours, that is: 

- With my simple approach, I used the toolplane vectors to get the i,J,K value directly. With this method, my tilted plane's X&Y may not align with the machine X,Y axis after applying the G68.2 (e.g. X100. command will cause both X and Y axis to move)

- With your method, the tool plane's X&Y axis will be rotated to align with the machine XY axis after applying G68.2 . Am I correct?

I don't know what is the actual purpose of it, is it just for a better visualization?

Thanks again for your comment, I hope you guys can still understand what I say with my English.

---------------------------------------

Update for the function. Now I'm able to control the n_tpln_mch value using the mill5$ variable. 

      if mill5$ <> 0, 
	   [
	   top_map = 0
	   ]
      else, 
	   [
	   top_map = 1
	   n_tpln_mch = top_type
       !n_tpln_mch
       ]

 

[Greg Williams]

- With my simple approach, I used the toolplane vectors to get the i,J,K value directly. With this method, my tilted plane's X&Y may not align with the machine X,Y axis after applying the G68.2 (e.g. X100. command will cause both X and Y axis to move)

-------------------------------------------------------------------------------------------------------------

Yes this is the problem with using the plane, we need to use the operations X axis

 

- With your method, the tool plane's X&Y axis will be rotated to align with the machine XY axis after applying G68.2 . Am I correct?

-----------------------------------------------------------------------------------------------------------------

Yes correct

 

Your code is correct to calculate the Euler angle from the plane, but using the plane is not the answer.

[Giang-TT]

Quote

Your code is correct to calculate the Euler angle from the plane, but using the plane is not the answer.

 

again with the question: I don't know what is the actual purpose of it - aligning the plane X&Y with machine X&Y , is it just for a better visualization?

I haven't tried it on the real machine but it looks workable on the simulation software, on a table-table AC.

 

 

[Greg Williams]

If the G68.2 block spins the C axis table to a different place to what the Gcode is expecting the program will not cut the part correctly. Try my sample part of a machine and you will see the problem.

[Colin Gilchrist]

On 3/25/2024 at 3:02 AM, Giang-TT said:

again with the question: I don't know what is the actual purpose of it - aligning the plane X&Y with machine X&Y , is it just for a better visualization?

I haven't tried it on the real machine but it looks workable on the simulation software, on a table-table AC.

 

 

The purpose is multi-faceted. You are calculating the output angles, but you are not taking advantage of the architecture of the Post.

The purpose is to give control over the Post and Code Output to the programmer.

One of the things you may not yet know > the Post uses Miscellaneous Integers and Real Numbers > for every Mastercam Operation.

This allows us as Programmers to pass data to the Post, to control the output.

For example, on a Tilt-Trunnion Post, sometimes the calculations make the part "rotate away" from the Operator. The code will work, but you can't easily see and watch.

Wouldn't it be nice if you could use a switch to control the Tilt Axis? Well, you can. The Generic Fanuc 5X Mill Post uses Misc. Integer #10 to control this tilt. (1 or 2 flips between Positive and Negative)

The Post, in the encrypted section, keeps track of things like this.

So, even though you may get G68.2 output that will rotate to the correct orientation on your machine, your XY code may be "skewed" and not match your Tilted Work Plane orientation, because you haven't matched the rotary and linear mapping calculations.

[diabedon]

Tagging this post.  I watched Colins's entire youtube course on this and ended up with a pretty nice post.  

[Colin Gilchrist]

Did you watch both the MP 101 and MP 301 (5-Axis) Post Class? Technically, there are two courses up. I uploaded part of my 4X Lathe Post Class. I really should go and find the old Lathe videos and upload them as well.

Glad to hear you learned enough to do your own Post edits!