Iterative alignment and using XactMeasure

First let me apologize for the cluster, and thank you for clarifying for me.

No worries, you are thinking rapidly which is a good sign!

1) Ok I think I understand. I am programming offline so no worries with "jog-box created" points. I can create auto vector points from model and get Iterative alignment to work? My trihedron will not move.

Ok, time to pull out the Big Explanation...
So: we are going to measure a 123 block.
We get a CAD file of the 123 block, and it's laying down with 1" being Z height, 2" being front-back Y width, and 3" left-right X length.
In the CAD model:
-> X zero = left face,
-> Y zero = front face,
-> Z zero = top face.

Running offline, you do the same exact Iterative plan of attack that you posted originally:
-> Some points on top face, all nominal Z zero, for the Level group.
-> Some points on front face, all nominal Y zero, for the Rotate group.
-> Some points on left face, all nominal X zero, for the origin group.

Running offline,
-> all those points on top plane with nominal Z zero also have actual of Z zero,
-> all those points on front plane with nominal Y zero also have actual of Y zero,
-> all those points on left plane with nominal X zero also have actual of X zero.

So when you create the Iterative Alignment, it looks at each point's deviation from nominal to actual and then shifts and twists and tweaks the coordinate system around to try to reduce those deviations.
Running offline, it has a very easy job - all deviations are zero. The trihedron... Does. Not. Move.

So, then we take this PRG to the CMM and measure a 123 block In Real Life.
First, with the cursor BEFORE the alignment, observe that the trihedron of the CAD model is on the part, but look at your probe readout and understand that you're currently in machine Startup coordinate system.
For sake of argument I'm assuming that it's upper left front, your machine may vary.

So, after you measure the 123 block sitting on the granite you get real actuals as defined by Startup coordinate system, with the cursor BEFORE the alignment:
-> all those points on top plane with nominal Z zero now have actual of Z negative "whatever inches the block is below machine home",
-> all those points on front plane with nominal Y zero now have actual of Y positive "whatever inches the block is away from machine home",
-> all those points on left plane with nominal X zero now have actual of X positive "whatever inches the block is to the right of machine home".

Then - the final step - the Iterative Alignment works it's background magic:
It shifts and twists and tweaks the coordinate system around to try to reduce those deviations between nominal and actual.
It makes a new alignment, one where:
-> the X deviations of the left plane points are reduced from "whatever inches the block is to the right of machine home" to zero.
-> the Y deviations of the front plane points are reduced from "whatever inches the block is away from machine home" to zero.
-> the Z deviations of the top plane points are reduced from "whatever inches the block is below machine home" to zero.

Click your cursor AFTER the iterative alignment and dimension the points to verify.
Notice the trihedron does not move as it's an artifact of the CAD file. All the alignment is doing is 'bringing' the actuals closer to the nominals.

Does an Iterative alignment control 6 DOF?

It does control 6 DOF as long as your sets of points don't all have the same vector. Your plan does control all 6 DOF.


Final explanation:
Instead of putting origins at datums, Iterative merely puts actual datum results as close to their nominals as possible.

That 123 block could be a car part hanging at some crazy angle in some huge complete-car XYZ coordinate system, with different random XYZ nominals for every point on the faces - and the Iterative would work to shift and twist and tweak the actuals until they fit those crazy nominals.
And the trihedron would still not move, because origin is not moving - only actuals are being moved.

Additional note:
The reason the Iterative repeats the measurement is that during initial manual run, each point has probing cosine error from clumsy human. Then, it repeats it again because the first couple DCC runs have decreasing probing cosine error as it tries to get alignments closer and closer to perfect.

NOTE: Do not add any material modifiers on datums (there better not be any for this datum scheme anyway) with Legacy. That's an old flaw


~~~

2 & 3) Datum -A- is not a plane, cylinder, or any other auto feature it is a surface with a very slight curve ("not prismatic", maybe not the right terminology) So if it can't be labeled datum -A- with my datum feature label for my dimensions in exact measure and my Iterative alignment doesn't translate my origins to my datums, how do I report my true position and profile dimensions to my A-B-C feature control frame?

What you have is an Irregular Datum Feature.
Your very best course of action is to switch from Xactmeasure to Legacy mode.
Then create Legacy position dimensions, which will neatly report the positions of the features according to the Current Alignment, which is your Iterative. Also put Report Comment before the dimension stating what datums the results are relative to: A, B and C.

Finishing touches: sometimes we even add the T values of the A, B, and C datum points to the report with tiny tolerances (which is fine because the results will be super close to or exactly zero) to drive home the fact that we are datumed on those surfaces.

First let me apologize for the cluster, and thank you for clarifying for me.

No worries, you are thinking rapidly which is a good sign!

1) Ok I think I understand. I am programming offline so no worries with "jog-box created" points. I can create auto vector points from model and get Iterative alignment to work? My trihedron will not move.

Ok, time to pull out the Big Explanation...
So: we are going to measure a 123 block.
We get a CAD file of the 123 block, and it's laying down with 1" being Z height, 2" being front-back Y width, and 3" left-right X length.
In the CAD model:
-> X zero = left face,
-> Y zero = front face,
-> Z zero = top face.

Running offline, you do the same exact Iterative plan of attack that you posted originally:
-> Some points on top face, all nominal Z zero, for the Level group.
-> Some points on front face, all nominal Y zero, for the Rotate group.
-> Some points on left face, all nominal X zero, for the origin group.

Running offline,
-> all those points on top plane with nominal Z zero also have actual of Z zero,
-> all those points on front plane with nominal Y zero also have actual of Y zero,
-> all those points on left plane with nominal X zero also have actual of X zero.

So when you create the Iterative Alignment, it looks at each point's deviation from nominal to actual and then shifts and twists and tweaks the coordinate system around to try to reduce those deviations.
Running offline, it has a very easy job - all deviations are zero. The trihedron... Does. Not. Move.

So, then we take this PRG to the CMM and measure a 123 block In Real Life.
First, with the cursor BEFORE the alignment, observe that the trihedron of the CAD model is on the part, but look at your probe readout and understand that you're currently in machine Startup coordinate system.
For sake of argument I'm assuming that it's upper left front, your machine may vary.

So, after you measure the 123 block sitting on the granite you get real actuals as defined by Startup coordinate system, with the cursor BEFORE the alignment:
-> all those points on top plane with nominal Z zero now have actual of Z negative "whatever inches the block is below machine home",
-> all those points on front plane with nominal Y zero now have actual of Y positive "whatever inches the block is away from machine home",
-> all those points on left plane with nominal X zero now have actual of X positive "whatever inches the block is to the right of machine home".

Then - the final step - the Iterative Alignment works it's background magic:
It shifts and twists and tweaks the coordinate system around to try to reduce those deviations between nominal and actual.
It makes a new alignment, one where:
-> the X deviations of the left plane points are reduced from "whatever inches the block is to the right of machine home" to zero.
-> the Y deviations of the front plane points are reduced from "whatever inches the block is away from machine home" to zero.
-> the Z deviations of the top plane points are reduced from "whatever inches the block is below machine home" to zero.

Click your cursor AFTER the iterative alignment and dimension the points to verify.
Notice the trihedron does not move as it's an artifact of the CAD file. All the alignment is doing is 'bringing' the actuals closer to the nominals.

Does an Iterative alignment control 6 DOF?

It does control 6 DOF as long as your sets of points don't all have the same vector. Your plan does control all 6 DOF.


Final explanation:
Instead of putting origins at datums, Iterative merely puts actual datum results as close to their nominals as possible.

That 123 block could be a car part hanging at some crazy angle in some huge complete-car XYZ coordinate system, with different random XYZ nominals for every point on the faces - and the Iterative would work to shift and twist and tweak the actuals until they fit those crazy nominals.
And the trihedron would still not move, because origin is not moving - only actuals are being moved.

Additional note:
The reason the Iterative repeats the measurement is that during initial manual run, each point has probing cosine error from clumsy human. Then, it repeats it again because the first couple DCC runs have decreasing probing cosine error as it tries to get alignments closer and closer to perfect.

NOTE: Do not add any material modifiers on datums (there better not be any for this datum scheme anyway) with Legacy. That's an old flaw


~~~

2 & 3) Datum -A- is not a plane, cylinder, or any other auto feature it is a surface with a very slight curve ("not prismatic", maybe not the right terminology) So if it can't be labeled datum -A- with my datum feature label for my dimensions in exact measure and my Iterative alignment doesn't translate my origins to my datums, how do I report my true position and profile dimensions to my A-B-C feature control frame?

What you have is an Irregular Datum Feature.
Your very best course of action is to switch from Xactmeasure to Legacy mode.
Then create Legacy position dimensions, which will neatly report the positions of the features according to the Current Alignment, which is your Iterative. Also put Report Comment before the dimension stating what datums the results are relative to: A, B and C.

Finishing touches: sometimes we even add the T values of the A, B, and C datum points to the report with tiny tolerances (which is fine because the results will be super close to or exactly zero) to drive home the fact that we are datumed on those surfaces.