Alignment from FCF Datum Shift

I think what vpt (and me) were hoping for was a way to create an alignment that uses the Xact fit shift. There are all sorts of applications for this. Using the available options in best-fit alignment is not the same, because they do not attempt to fit within a tolerance zone.

A few years old but I haven't found anything using search.

SPH1       =GENERIC/SPHERE,DEPENDENT,CARTESIAN,OUT,$
            NOM/XYZ,<0,0,0>,$
            MEAS/XYZ,<0,0,0>,$
            NOM/IJK,<0,0,1>,$
            MEAS/IJK,<0,0,1>,$
            DIAMETER/1,1.1
DIM LOC1= LOCATION OF SPHERE SPH1
AX    NOMINAL       +TOL       -TOL       MEAS        DEV     OUTTOL
D       1.0000     0.2500    -0.2500     1.1000     0.1000     0.0000 ------#--
END OF DIMENSION LOC1
            DATDEF/FEATURE=SPH1,A
            DISPLAYPRECISION/6
FCFLOC1 =POSITION : CIR152_1,CIR152_2,CIR152_3,...
            FEATCTRLFRAME/SHOWNOMS=NO,SHOWPARAMS=NO,SHOWEXPANDED=NO
              SIZE TOLERANCES/33,DIAMETER,0.375,0.005,-0.005
              PRIMARY DIMENSION/POSITION,DIAMETER,0.01,MMC,A,MMC,,
              NOTE/FCFLOC1
            FEATURES/CIR152_1,CIR152_2,CIR152_3,CIR152_4,CIR152_5,
                                CIR152_6,CIR152_7,CIR152_8,CIR152_9,CIR152_10,
                                CIR152_11,CIR152_12,CIR152_13,CIR152_14,
                                CIR152_15,CIR152_16,CIR152_17,CIR152_18,
                                CIR152_19,CIR152_20,CIR152_21,CIR152_22,
                                CIR152_23,CIR152_24,CIR152_25,CIR152_26,
                                CIR152_27,CIR152_28,CIR152_29,CIR152_30,
                                CIR152_31,CIR152_32,CIR152_33,,
            ASSIGN/V1=GETTEXT("DRF_SHIFTX",1,{FCFLOC1})
            ASSIGN/V2=GETTEXT("DRF_SHIFTY",1,{FCFLOC1})
            ASSIGN/V3=GETTEXT("DRF_SHIFTZ",1,{FCFLOC1})
            ASSIGN/V4=GETTEXT("DRF_ROTATIONX",1,{FCFLOC1})*-1
            ASSIGN/V5=GETTEXT("DRF_ROTATIONY",1,{FCFLOC1})*-1
            ASSIGN/V6=GETTEXT("DRF_ROTATIONZ",1,{FCFLOC1})*-1
            FORMAT/TEXT, , ,HEADINGS, , ;NOM,MEAS, , , , , 
DIM BEFORE= LOCATION OF CIRCLE CIR152_1
AX     NOMINAL        MEAS
X     10.153721   10.154507
Y    -27.402826  -27.405035
Z     -8.032519   -8.025360
END OF DIMENSION BEFORE
ALIGN1     =ALIGNMENT/START,RECALL:PREVIOUS,LIST=YES
              ALIGNMENT/ROTATE_OFFSET,V4,ABOUT,XPLUS
              ALIGNMENT/ROTATE_OFFSET,V5,ABOUT,YPLUS
              ALIGNMENT/ROTATE_OFFSET,V6,ABOUT,ZPLUS
              ALIGNMENT/TRANS_OFFSET,XAXIS,V1
              ALIGNMENT/TRANS_OFFSET,YAXIS,V2
              ALIGNMENT/TRANS_OFFSET,ZAXIS,V3
            ALIGNMENT/END
DIM AFTER= LOCATION OF CIRCLE CIR152_1
AX     NOMINAL        MEAS
X     10.151373   10.152161
Y    -27.394485  -27.396694
Z     -8.041472   -8.034312
D      0.376500    0.377383
END OF DIMENSION AFTER
            COMMENT/REPT,
            "Xshift:  "+V1
            "Yshift:  "+V2
            "Zshift:  "+V3
            "Rotation X:  "+V4*-1
            "Rotation Y:  "+V5*-1
            "Rotation Z:  "+V6*-1

The FCF output with datum shift is:

Using a sphere as the only datum seems to allow all 6 degrees to float. There is some small round-off error due to the numbers being used limited to the current DISPLAYPRECISION (not much).

Now what? Trying to actually use this has me baffled. I'd like to simulate the FCF output having the transformed measured coordinates evaluated against the model nominal values. The BEFORE dim has the nominals I want but the AFTER dim has the measured I want (like the FCF output). Inserting & Recalling alignments, Updating Dependent Commands (answering both yes and no) leaves me feeling like I've found my way into a rabbit hole. Maybe Profile dims behave differently?

I'm aware that some settings may influence the results: Update Dependent Commands (warning), UpdateBelowChangedAlignmentDuringExecution (registry), Ignore CAD to part (F5 settings), Allow Fine Tuning of Alignment (F5 settings). I'd really like to get this working inline without resorting to any type of external automation if possible. Can someone throw me a bone here? There's gotta be a way to get some mileage out of this.

Aaron Baldauf over 8 years ago

I had to work with this some more recently. My above application was regarding getting info from Xact for datum shift 9mmc on datum).

Now I had to get data from Xact re. composite position for hole locations. Some of what GomoFazter posted didn't apply to my first situation so it didn't sink in, but as I revisited the subject I see more clearly now. Attached is a graphic that I composed as I was trying to get a handle on assigning the data to variables. But its not very readable due to the resolution restrictions. Please let me know if you'd like me to email it to you.

Note, I've stumbled upon an error that I've submitted a ticket on to Hexagon help desk, that the Z and X data is mixe dup in the report window, and hence, also in how I assign the data to variables.
-------
edit. Just figured out why my XZ axis are flipped.
My alignment ABC: •Leveled on Plan A (adjacent to sphere datum B) in Yminus plane with a +Y vector
•-Rotated to a midline datum C, which is constructed from two side lines, all having +Z vector.
•Y origin on plane datum A
•XZ origin on sphere datum B
Since A is primary datum, I figured it should constrain 3 dof - hence my level and Y origin.
B sphere is secondary, so I set XZ origin on it.
C tertiary, so I rotated to it.
so I'm 3-2-1 with my dof restraints per proper datum precedence as I understand it.
But Xact seems to interpret the datum's differently (I'm using "Datum Reference Frame" in Advanced tab), so it flipped my XZ axes. When I reorder my ABC reference frame to ACB it rotates the Xact trihedron correctly.

So to correct my XZ axes flip I have to select "current alignment" in the Advanced Tab, rather than "Datum Reference Frame".

Am I incorrect in my interpretation of the ABC dof restraint? Or is Xact correct? Attached is a partial part sketch.

I don't know how it is handled in ASME but according to the ISO 5459 (or at least how I understand it) the primary Datum has to impose constraint of direction on the secondary and tertiary Datum and the secondary Datum also has to impose constraint of direction on the tertiary Datum. Because Datum B is a sphere it can't impose any directional constraint on the tertiary Datum. So in my opinion the Datums should be in the order [A][C] or [A][C><] to make sense.
[A][C] would mean:
- level to Datum A and translate corresponding axis to zero
- rotate to Datum C and translate second corresponding axis to zero
- with Datum B translate the last corresponding axis to zero
[A][C><] would mean:
- level to Datum A and translate corresponding axis to zero
- rotate to Datum C . Do not translate. The "><" means the Datum is just used for direction.
- with Datum B translate the last two corresponding axes to zero.

Maybe that's the reason Xact flips your axes.

Like I sad the above explanation is how I understand ISO 5459 so correct me if I'm wrong.
Also I just have the German version (DIN EN ISO) so I don't know how it is exactly stated in English. I tried my best to translate it
Cancel
Vote Up 0 Vote Down

Sign in to reply

Cancel
Kevo_cmm over 8 years ago

I don't know how it is handled in ASME but according to the ISO 5459 (or at least how I understand it) the primary Datum has to impose constraint of direction on the secondary and tertiary Datum and the secondary Datum also has to impose constraint of direction on the tertiary Datum. Because Datum B is a sphere it can't impose any directional constraint on the tertiary Datum. So in my opinion the Datums should be in the order [A][C] or [A][C><] to make sense.
[A][C] would mean:
- level to Datum A and translate corresponding axis to zero
- rotate to Datum C and translate second corresponding axis to zero
- with Datum B translate the last corresponding axis to zero
[A][C><] would mean:
- level to Datum A and translate corresponding axis to zero
- rotate to Datum C . Do not translate. The "><" means the Datum is just used for direction.
- with Datum B translate the last two corresponding axes to zero.

Maybe that's the reason Xact flips your axes.

Like I sad the above explanation is how I understand ISO 5459 so correct me if I'm wrong.
Also I just have the German version (DIN EN ISO) so I don't know how it is exactly stated in English. I tried my best to translate it

Aaron, Thanks for your input. I've heard there are differences between ASME and ISO5459 - maybe this is one of them.
I would not claim to be an ASME expert myself, but in my understanding of datum precedence it would be contradictory to have the tertiary datum control more degrees of freedom than the secondary datum. So by placing datum C in tertiary position the designer is communicating that he only wants it aligned to, not translated to. I used to think that the rotation had to be in the secondary datum position but was corrected by someone more knowledgeable, that if it only controlled rotation - only 1dof - then it belonged in tertiary position even though it was the rotation constraint.
Does ISO5459 allow secondary to control more dof than primary?
Or tertiary to control more dof than secondary?
Cancel
Vote Up 0 Vote Down

Sign in to reply

Cancel