hexagon logo

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.
Parents
  • 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 Slight smile

    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?
Reply
  • 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 Slight smile

    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?
Children
No Data