pe_inc_calc & ps_inc_calc

[ahaslam]

Why does the IHS have these? What does pe_inc_calc do for the post and why? I see that it updates and rounds off xia, but how is xia different than xinc? The reason I am asking is because I placed a pfxout in my post to call xy after a rotation on the tomb stone. Does it matter if I have pfxout before or after the ps_inc?

ps_inc_calc     #Incremental calculations, start              
      xia = fmtrnd(xabs)
      yia = fmtrnd(yabs)
      zia = fmtrnd(zabs)
      xinc = vsub (xia, prv_xia)
      ps_cinc_calc 

pfxout          #Force X axis output
      if absinc$ = zero, *xabs, !xinc
      else, *xinc, !xabs

Thanks for any feed back. Not a pressing issue as the post seem to work fine now but just wanted to understand the concept.

[Colin Gilchrist]

There are two blocks: 'ps_inc_calc' is "start of incremental calculations". The 'pe_inc_calc' is "end of incremental calculations".

 

This post (and all Generic Fanuc Posts from CNC Software), have a "switch", usually "miscellaneous integer #2", that will switch the output from "absolute" coordinates to "incremental" coordinates. 'mi2$' is used to set the 'absinc$' variable.

 

So for all output, the standard "absolute" coordinates are calculated in 'pxyzcout0' for Tool Plane based tool paths.

 

That means at the time we call 'ps_inc_calc', the values of 'xabs', 'yabs', and 'zabs' are already calculated and set.

 

In 'ps_inc_calc', we first set the "internal" variables for 'xia', 'yia', and 'zia' to the rounded values for xabs, yabs, and zabs.

 

These variables are used internally, and are not output. The Incremental values (all three numbers) are then calculated with 'Vector Subtract', which subtracts three variables in a row, from three other variables.

 

'xinc = vsub (xia, prv_xia)' <- This command takes three variables, and does a subtraction on each pair of numbers. This single line of code calculates all three Incremental values.

 

It is the equivalent of doing the following:

 

xinc = prv_xia - xia

yinc = prv_yia - yia

zinc = prv_zia - zia

 

So 'xia' and the "previous" value of that variable (prv_xia) are used internally by the post to set 'xinc'. This happens also with the other two incremental variables, it just isn't written explicitly, it is done using a 3D Vector Math Function, mostly for ease of writing the code I think. Why write 3 lines of code, when you can accomplish the same result with a single line, using an existing function?

 

 

 

So, what does the 'pe_inc_calc' do? It "updates" the variables that are used in the incremental calculations. This is for two things: modality output, and to make sure that the "previous" values are always set to the last XYZ position, so that the next time 'ps_inc_calc' is run, the Incremental variables are always calculated correctly, when the call to 'ps_inc_calc' is made.

 

 

In regards to your specific question: Yes, the call to 'pfxout' should be after the call to 'ps_inc_calc', if you ever intend to run using Incremental mode. That way the values are calculated correctly for 'xinc'.

 

Now, the other issue is this: if you want XY output, you need to put two calls on the line. One for 'pfxout', and one for 'pfyout', so that you also get Y output.

[ahaslam]

 3D Vector Math Function

 

Thanks Colin! I'm off to learn more about vectoring. 

[Colin Gilchrist]

There are a couple dozen Vector and Matrix Math functions available inside the Post. They are quite powerful, and you can do quite a bit of Linear Algebra, or similar functions just by using the math functions available inside MP.

 

One of my favorite experiences was working with John Summers, the original architect of the MP Language, and seeing a couple "posts" that John wrote, to take input in the form of a Text File, and output the points to generate a CAM profile, using just the language functions in MP. It was very cool to see how powerful the language is, and that you can do other tasks, beside just creating NC code output...

[crazy^millman]

There are a couple dozen Vector and Matrix Math functions available inside the Post. They are quite powerful, and you can do quite a bit of Linear Algebra, or similar functions just by using the math functions available inside MP.

 

One of my favorite experiences was working with John Summers, the original architect of the MP Language, and seeing a couple "posts" that John wrote, to take input in the form of a Text File, and output the points to generate a CAM profile, using just the language functions in MP. It was very cool to see how powerful the language is, and that you can do other tasks, beside just creating NC code output...

 

Yes I would have liked to worked side by side with him. He has my utmost respect when it come to what MP and Mastercam do.

[ahaslam]

People are pretty amazing. So many great things starting with one person. I still can't seem to get a grip on 3D vectors but I guess that's why I'm trying to learn it. It would be neat to see some one like John Summers in action.

[Colin Gilchrist]

What part of a 3D vector isn't making sense?

 

A "Vector" is just a line. Most often, the "base point" or "origin" of the vector is assumed to be 0, 0, 0. A vector is a "unit" vector, if the 3D length of the vector is equal to "1" unit in the coordinate system. In Inch mode, that vector length would be 1". In Metric, the vector would be 1mm.

 

If a vector is a "unit vector", then we can perform 3D math functions on the vector. (It is always recommended to define a vector as a 3D vector, even if you are only performing a 2D vector math function on it.

 

A Vector in the MP language is simply 3 ordered variables. Each number holds the X, Y, or Z endpoint of the vector.

 

v1_x  : 0

v1_y  : 0

v1_z  : 0

 

v2_x  : 0

v2_y  : 0

v2_z  : 0

 

vx_result : 0

vy_result : 0

vz_result : 0

 

xabs : 0

yabs : 0

zabs : 0

 

fmt  "X"  3  xinc

fmt  "Y"  3  yinc

fmt  "Z"  3  zinc

 

All 5 "arrays" above can be used in a vector math equation, since they are defined in a specific order. (breaking the order, breaks any math function that relies on them being in order!).

 

Technically, any 3D point, in Euclidean Space, is by definition a vector. It is a "point vector", that gives the X, Y, and Z distances from the origin of the coordinate system frame. (Gnomon)

 

To define a line, we usually use two endpoints of the line to construct it:

 

Here is a 30 degree line, that is 2" long:

 

v1_x  : 0.375

v1_y  : 0.25

v1_z  : 0

 

v2_x  : 1.7892

v2_y  : 1.6642

v2_z  : 0

 

For us to calculate the 3D length of the vector, we can use the 'lng3' function. But!... That assumes that the vector we want to measure actually starts at the origin.

 

So, if we wanted to use that "line" and calculate the length, we would first have to use 'vsub' (3D Vector Subtract) to subtract the start point from the endpoint. That would "shift" our vector endpoint, so that the start point would be at the origin.

 

vx_result = vsub(v2_x, v1_x)   # This line subtracts the vector, starting with 'v1_x' from 'v2_x'. It performs 3 subtractions.

 

The result of running the above code would put the following values into the vector starting with 'vx_result':

 

vx_result  : 1.4142

vy_result  : 1.4142

vx_result  : 0

 

If we then ran the "3D Length function", we would get the following:

 

result = lng3(vx_result)

 

After running that, 'result' would equal 2.0. (or maybe 1.9999999999!)

 

There is a ton of stuff you can do with both 3D Vectors (3 variables), and Matrix Functions (uses 9 variables, or 3 ordered Vectors).

 

For example, when MP outputs the NCI file, it contains no "Rotary Position" numbers. In other words, when we output A65.0 or B23.22 Degrees, that data is not contained anywhere inside Mastercam or the NCI file.

 

Those numbers are calculated, using the 'atan2' function, from the "Z Vector" of the Tool Plane Matrix. During processing, there is also logic that checks in a 4X Post to be sure that the "axis of rotation" hasn't changed from plane to plane. For a Vertical Machine, we check to make sure that either the X or Y Axis remains constant in your Tool Plane. For a Horizontal, we check only the Y axis of the tool plane, to be sure that it hasn't changed.

[ahaslam]

I think I follow. I guess my road block is being stuck on Cartesian system. What you just explained is more Cartesian, right? Because you have point to point with no parameters defining how to get there. Basically it's trig, a straight shot via the shortest distance. Assuming all this is correct, the point I lose it is when things go polar and when you start defining points with parameters. You spoke about how NCI doesn't output rotary position, it calculates them. Say you drop an end mill (or what ever) to a surface .5 units from center in Z (pretend I'm using a VMC with a 4th along x) Then you tell it to shift the plane +90 degrees (assumed abs origin). At some point, the NCI calculates the equivalent of an arc, right? It sees the shift in the plane but no motion in x or y. If it was Cartesian, planes wouldn't move and you would instead find the motion of Z-.5 and Y.5 gets you to the point. But, because the plane has rotated about the X axis, MP knows to trig it and finds that a 90 deg rotation gets you to the position defined. I don't know how much of that is right but that's kind of where I am. As for a matrix... I'm not even sure what to do with 9 variables.

 

PS, you're awesome. Thanks for the run down. 

[Colin Gilchrist]

You're on the right track. The key is that most operations do not contain "full rotary" motion. Take a Vertical Machine, with a Rotary A Axis, rotating about X, as an example.

 

If you machine on the "Top" plane, and cut a "pocket", then switch to the "Front" plane, Mastercam will use the "Z" vector of the Tool Plane to calculate the rotary position. This is where the posts "sees" the rotation, but it is "3 + 1". Meaning that as long as your Plane Origins are in the center of rotation, when you program in the "Front" plane, those coordinate motions match the coordinate positions of the machine, since the origin is the center of rotation. That means in the post, we just output "A90.", and the XYZ values are in essentially the same position, as long as your Planes are setup correctly.

 

Now, there are a couple paths that will produce "4X" motion without using "Vector" output.

 

Take Contour for example. You can use the "Axis Substitution" option to "Wrap" the geometry around a cylinder. Inside the Contour page, go all the way to the bottom of the tree. There you will find the Rotary settings. You must provide a "Cylinder Diameter", and you draw your geometry (say a line in this case), in the "Y" direction. Then you apply a Contour Tool Path. By using Pi as a constant, and knowing the diameter, you can figure out the length of the line you need to equal a certain number of degrees. To go 360 degrees, it would be Pi * Diameter. To go 90 degrees, it would be (Pi * diameter) / 4.

 

So, to calculate the length of 1 degree of "wrapped linear motion", it would be (Pi * diameter) / 360.

 

The other way to calculate it is to figure out what "your ratio" is for the diameter you are working with. We take the base unit of "1 inch diameter", and divide it by the diameter of your part. Say we are cutting a 22.2894 diameter...

 

1 / 22.2894 = 0.044864375

 

Then divide Pi by your ratio: 3.14159265 / 0.044864375 = 70.02421521291 length line to cut 360 degrees.

 

Double Check: 3.14159265 x 22.2894 = 70.02421521291

 

Pi x Diameter is pretty easy to remember...

 

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

 

Ok, so the hard thing to wrap your head around with "linear" coordinates, is that each point you "go to" or each point that the tool moves to, it is just a vector. It could be a really big Vector (1205.2614, 65.2322, 29.1254), but that is just a discreet point from an origin.

 

So, a Vector, is just a line in space, where the "start point" is just assumed to be 0,0,0.

 

We can treat everything as a vector. A Matrix; is just 3 Vectors, listed in XYZ order!!!

 

So, take your machine as an example. It is a Vertical machine, meaning Z is up/down, and let's assume that X is left/right, and Y is front/back.

 

Ok, so X goes to the Right. How would we define this mathematically, in terms of a Numeric Vector?

 

How about like this:

 

machine_X_x  : 1

machine_X_y  : 0

machine_X_z  : 0

 

We have to define all three endpoint coordinates to locate the "X Axis Vector". (And since we want to do "vector" and "matrix" math, it must be a "Unit" vector, or have a 3D length of "1 unit", in our case, inches!

 

Now, that's just the X Axis. What about the Y Axis? We can define it as follows:

 

machine_Y_x  : 0

machine_Y_y  : 1

machine_Y_z  : 0

 

As you can see, just by looking at the numbers, this is a 1" long line, that points in the +Y direction of our Mastercam coordinate system.

 

Finally, the Z Axis:

 

machine_Z_x  : 0

machine_Z_y  : 0

machine_Z_z  : 1

 

It is also a 1" long line, starting at the origin, and pointing "up" in Z.

 

If you put all three vectors, in an ordered list, you get a Matrix:

 

 

machine_X_x  : 1

machine_X_y  : 0

machine_X_z  : 0

machine_Y_x  : 0

machine_Y_y  : 1

machine_Y_z  : 0

machine_Z_x  : 0

machine_Z_y  : 0

machine_Z_z  : 1

 

 

ONE, zero, zero,

zero, ONE, zero,

zero, zero, ONE

 

Shown visually as:

 

1  0  0

0  1  0

0  0  1

 

That is a matrix, in written notation form.

 

Using 9 numbers, we can ORIENT the matrix, relative to a "base matrix". (Your machine's coordinate system arrangement, also called its "kinematics" is typically the "base matrix".

 

Now, what if we rotated our Tool Plane, about the X Axis, by 35 degrees? What would that "look like" mathematically?

 

Well, we are rotating about X, so that Vector stays constant:

 

machine_X_x  : 1

machine_X_y  : 0

machine_X_z  : 0

 

Now, what about the Y and Z axes?

 

machine_Y_x  : 0

machine_Y_y  : .8192

machine_Y_z  : .5736

machine_Z_x  : 0

machine_Z_y  : -0.5736

machine_Z_z  : .8192

 

Put the whole matrix together:

 

machine_X_x  : 1

machine_X_y  : 0

machine_X_z  : 0

machine_Y_x  : 0

machine_Y_y  : .8192

machine_Y_z  : .5736

machine_Z_x  : 0

machine_Z_y  : -0.5736

machine_Z_z  : .8192

 

So that is what a 35 degree rotation "looks like".

 

Here is 5 degrees:

 

machine_X_x  : 1

machine_X_y  : 0

machine_X_z  : 0

machine_Y_x  : 0

machine_Y_y  : .9962

machine_Y_z  : .0872

machine_Z_x  : 0

machine_Z_y  : -0.0872

machine_Z_z  : .9962

 

 

Now granted, I did not know those numbers off the top of my head. I simply created 3, one inch long lines, aligned with the coordinate system, and rotated the YZ vector lines, by a given angle, then just analyzed the lines.

 

I can tell you that when one number is zero, and the other two are both (+-) .7071, then you are at a 45 degree angle to some base matrix, whatever you are measuring relative to.

 

In all seriousness, start here:

 

http://ocw.mit.edu/courses/mathematics/18-06-linear-algebra-spring-2010/video-lectures/

 

The Open Courseware from MIT is amazing, and it is free. Try just the first video "The geometry of linear equations" to get started, and go on from there. I ♥ Professor Gilbert Strang.

[ahaslam]

Best explanation ever. Now that I see an applied matrix, it all clicks. I thought a 9 variable matrix was something you used relative to planes but, in reality it is the plane. It's relative, but only that origin is assumed. That's why Mastercam loses it's marbles when you shift your plane wrong. It can't build the matrix because (your example) machine_X_x  : 1 is no longer valid (assuming your plane bad rotation shifted X_x). Okay, so to build a matrix for HMC, you would start with your base, same as any other plane. (this assumes that you are programming the top plane as the primary plane and that you constructed it to rotate around y)

 

 1   0   0 (x) 
 0   1   0 (y)
 0   0   1 (z)

 

but then, you rotate your tomb stone +90 deg. The plane shift is seen as follows.

 

 0  0   1 (x)
 0  1   0 (y)
-1  0   0 (z) I might have that backwards, that might be 270 degrees.

 

Relatively speaking, your new plane sees the motion of x and z changed and your y remains centered. I'll check out the videos soon.

[Colin Gilchrist]

You are very much on the right track. But the "Base Matrix" itself is also relative to the "real world" in terms of how you define XYZ in Mastercam.

 

For a Horizontal machine, in Mastercam's Euclidean Space, think about how the Horizontal machine is normally programmed...

 

We use the -Y axis as the "machine Z", the +Z Axis as the "machine Y", and the X is still the X.

 

So for a Horizontal, the base matrix would look like this:

 

machine_X_x  : 1

machine_X_y  : 0

machine_X_z  : 0

machine_Y_x  : 0

machine_Y_y  : 0

machine_Y_z  : 1

machine_Z_x  : 0

machine_Z_y  : -1

machine_Z_z  : 0

 

 

1  0  0

0  0  1

0 -1  0

 

As you can see, the Y Axis is pointing "up" in Z. Also, the machine's Z axis is pointing towards -Y.

 

Now, in my example, I just made up some "user defined" variable names.

 

In the real posts, there is a "pre-defined" matrix, called, appropriately enough, "the machine base matrix".

 

 

For a Vertical machine:

 

matb1$  : 1

matb2$  : 0

matb3$  : 0

matb4$  : 0

matb5$  : 1

matb6$  : 0

matb7$  : 0

matb8$  : 0

matb9$  : 1

 

For a Horizontal machine:

 

matb1$  : 1

matb2$  : 0

matb3$  : 0

matb4$  : 0

matb5$  : 0

matb6$  : 1

matb7$  : 0

matb8$  : -1

matb9$  : 0