In this article I will talk about 5 axes measurement. Until recently most CMMs measured using a combination of their X, Y and Z axes. This meant that the probe head remained static during the touch process.

The GOTO statement:

Or

GOTO/coord_type,x(r),y(a),z(h),PCS,z1,y,z2

DMIS GOTO statements were previously used to instruct the CMM to move to a Cartesian x, y, z or polar r, a, h position which moved the CMM only. The additional parameters give programmers the ability to not only move the machine but also the head axes simultaneously. The software will usually take care of making sure that all 5 axes arrive at the target point simultaneously which means that the head can be moved into areas previously only accessed with a great deal of trouble. This is especially true when the CMM is moving in FLY mode. The following example moves the machine to a Cartesian position of 100, 100, 0 while simultaneously rotating the head to the angles 90 and 180.

Example:

Those of you familiar with the polar head rotation of existing probe heads will recognize the angles in this example (note … the order is B then A). The angles are an easy way for existing programmers to create moves with built in head rotations. In this case the angles are considered absolute which means that a programmer must enter new angles to measure another feature in different orientation. The next example moves the CMM to a polar position of 30.5 (radius), 0 (angle) and a height in the current work plane (WKPLAN) of 76 while simultaneously rotating the head using Euler angles -90, 45 and 180.

Example:

GOTO/POL,30.5,0,76,PCS,-90,45,180

Unlike the previous HEADCS angles which are familiar to us, Euler (pronounced ‘oiler’) angles are defined from the current axes system and as such can be reused by rotating the axes using the relevant DMIS statements. This makes it very easy to create code to measure a feature and then rotate the axes to measure a similar feature without having to modify the head orientation. This also means that the probe head will reorient to facilitate parts that are not perfectly aligned to the CMM axes. The downside to using Euler angles is that they are not trivial to calculate however a good inspection system will give you tools to create and manipulate these angles without resorting to your calculator. Renishaw's own inspection software (Modus) provides tools to generate head angles based on part models and a means of converting the usual A and B angles into Euler angles. DMIS language statements have also been added to define touches that include head movement:

The PTMEAS statement:

Or

PTMEAS/coord_type,x(r),y(a),z(h),i,j,k,PCS,z1,y,z2,touch_type

As with the DMIS GOTO statement head orientation parameters have been added to the PTMEASstatement. It has also gained an option for ‘touch type’ (either HEADTOUCH or ALLAXESTOUCH) which defines whether the head should be used alone or with the CMM to touch the part.

Example:

This example measures a point at x=4.5 y=0 and z=0. The point has a negative Y normal and the measurement will be carried out using a combination of the CMM and head axes to touch the component. The following screenshot illustrates the process of generating PTMEAS touches using a model based toolset:

Illustration of PTMEAS generation in Renishaw Modus Software by kind permission.

Each of the blue lines represents the head angle as it makes contact with the bore being measured. This means that the CMM can remain stationary while the head measures the circle. The resulting DMIS code is listed below:

F(A)=FEAT/CIRCLE,INNER,CART,27.5,90,-50,0,1,0,35

MEAS/CIRCLE,F(A),12

PTMEAS/CART,45,92.5,-50,-1,0,0,PCS,97.7,90,-90,ALLAXESTOUCH

PTMEAS/CART,42.655,92.5,-41.25,-0.866,0,-0.5,PCS,96.7,93.8,-119.7,ALLAXESTOUCH

PTMEAS/CART,36.25,92.5,-34.845,-0.5,0,-0.866,PCS,93.8,96.6,-149.7,ALLAXESTOUCH

PTMEAS/CART,27.5,92.5,-32.5,0,0,-1,PCS,90,97.7,180,ALLAXESTOUCH

PTMEAS/CART,18.75,92.5,-34.845,0.5,0,-0.866,PCS,86.1,96.6,149.7,ALLAXESTOUCH

PTMEAS/CART,12.345,92.5,-41.25,0.866,0,-0.5,PCS,83.2,93.8,119.7,ALLAXESTOUCH

PTMEAS/CART,10,92.5,-50,1,0,0,PCS,82.274,90,90,ALLAXESTOUCH

PTMEAS/CART,12.345,92.5,-58.75,0.866,0,0.5,PCS,83.2,86.1,60.2,ALLAXESTOUCH

PTMEAS/CART,18.75,92.5,-65.155,0.5,0,0.866,PCS,86.12,8.3,30.2,ALLAXESTOUCH

PTMEAS/CART,27.5,92.5,-67.5,0,0,1,PCS,90,82.274,0,ALLAXESTOUCH

PTMEAS/CART,36.25,92.5,-65.155,-0.5,0,0.866,PCS,93.8,83.3,-30.2,ALLAXESTOUCH

PTMEAS/CART,42.655,92.5,-58.75,-0.866,0,0.5,PCS,96.7,86.1,-60.2,ALLAXESTOUCH

ENDMES

The PTMEAS statement is generally considered a touch statement and although it can be used in some scanning statements it is generally recommended that scanning employ the DMIS PATHstatement:

The PATH CURVE definition statement:

Or

P(name)=PATH/CURVE,x,y,z,i,j,k,PTDATA,z,y,z,i,j,k,PCS,z1,y,z2 …

The DMIS PATH statement when used with a CURVE parameter provides a position and plane for theCURVE but also allows the addition of multiple PTDATA parameters containing a touch definition (x,y,z,i,j,k) and the orientation of the head as relates to that touch. When multiple PTDATA parameters are strung together the CMM and head flow from one point to the next in a seamless scanning movement without the usual need for stops in order to reorient the head for access. The following illustration shows PATH generation for a CURVE using a rail tool. This example clearly shows that the head moves to access the curve while the CMM moves along the rail forming a 5 axes measurement.

Illustration of PATH generation in Renishaw Modus Software by kind permission.

The PATH statement provides similar functionality for surfaces:

The PATH SURF definition statement:

Or

P(name)=PATH/SURF,PTDATA,x,y,z,i,j,k,PCS,z1,y,z2 …

The SURF version of the PATH statement is very similar to a CURVE but is not restrained to a plane and as such does not require position or plane definitions.

Other PATH statements have also been co-opted by Modus to implicitly include head orientations based on the definitions contained therein and it is expected that most DMIS based systems will provide DME measurement routines when in AUTO mode making upgrading existing DMIS based systems relatively straight forward from a program modification point of view.

One final area of interest is the DMIS SNSLCT statement. Although the move and measurement statements talked about in this article make actual sensor selection virtually unnecessary there may be times when you would like to move the head without moving the CMM. The DMIS SNSLCT statement has been modified to allow this:

The SNSLCT statement:

Or

SNSLCT/SA(name),PCS,z1,y,z2

By now you will be familiar with the head angles added to the end of the SNSLCT statement. When a SNSLCT is executed the DMIS system will use the name of the sensor to recall the relevant calibration map and decide whether to change to another rack position. The optional head angles can be used to rotate the head to a predefined position. If an independent head move is not required the programmer will typically use the DMIS RECALL statement to retrieve the sensor from the software’s database and then use the SNSLCT statement to install the relevant map at the start of the program after which no other selections will be necessary.

Stephen Horsfall specializes in DMIS programming, training and consulting and is the author of ‘Step by Step DMIS Programming’ available from the Dimensional Metrology Standards Consortium (www.dmisstandard.org). He can be contacted at This email address is being protected from spambots. You need JavaScript enabled to view it. .

JSN Megazine template designed by JoomlaShine.com